Software Infrastructure for Business Value

The need for MDM and the role of architecture

2009-09-11T19:44:58Z

The other day I read a post from David Norfolk ("The MDM tarpit") which generated some lively comment. You can read the post yourself, but to briefly summarise, David highlighted a view that Master Data Management (MDM) should really be redundant - the need for MDM is really a reflection of poor architecture or poor strategic planning. Design things right from the outset and you won't find yourself needing MDM, appears to be the argument. David says:

In my opinion, if you have an MDM project, this is prima facie evidence of poor governance in the past. If you couldn't manage your data properly before, once the initial euphoria of buying your shiny new MDM software has worn off, won't you make the same mess of the "master data" that you previously made of your original data? After all, a fool with a tool is still a fool--what has changed?

I think there are two problems with this point of view - which is really a specialisation of a broader view that with "good" architecture in place, the need for remedial action or investment should never be required.

The first is that David's argument could just about be made to work - *if* all you do is implement custom-built applications where you can determine the data model(s) in play and mandate sharing of metadata definitions and so on. However, unlike thirty years ago, for most organisations it's a small minority of applications today that are built, rather than bought. Of course, if you're buying applications off-the-shelf, you have no say over the data models underpinning those applications. Functional and business process fit should be the overriding concerns when considering buying packaged applications - it would be foolish to consider the nature of an underlying data model as a purchasing criterion.

The second is that (as I said a while ago here)

Even where architecture is highly effective (and in many places it isn't), it can at best only be one of many forces shaping the way that IT evolves to support changing business conditions and requirements, and each force has its own vector. Some forces, like a good architecture team, try and combine business and technology focus, and promote the value of global optimisations, good practice and standardisation. But most of the most powerful forces are business forces, and in 99.99% of organisations, their power, when something really big and important happens, will trump any righteous splutterings emanating from IT departments.

Mergers and acquisitions are an obvious example of "something really big and important". They typically lead to duplication of application coverage and the need to harmonise views of products and customers - primary usage scenarios for MDM technology.

From a technology architecture idealist's point of view MDM may seem rather annoying and of course, given a choice, people would rather not have to deal with the issue of reconciling and synchronising data - but we live in a complicated, imperfect world.

What do you think - have I missed the point?

The seven elements of Cloud Computing's value

2009-08-20T04:55:22Z

Back in June I was invited to speak as part of the London leg of TIBCO's NOW roadshow, which focused primarily on Cloud computing and TIBCO's new Silver offering (you can see what we think about that specifically in this report).

My job was to talk about "articulating the value of Cloud computing". This was a fun challenge: so much of the talk about Cloud today starts by arm-waving at the 30,000ft level - and then zooms right down to the level of "virtualised compute resources" and "dynamic scalability". What I hadn't seen so much of was an attempt to map out more of a big picture of the value that Cloud computing can potentially deliver in the context of other approaches to consuming IT infrastructure resources.

So after reading countless blogs, conference proceedings, customer stories and news articles, I sat and stared at a blank piece of paper for a while, thinking about how I could pull all the different perspectives together to show one picture that captures all the different ways in which Cloud computing can potentially deliver value. This is what I ended up drawing and presenting in my talk:

You can see that there are seven elements of value I've highlighted, and they fall into three "value types": economic, architectural and strategic.

The economic value of Cloud is largely about being able to align the timing and size of the investments you make with the value you receive - variously referred to as "pay as you go", "pay as you grow". You don't pay $millions for infrastructure that only delivers value months or years later; you pay for what you actually need, when (or soon after) you use it. And you don't purchase an asset that then depreciates (like crazy).
The architectural value of Cloud is about having an simple, consistent abstract environment presented to developers and operations folks that hides a lot of complexity, making it much quicker and easier to develop and deploy applications.
The strategic value of Cloud might be easily conflated with the economic value, but I think it's different. It's this: Cloud platforms help you focus on what makes your organisation more effective and different, and leave all the other stuff to a third party that is dedicated to doing a great job for a competitive price. This is about focus and it's also about avoiding having to train people to do things that fundamentally don't add value to your organisation (think "Lean IT" if you like.)

Have I captured all the potential elements of Cloud computing value? I'm 95% sure I have - but if I've missed something please let me know! Either way, the discussions I've had around this picture so far make me think that it's a useful model for exploring different Cloud propositions as stated today and comparing them. What do you think?

Progress Software - getting past "Who"?

2009-04-01T14:24:10Z

A couple of months back I had a brief Twitter exchange with David Bressler of Progress Software (@djbressler), following a comment I'd seen from Judith Hurwitz (@jhurwitz) at Progress' analyst day regarding the lack of brand awareness that the company has out there in industry. What I said was: "Progress is a bit like Unilever - top-level brand is vanilla, sub-brands have chops". What I meant is that these days, there's little knowledge of what Progress does (a typical response is either "Who?" or possibly "oh, they used to sell a 4GL and a database in the 1990s, didn't they") - whereas there's much more recognition of brands like Sonic (SOA infrastructure), Actional (SOA management / governance), IONA (middleware, SOA infrastructure), Apama (event processing), DataXtend (data integration) and DataDirect (data connectivity, legacy application integration).

David replied that Progress is a technology company's company - which is absolutely correct: Progress has a long and successful history of providing a platform for other software vendors to embed in their application offerings. And he followed up with this blog entry, saying "We'd love for the Progress brand to have some chops, and we're trying but it's not trivial."

Well, for a few weeks I'd been meaning to write a blog post of my own exploring this - but in the general headlong rush that we've been experiencing so far this year, I'd forgotten to write that post. When I saw today's news that there's been a change at the top at Progress, though, I was finally prompted to write some thoughts down. (Thanks for the pointer Miko).

The main thought in my head all those weeks ago was that it's all very well for Progress to be a bit like Unilever - with the sub-brands (Sonic, Actional, Apama, DataDirect, and so on) having much more visibility in industry than the parent brand - as long as the company doesn't want to start pulling together broader IT and business infrastructure propositions that tie together pieces from the different brands. Unilever is well-known for owning a vast portfolio of products, many of which actually compete with others in the portfolio (Dove v Lux; or Persil v Surf, for example). The invisibility of the parent brand is fine for Unilever, but it's bad news for Progress if it wants to really make the most of its potential within enterprises (by cross-selling or bundling its products to help customers with broader opportunities, for example).

So this is the point where the company has to undergo a pretty radical shift. As reported in PCWorld, the new Progress Software CEO (formerly the COO) has established a target of doubling the company's annual revenue to around $1bn, by "reorienting sales towards multi-product suites, as well as aiming marketing messages more at business executives than IT workers" - that is, precisely what it's not currently suited to doing.

This goal makes absolute sense, and in fact it has made sense for ages. The majority of the markets where Progress' brands play are growth markets where there's real opportunity, right now; and what's more, the combination of the offerings could have real power, too.

The required shift will be no picnic, but there are worse times for Progress to be trying to make it happen. There's a new man at the top with a new broom, no doubt; and what's more, there's still a small window of opportunity open for another medium-to-large-sized specialist infrastructure software vendor to pick up business, following BEA's acquisition by Oracle a few months back. TIBCO and Software AG have recently been making much of BEA's disappearance as an "independent" infrastructure software vendor, and it's surely no coincidence that both these companies also have aspirations to reach $1bn in annual revenues (Software AG has been particularly vocal about this of late - it's just reached the $1bn mark following its acquisition of webMethods). Progress has long had the potential to join Software AG and TIBCO as a serious contender for enterprises wanting to avoid getting into bed with the MISO pack (Microsoft, IBM, SAP or Oracle) for whatever reason, but until now it just never seemed to be able to be bothered to do what was necessary.

With a new CEO at the top, it'll be fascinating to see whether Progress can move up a gear. If it succeeds, then enterprises wanting to avoid giving too much technology supplier power to the MISO pack may well have a new choice - and in a market where consolidation has recently been rampant, more choice would be refreshing for everyone.

Why we need ALM: industry's dangerous flirtation with software quality

2009-03-20T12:03:42Z

Yesterday I spent the evening at a dinner in London as a stand-in for my colleague Bola Rotibi, talking about Application Lifecycle Management (ALM) and governing software delivery to a group of around 20 senior IT leaders. Due to my own disorganisation I'd not realised that this was a stand-up talk with no visuals or projection, and I'd created a slide deck for the talk.

So, on the train to the event, I was frantically reverse-engineering my slides into a set of brief stand-up notes. Although it was a pain, it ended up being fortuitous because the act of having to reinterpret my slides made me see a couple of points worth making that I hadn't spotted before.

The point I was making is that today's industry interest in ALM represents an interest in delivering high-quality outcomes from software delivery work, but that's hardly a new thing. However the need for ALM today is made more pressing by industry's historic failure to consistently address quality as a concern. It's what I called "industry's dangerous flirtation with software quality" - kind of a perpetual "get away, come closer" posture that has by and large failed us. Although there's now 50+ years of racial memory somewhere out there in industry about why software quality is important and how to achieve it, the problem is that fundamentally, the IT industry is a fashion industry - and each new fashion wave brings a new set of devotees, few of whom are particularly interested in taking notice of what the devotees of previous waves learned.

Let's look at a picture.

What I'm trying to show here is how disruptions in technology platforms and architecture patterns typically lead to the baby being thrown out with the bathwater. As any given approach starts to have mainstream applications and matures, the importance of quality becomes more visible. Then, though, a new platform arrives and we start all over again. Think about how, in the client-server era, we started with hacking in PowerBuilder and VB; then, "second-generation" client-server tools took more CASE-like approaches and helped organisations deliver more scalable, robust apps more quickly. Then came the web, and it seemed that we suffered from a mass "memory wipe" before grabbing hold of the nearest Java IDE and hacking again.

We've been through this cycle at least three times: from mainframe to client-server; from client-server to first-generation web; and from first-generation web (simple consolidated server deployment; simple web-based client deployment) to where we are now (I'm desperately trying to avoid typing the web-two-dot-oh thing, but I'm referring to web-based services with multi-channel front ends, mashups in the mix, back-end web-based integration, etc). Of course, so far I've really said nothing you probably hadn't thought about already. But what also struck me yesterday was how each "turn" around the cycle has added more complications to the process of software delivery. There are three parts to this.

Firstly, consider that each time we've turned through the cycle, the overall IT environment has become more complicated. This has happened in two ways. Each new platform/architecture has brought more distribution, federation (moving parts) to the equation; and nothing ever dies - mainframes, client-server systems, and first-generation web systems still abound. They're part of the operational and integration environment.

Secondly, each time we've turned through the cycle, there's been a decreasing scarcity of "hard" resource - that meant that we naturally had less innate desire to control effort and quality than previously. Back in the early days of mainframe development, CPU cycles were expensive and access to those cycles was exclusive; it was absolutely obvious that the cost of the assets employed was so high that you had to get things right first time.

Today, for the price of a sandwich, I can get some tools, rent some server capacity, and build and deploy an application that might end up playing at least a bit part in the way a business works. The kicker is that although the cost of "doing stuff" is rapidly tending towards zero, the cost of software failure is at least as high as it's always been - but the tendency in industry to perpetuate the artificial "wall" between software development and IT operations means that we can easily forget about the cost of failure - and the overall risk to software delivery outcomes - until it's too late.

Thirdly, each time we've turned through the cycle, the distinction between "software" and "service" has become more and more blurred, as business services have come to depend increasingly on software automation internally, and be delivered to consumers through software-based interfaces externally.

These three factors all point to the desperate need for organisations to be able to better link activities across the whole of the software delivery lifecycle - from upstream activities like portfolio management, demand management and change management right through development, test and build all the way downstream to IT operations.

We need to turn software delivery into a business-driven service - and that means ensuring that business priorities are reflected in *what* work gets done; ensuring that business priorities are reflected in *how* work gets done; and ensuring that individual projects are carried out in the context of a "big picture" of business service delivery. That's what ALM is all about.

If you'd like to read more about Bola's thoughts on this subject, check out The dilemma of "good enough" in software quality.

Cloud computing, SaaS and SOA - the universal service network

2009-02-23T05:45:03Z

Something that's been sloshing gently around in my head for a little while came into focus the other day on reading a post by Brenda Michelson: Unintentional Cloud Watching >> Cloud Computing for Enterprise Architects. Namely, that the link between cloud computing and SOA has multiple angles.

It's becoming clearer that, true to Tim O'Reilly's initial Web 2.0 noodling, by providing open infrastructure services and APIs, the poster children of the Web 2.0 era - Amazon, Salesforce, Zoho, and so on - are now treading the path that companies like StrikeIron started out on in 2002.

As a result, as other commentators have noted, it looks like the bulk of the service-oriented IT that many organisations will interact with will be "stuff from outside" (commercially provided services) rather than "stuff from inside" (internally developed services). And it's not just hosted SaaS providers who are playing here of course: there's the issue of newer versions of on-premise commercial packaged application software products and integrations between them - SOA is coming in by the back door there, too (see SAP's ESOA, Oracle's Fusion Architecture). In fact, perhaps unsurprisingly, there are strong parallels here with the component-based development (CBD) hype-wave of the 1990s - a lot of the initial hype was around tools and development for enterprise IT groups, but ultimately the vast bulk of development was actually carried out by commercial software vendors, for consumption by enterprise IT teams. What we're seeing here is a repeat of "componentware" market development, with a 21st Century twist.

Regardless of where services come from (and indeed because they will come from multiple places, creating cross-enterprise service networks), it's increasingly the case that in order to deliver effective IT capabilities in the 21st Century, you need to understand SOA principles and build technology and management structures that really support the principles of service orientation. Much has been written about the "consumerisation of IT" and how new generations of people entering the workplace are asking difficult questions about why enterprise IT applications are so unintuitive to use. But what happens when business teams that are using SaaS-based offerings learn about the infrastructure side of the story - how easy they can be to customise, extend, and integrate with - and ask why internally-developed systems don't exhibit the same qualities? Another slab of SOA pressure, that's what.

Back in 2006 I was doing some research for an event that we were considering running on "IT Sourcing in the 21st Century". As part of trying to work out what might be in scope and what might be out of scope, I drew this picture:

As the picture attempts to show, from a technology architecture point of view, the software-as-a-service (SaaS) model relates to the prior Application Service Provider (ASP) model in much the same way as SOA relates to monolithic on-premise applications - to deliver value, both SaaS and SOA need to "crack the box open" and enable IT capabilities to be customised, composed and remixed while also being shareable/reusable. There's much I disagreed with about Anne Thomas Manes' recent "SOA is dead" post (see Schrodinger's SOA), but she nailed this parallel between SaaS and SOA pretty well I think.

With the increasing visibility of cloud-based infrastructure and application services in mind, anyone seriously pursuing SOA should be looking to the world of SaaS for insight, or at least inspiration. In the IT industry's rush to SOA, many of the nuances and implications of SOA have often been condensed into simplistic advice targeted at software developers (something that's been written about a great deal, not least by us). One of the themes we've returned to again and again in our SOA advice is that the concept of a "service" isn't primarily about something you build - it's about something you experience. If you're going to deliver business value from your SOA efforts, you have to grasp the implications of this and make the necessary changes - not only in terms of tools and technologies, but also (crucially) in terms of your governance approach. One of the most popular posts from arch-architect Todd Biske, on ITIL and SOA, digs nicely into how it's crucial to consider the full service lifecycle when you do SOA, and drive governance to ensure that you can deliver "real service" - not just code wrapped in XML-based interfaces.

The providers of cloud-based services should have this idea etched on their brains - and there are plenty of examples of this principle in action for any eager student of SOA. Witness the grumbles that echo when Twitter barfs, for example, or see the grumpy users trying to get to grips with Zoho's CRM API in the face of almost non-existent documentation. These are great examples of situations where the provider's idea of service doesn't match the consumer's expectation.

The rise of cloud computing and SaaS should entice us to revisit our development-centred assumptions about SOA and search for a "bigger picture" that focuses on consumer expectation and value first. The pressure to deliver business value from IT capabilities, and the increasingly diverse mix of IT capability sources, demands that we do so.

Notes from a BPM conference

2008-11-03T09:16:54Z

A few weeks ago I spent a couple of days in London, at IRM's 2008 Business Process Management Conference Europe, where I took in most of the sessions and also ran a session myself. I've been meaning to do a quick write-up of what I came across for a few days... so here it is.

I think this was the first time that IRM UK (most known for technology conferences, seminars and training courses focusing on Enterprise Architecture, software development techniques etc) had run a BPM conference. The event was put together with the assistance of BPTrends, the BCS and the Process Renewal Group; and the BPM-Forum, ABPMP and the BPM Journal were also involved. The infamous (well, in certain circles) Richard Soley and Howard Smith were also in attendance. All in all, we certainly weren't short of serious-minded types ;-)

Most of my time was spent in the "case study" sessions, each of which was led by one or two representatives from industry who'd embarked on a BPM initiative of some kind and come out the other end with all limbs intact. (I had an ulterior motive, which was to seek out volunteers for our own BPM case study programme, which you can find out more about if you like). I attended sessions by a Danish pensions administrator; a UK pension fund manager; a (very large) telecoms operator; the European Court of Human Rights; a UK hospital trust; and an oil/energy giant.

What did they have in common? At a high level, not much - but that in itself was interesting. One organisation was imposing standard processes throughout most of its operation, catalysed by a mind-bogglingly large SAP rollout. One was really doing some pretty lightweight content lifecycle management, even though on quite some scale. One was pursuing an ingenious application of Business Process Management Suite (BPMS) technology to implement process automation and performance monitoring without any direct interaction with existing applications. One implemented virtually no new technology, but revolutionised a key process and dramatically improved its business as a result. And one was primarily focusing on cataloguing and attempting to standardise ways of representing existing business processes.

Here's a handful of choice quotes I jotted down from the sessions and from coffee-break conversations - they're all thought-provoking.

"KPIs are units of measure. But you have to know what measures you want ? efficiency? Effectiveness? Adaptability?"

"The best thing we did to improve business-IT collaboration was to move to open-plan seating."

"We had plenty of KPIs and SLAs in place; but they were aimed at optimising localised individual activities, rather than our performance against the sales promises we were making."

"Senior business managers don't like detail and so often don't like the idea of 'process'. They see it as detail, and about something that doesn't sound very agile."

"Most organisations have a functional management structure, but in a complex business this isn't sufficient. It doesn't actually support delivering a good customer experience."

"Everything you do in process management should be related to performance."

"We decided not to blindly look for best practice. Instead we chose to work around something we called 'best available practice' - the best of what was already being done inside the company; stuff we knew would work within our culture."

"[A large German auto manufacturer] has created around 15,000 services from its SOA initiative. That's probably not a good thing."

Given the timing (this was just as the financial services universe was beginning to collapse in on itself) the event seemed to be pretty well-attended (the sponsors that I spoke to certainly seemed happy, anyway). My two key take-aways?

First: luckily (for my prejudices ;-), what I came across further confirmed what we thought was the case, from the research we've done in the BPM area through 2008. In the real world, there's still not really much consensus about what BPM is, what it's made of, and how you know when you're doing it (let alone when you're doing it well).
Second: The one thing that all except one case study (and many conversations) highlighted was that the buy-in of senior management is absolutely crucial to success. The culture, management structure and operating model(s) of your organisation are the biggest determinants of the the kind of BPM initiative you'll be able to follow, and the likelihood of you being able to achieve a successful result.

Overall I'd say it was a really solid event, and I'm definitely going to be responding to the Call for Papers for 2009, if I'm invited. Along the way I also learned that only around 1% of the audience (based on a rough count) was pursuing a Six Sigma initiative, that around 5% were pursuing SOA, and that although around 10% had heard of the word "mashup", no-one would admit to having created one. Viz. the level of awareness/adoption of SOA, I think this is just one more data point that shows how dangerous it is to make simplistic assumptions about the relationship between BPM and SOA (I talked more about that here and here, as well as in this report within our BPM advisory service).

SOA governance and data governance - separate or one in the same?

2008-09-24T06:24:55Z

Joe McKendrick (once again!) has another post which caught my blogreader today. This time he is pondering the relationship between SOA and data governance:

If data governance is inadequate - information is outdated, out of sync, duplicated, or plain inaccurate ? SOA-enabled services and applications will be delivering garbarge. That's a formula for SOA disaster.

He goes on to reference an article by Ed Tittel, which draws the same conclusion:

Amidst all the hype and buzzwords that surround SOA nowadays, it's still far too common for organizations that seek to integrate service-oriented architecture into their IT infrastructure to omit issues related to data integration, management and governance in their designs. As they roll out and learn to live with an SOA, however, they often discover that interoperability with other systems and solutions poses interesting problems. In fact, these problems can make interaction between systems and SOA components both vexing and time consuming.

Absolutely! When we put together our SOA Strategy Planning Tool, we explicitly acknowledged the importance of a common information model that provides:

standard representations of core information types for communication between services

Where I deviate from Joe and Ed, however, is their perspective that data governance and SOA governance are separate disciplines. Without inter-service communication there's no SOA and so SOA governnance must encompass data governance. Furthermore, that governance needs to extend beyond service design throughout the service lifecyle.

In a subsequent post, Joe calls out this post from David Linthicum in which he noodles on the same topic. I am not so sure about David's view that SOA initiatives:

need to start with the data first

It all depends on the scenario where a service-oriented approach is being applied. However, I agree with him that there is a need to understand:

the core purpose of the data, how it relates to other data, how the data is bound into entities, as well as security issues, integrity issues, and the binding to existing functions or transactions. I would go further and say that it's not just about understanding those things. In the case of security and integrity issues, there is a need to ensure that what is understood is enforced. That means defining service contracts that take account of those requirements and enforcing them through policies.

Which brings me neatly back to the SOA versus data governance discussion. Policies are the lingua franca of SOA governance and policies apply as much to the data flowing in a service network as they do to the services themselves.

If you are embarking on an SOA initiative you need to ensure that those responsible for SOA governance, ideally though an SOA centre of excellence, include individuals with data management expertise. Your governance processes should enforce utlilisation of a common information model and encompass a policy-based approach to ensure that data management objectives and constraints are enforced.

Hmm indeed Mr McKendrick - that should be "an over-simplistic definition of 'SOA'"

2008-09-24T06:21:05Z

Joe McKendrick over at ZDNet has been pondering CIO "SOA Advisor" Nicholas Petreley's definition of SOA:

a networked subroutine

No wonder Joe's not sure about it! Nicholas' definition is closer to that of a web service and even that's being generous!

Joe rightly points out that the definition completely ignores the 'A' of SOA and comes up with his own alternative to address that limitation:

an architecture of services

But that suggests that SOA is something that you build - an end-product. It isn't. Architects in the real world don't create architecture: they do it! That's why they are called architecture practices.

Back in May 2005 in our first report on SOA, which set out to provide a big picture view of SOA, we proposed the following definition:

SOA is the disciplined approach through which an IT organisation manages the lifecycle of IT services, and assures their delivery, in a way the reflects business process priorities

As our SOA definition suggests, we see the ultimate value of SOA as shaping a service-oriented perspective on IT delivery, from top to bottom in the IT organisation. Service orientation can apply just as much to business architecture as it can to solution and technical architecture. It may not be quite as simple as Nicholas' definition but I think it more accurately reflects how thinking about SOA has moved on since the heady days of "SOA as software development and integration based on web services"

ECM vendors collaborate on interoperability standard

2008-09-11T04:39:34Z

Yesterday EMC, IBM, and Microsoft jointly announced Content Management Interoperability Services (CMIS) - a new specification designed to enable interoperability between content management repositories. The proposed standard, which was also being submitted to the open standards consortium OASIS yesterday, will create a common interface for accessing content stored in compliant repositories, simplifying the process of integrating business applications with enterprise content management (ECM) systems, particularly in a mixed environment with products from multiple ECM vendors - a situation that is common among enterprise organisations.

The core ECM focus areas for version 1.0 are collaborative content creation, and delivery of content through portals and mashups, with support for applications such as workflow/BPM, archiving, compound document management and electronic legal discovery to be built on top of the CMIS interfaces. The specification provides support for both REST- and SOAP-based interfaces.

The three primary parties in the development of the standard have been working on its development since 2006, and have since been joined by fellow competitors in the ECM space Alfresco, BEA/Oracle, OpenText and SAP.

I have to say that this is a welcome move by the ECM vendors - a standard of this kind is well overdue, and it is encouraging that so many of the leading players are on board. Clearly the implementation of such a (proposed) standard will not happen overnight - and approval of the standard by OASIS is not expected until the second half of 2009. However, we can expect the vendors involved to begin introducing CMIS-compliant code before then, especially since a key goal of the specification was to enable it to be developed as a layer that can sit on top of existing content repositories, rather than requiring them to be redeveloped from scratch (compared to the related JSR 170 standard, for example). In fact, the Alfresco website is already offering up its draft CMIS implementation for preview by the developer community.

A risk to the specification's success is that it falls into the same trap that befell the ANSI SQL standard. This provided a standard way of accessing data repositories, but allowed vendors to include their own "tweaks" which locked people in. The CMIS vendors acknowledge that CMIS is not trying to cover everything - for example security and administration is left to the individual applications - and clearly some products will have differentiating capabilities that are not covered by the standard, increasing the risk of deviation. However, despite this risk, CMIS is a positive step for the ECM market.

It is also worth noting that the standard has much wider implications than just ECM - certainly any organisations looking to implement collaboration technologies should keep an eye on the progress of the standard, and should also challenge their collaboration software providers on their plans, as CMIS should make it much easier to manage collaboratively authored content in the same way as any other organisational content.

Software AG goes in an interesting direction for SOA governance

2008-09-09T09:16:14Z

As part of yesterday's release of the latest iteration of its webMethods Insight product Software AG announced an OEM partnership with Progress Software. This announcement adds the Actional runtime SOA management and monitoring technology (which Progress acquired back in January 2006) to Software AG's existing Centrasite design-time governance capabilities (which were bolstered by the acquisition of Infravio in September 2006) and the runtime policy enforcement provided by its webMethods X-Broker and partner Layer 7's XML Firewall.

The incorporation of runtime SOA management and monitoring functionality into Insight is a necessary evolution of Software AG-webMethods integration strategy that we commented on just over a year ago. It's long been our position that SOA is more than a standards-based approach to software development and integration. The business value of a service-oriented initiative depends on a recognition that software services are experienced, just like their real-world analogues. The quality of that experience depends on a governance approach that extends throughout the service lifecycle, where the contracts defined when services are designed are subsequently enforced through policies once they are deployed and running - and where runtime metrics are captured to provide insight into the service level quality that is actually exeprienced. Furthermore, those metrics can be used to inform and support change management processes, so closing the SOA lifecycle loop.

Whilst the announcement doesn't come as any great surprise, the source of the runtime management and monitoring functionality does. When Oracle confirmed it's intention to acquire BEA, I said:

It [the acquisition] leaves some of the other bigger specialist players - TIBCO, SoftwareAG (and to a lesser extent Progress and Red Hat) in an interesting position. On the one hand they will be more attractive, particularly for SOA and BPM, to customers looking for an application-independent infrastructure offering.

Software AG has gone to a potential competitor for the mantle of best-of-breed, specialist alternative to the likes of IBM, Microsoft and Oracle. If you had told me on Friday that Software AG was going to strike an OEM deal for SOA management and monitoring I'd have put my money on AmberPoint, which has historically been the OEM of choice for the likes of BEA and TIBCO.

I am not quite sure what to make of this decision. AmberPoint doesn't compete with Software AG directly and has established a healthy and growing customer base, as well as partnerships with some of the leading systems integrators - and a technology partnership with Software AG! Software AG's decision comes not long after Oracle's decision to drop AmberPoint. As we pointed out in our analysis of Oracle's roadmap for the BEA integration, we don't have any hard evidence for Oracle's claims that it had received negative feedback from BEA customers but it's something we will continue to explore. In light of the decision to go with Actional, it will be intriguing to see how the partnership evolves and how things pan out when Software AG and Progress are in a competitive situation.

This acquisition should be welcome news to Software AG customers that have invested in the company's SOA offerings as it will save them the time and effort of plugging the runtime governance gap that existed prior to the partnership. Those embarking on a significant SOA intiative should also give Software AG careful consideration, particularly if they are not wedded to one of the mega-platform providers.

Cisco strengthens collaboration portfolio

2008-08-27T08:32:20Z

Cisco today announced its acquisition (which is expected to close by the end of October) of email and calendaring startup, PostPath, for the princely sum of approximately $215 million. The PostPath offering is Linux-based, and has been designed to drop into a Microsoft network as an alternative to Exchange, with the company claiming to offer an easier migration path from Exchange 5.5 to PostPath than from Exchange 5.5 to Exchange 2007.

This acquisition is a logical step for Cisco, which acquired conferencing vendor WebEx in May 2007, followed by policy management vendor Securent in November. Cisco wants to be a major competitor in the collaboration software market, leveraging its communications background to move up the business software stack. With the exception of its small business email offering WebEx Mail, email and personal calendaring has been a noticeable weak spot in the Cisco portfolio, and by building the PostPath technology into the SaaS-delivered WebEx Connect product (which is gradually becoming the platform for all things collaboration at Cisco), the acquisition means it can offer an alternative to customers, and further fleshes out the Cisco collaboration stack.

The previously stagnant email market has seen a flush of activity recently, with hosted email services such as Google's Gmail introducing increasingly viable alternatives to the costs of maintaining an in-house Exchange environment. While it is unlikely that players such as Google and Cisco will making a major dent Microsoft's Exchange market share in the short term, the competition can only be healthy, and at least prompt Microsoft to address the challenges posed.

I have yet to speak to Cisco directly about the acquisition, so I remain quite speculative about how significant a role the company sees this technology playing in the overall collaboration portfolio. $215 million is a considerable purchase price, although it pales into insignificance next to the $3.2 billion the company paid for WebEx last year. Whether the value of the PostPath technology will justify that investment however, remains to be seen. Integration is a key factor in the WebEx Connect strategy, so it will be interesting to see how effectively Cisco can leverage the PostPath features across the breadth of the collaboration portfolio, rather than simply adding a check in the "email and calendaring" box. For organisations considering hosted collaboration offerings such as WebEx Connect, this acquisition could make Cisco a more interesting proposition, especially if Cisco can leverage the Exchange migration strategy touted by PostPath in combination with both PostPath's and WebEx's Outlook integration.

Collaborative Mind Mapping

2008-07-29T10:34:31Z

I don't usually blog about individual briefings from vendors, but I've just had a fascinating briefing from Mindjet, a company which has developed an interactive, collaborative mind mapping solution based on its established personal mind mapping technology. Mindjet Connect allows multiple users to synchronously edit a central mind map, seeing what each other is editing in real time while maintaining full versioning and rollback, and combining this with communications-centric collaboration capabilities such as group chat, video conferencing, whiteboarding and desktop sharing. With almost 20 years of engineering and market experience, Mindjet should be in a good position to recognise the potential of its core solution, but what I think is interesting is that the company has created a slick, powerful and flexible collaborative application which sets a standard for many of the current new wave of collaboration software vendors. Where many talk about the power and innovation of wikis, I think the new Mindjet Connect solution competes very favourably in this space. I'll be writing an On The Radar report on Mindjet soon.

Businesses Aren't Machines, and Enterprise Architecture Can't Make Them So

2008-07-24T13:15:10Z

Via Service Oriented Enterprise, I recently picked up an Infoworld blog post by SOA journeyman David Linthicum, where he makes a couple of very strange points about SOA and ESBs. It may be, of course, that the post is pure link bait: certainly, David appears to have said some relatively sane things in the past, so that might be it. If it is link bait, I'm going to fall for it now.

In his piece David quotes a representative from iTKO, who repeats the now well-understood insight that in some large organisations, there's a challenge that arises because different groups with SOA initiatives find themselves having to integrate different ESBs in order to pull together implementations for cross-silo scenarios. He then goes on to comment (I’ve taken the liberty of extracting elements of his piece below):

First, if there is indeed 'enterprise architecture' and an 'enterprise architect' then the different divisions should not be using different ESBs, or even an ESB for that matter... Second, considering that my first point is correct (which it is), why the heck are you attempting to integrate these integration engines when they should perhaps be displaced altogether. Because, call me crazy again, that would be cheaper... just to be clear, you determine your requirements, and then the solutions patterns, and then the technology.

The most charitable explanation I can come up with for David's position is that he believes passionately in the transformational power of enterprise architecture. The problem with this perspective is that even where EA is highly effective (and in many places it isn't), it can at best only be one of many forces shaping the way that IT evolves to support changing business conditions and requirements, and each force has its own vector. Some forces, like a good EA team, try and combine business and technology focus, and promote the value of global optimisations, good practice and standardisation. But most of the most powerful forces are business forces, and in 99.99% of organisations, their power, when something really big and important happens, will trump any righteous splutterings emanating from IT departments.

As any experienced IT staffer who's been on the sharp end of a big business merger or acquisition, or even a radical change of leadership, will tell you, businesses don't act like machines that EAs can simply steer so that they tend towards technology optimisation. In fact, it's the opposite: business change forces (new competitors, new product launches, new market launches, new regulations, mergers and acquisitions, and so on) will always drive entropy, tending to push IT estates towards chaos. The best value an EA team can really provide in this environment is to help the IT organisation to absorb these changes with as little stress as possible, and drive consistent, planned responses.

Still, there's always been a vocal (and quite often technically brilliant) part of the IT industry that seems to misunderstand this, and persists in maintaining that once people see beautiful models, they'll modify their behaviour to enable the models to be made real. They see businesses as deterministic machines that can be algorithmically decomposed, analysed, predicted, and shaped. I can only think that David is one of these people.

Unfortunately, no matter how clever your EA team might be, no amount of architecture astronautics can make businesses change their nature.

IBM's identity management becomes user-centric: HP's identity management exit strategy

2008-05-22T09:58:44Z

Courtesy of InternetNews on Tuesday I learned that IBM has added support for OpenID, Windows CardSpace and Eclipse's Higgins Identity Framework to its Tivoli Federated Identity Manager (FIM) offering. As one of the enterprise identity management heavyweights, IBM's announcement is an important endorsement of user-centric identity approaches. Such approaches are still in the formative phase of the adoption curve, particularly in the enterprise, so I see this is an investment for the future for IBM. IBM's significant installed base should help to increase awareness, particularly for organisations supporting external user communities.

IBM's press release provides more details on the user-centric credentials (no pun intended!) of FIM. It also discusses the product's SOA Identity Service, which is designed to address some of the challenges associated with identity lifecycle management and audit where service-oriented approaches are applied to siloed applications with siloed security. These challenges are something I highlighted back in February 2006 and are a barrier to the realisation of the value of SOA as it moves out of project-level deployments. I see the SOA Identity Service as the more important aspect of this announcement, with SOA being a more pressing IT (and hopefully business) concern than user-centric identity.

As an aside, the InternetNews article mentions that the enterprise identity management market

is becoming increasingly competitive with offerings from HP, CA and Oracle

Can't fault the journalist on CA and Oracle ... but HP! Earlier in the year the company announced that it was no longer going to be selling its Identity Center products to new customers: hardly a competitive force. As part of this (hopefully for its customers) graceful retreat from the market, HP announced that it has established an exclusive agreement with Novell whereby the two companies will

jointly offer migration services, HP will resell Novell identity and security management solutions and Novell will license HP Identity Center technology

When HP originally announced that it was exiting the market, it stated that it would continue to support and develop Identity Center for its existing customers so I was somewhat surprised to see it offering a migration programme. I wonder whether those customers didn't see this as an effective way forward for what is critical infrastructure. Whilst the programme was a surprise, the partner wasn't. Where else could HP have gone? BMC, CA or IBM: hardly, given the competition in the IT service/systems management markets (and numerous others in the case of IBM). Sun: difficult given competition in the hardware space. Oracle: would have made things difficult for HP's SAP alliance team. Microsoft: lacks the heterogeneous environment support and breadth of functionality that HP's customers need. So, whilst I am sure the sentiments behind Ben Horowitz's (VP and GM, Business Technology Optimization, Software, HP) statement that HP chose Novell

because of its outstanding set of technologies, recognized market leadership and tremendous commitment to working with HP customers

are real, the company didn't have too many others to chose from!

Which comes first: process or service? Part 2

2008-05-13T04:03:26Z

The question of how to combine BPM and SOA came up a lot here at TIBCO's TUCON user event - and, a little disappointingly, the standard response seems to typically revolve around reinventing the three-tier architecture of the 1990s, just with more scope and scale.

I pointed out in the previous part of this post a few ways in which that perspective is too short-sighted. It's OK to view BPM and SOA as both essentially technology approaches to building and integrating applications, but this is a perspective that misses a big part of the potential business value of the combination.

What we're starting to see, though, in a few advanced organisations, is how top-down, business-driven approaches to service orientation and business process thinking can combine with bottom-up, technology-driven approaches. The model that we see links an approach to business architecture that leans on the concepts of process and service to describe business fundamentals, with an approach to technology architecture that uses the same concept to describe the operation of automated systems. The same concepts are used at multiple levels of abstraction and composition/decomposition, so the link is seamless.

To make this link, the concepts of process and service are united through a third concept: outcome. The middle section of the diagram below, which outlines a process- and service-oriented view of business architecture, calls this out.

This is how it lays out:

Outcomes are desired results. An outcome at the highest level is likely to be something concerned with the core value of the organisation, financial performance, etc. At this level, outcomes might link very straightforwardly to mission statements. At lower levels outcomes are going to be concerned with operational results - for example "product is delivered".

Services are commitments to achieve outcomes.

Processes are the methods through which outcomes are achieved.

One of the realisations that should come when you think about this approach is that service-oriented thinking can "drive" process thinking - but not only because technical process implementations can be wrapped with technical service interfaces, as I mentioned in the last post. More importantly, service-oriented thinking should drive process work because when you define business services (commitments to achieve outcomes) you're actually providing business context that shapes the KPIs and goals that you need to set for processes in BPM initiatives.

Another way to explain this aspect of service orientation is like this: when you model a process, and define a KPI and a target for that KPI, you're actually modelling aspects of a service "wrapper" for the process, as well as the process. You're defining what the commitment to achieve the outcome looks like, as well as the method you'll use to achieve the outcome. It's only when you start to think in terms of outcomes (and then services and processes) that this becomes clear, though.

There are other ways in which SOA and BPM can be intelligently combined to add value to both that aren't just about simplistic views of integration (and I'll try and get to some of those in future posts, watch this space) - but I think this is one of the most important. It's important because it helps people get their heads around a way of linking business architecture work with technical architecture work - with one consistent set of concepts. To date, there haven't been many ways to do this, and our research suggests that few organisations manage to make the link effectively today.

To come back to the post title: when you start to think about outcomes as a core concept in business and technology architecture, it becomes clear that it's not accurate to say either that services come first, or processes come first: the truth is that *outcomes* come first, and services and processes are two sides of the same coin in achieving the right results.