Enterprise Service Bus (ESB) players often talk about their ability to support BPEL, and this is often mistaken for BPM support. But BPEL is a misleading beast (as I've blogged about previously). It's not a bad technology for helping IT folks with declarative specification of service-to-service integration processing, but it's not the same as BPM. This is often overlooked, and is where a good deal of the confusion surrounding BPM stems from.

The gap between BPM and BPEL is one perspective from which Cape Clear's recent tie-up with Appian - and Sonic's earlier tie-up with Lombardi - are newsworthy.

BPM initiatives need to be supported by technology that can flexibly integrate existing application, system and information assets into executing process instances. BPM pure-plays like Appian and Lombardi are both frequently tested against larger platform vendors (think IBM, BEA, TIBCO, Software AG, Oracle, etc) and, when standing alone, their integration stories are less comprehensive than those of the big boys.

Conversely, many SOA initiatives are pursued in the context of business process integration and improvement initiatives, and ESB specialists like Sonic and Cape Clear are frequently tested against the larger platform vendors, which on paper can offer more sophisticated support for runtime management of business processes. They certainly have more engineering and marketing resources.

So figuring out that partnerships between BPM specialists and ESB specialists are sensible is hardly rocket science. There are plenty of organisations out there which (for whatever reason) don't want to spend too much money with the big platform vendors, preferring instead to work with specialist suppliers.

What's more intriguing to me is how the separation of technologies forced by these partnerships can actually encourage good practice in "BPM + SOA".

It's often the case, where BPM and SOA tools are presented as part of broad tool suites, that separating business-focused process models from more technical models and service integration models is not encouraged in any meaningful way. Unless you work hard to keep these different models separate, over time artifacts which by rights should remain separate end up bleeding across models and it becomes harder and harder for different teams and stakeholders to remain actively involved in the programme, using tools and models that make sense to them.

By separating business-focused BPM modelling tooling from BPEL tooling and ESB configuration tooling, but still making it easy to link and reference where necessary between models and tools, these partnerships may well help to enforce good practice. It'll be really interesting to see how these partnerships develop, and whether the participants can make 1+1 = 2 (or more). If they can, then I agree with Sandy: these partnerships have the potential to create market-leading positions.

[Another interesting angle, IMHO, to the Appian-Cape Clear tie-up that's not really been picked up is that both companies are active in the area of SaaS. Cape Clear is doing quite a lot of work enabling integration of SaaS and on-premise capabilities for customers; Appian has a SaaS implementation of its technology called Appian Anywhere.]

Posted by neilwarddutton in Architecture • BPM | Permalink | Comments (0) | TrackBacks (0)

This might sound like an odd title for a post, but I was prompted by this ZapThink ZapFlash, via the ever-watchful Todd Biske.

The ZapThink note starts off talking about the challenges in SOA adoption that come from organisational issues - specifically, challenges that arise from situations where tactical decisions continue to trump strategic decisions. All these are good points well made (FWIW, when trying to educate people about the importance of enterprise architecture, governance, BPM and SOA, we talk about the strategic importance of global vs local business optimisations).

However the note all goes wrong when it goes on to say:

Among the various approaches organizations take to overcome such obstacles, one technique is increasing dramatically in popularity: bringing on board a new executive responsible for the enterprise's SOA initiatives.

The note then goes on to suggest some ideal characteristics for such an executive:

The ideal candidate will first and foremost be a business process guru who also has broad experience in IT. Must have a background in architecture and ten-plus years in increasingly senior management roles. Must be able to communicate to both business and technical audiences. The successful candidate will be part team builder, part evangelist, and part bean counter.

Think of a concrete example of a process transformation - something related to CRM. There's a wealth of salutory tales out there about the folly of driving CRM initiatives (which are process improvement/transformation initiatives) from within IT: CRM initiatives need to be owned and driven by the business. Extrapolating out to process improvement/transformation more broadly, even if transformation of some process areas isn't in the same league as that involved in CRM (and you'd have to argue hard to convince me of that) then I'd still argue that business leaders have to share ownership of process improvement and transformation initiatives. Real BPM cannot be driven by someone reporting to your average CIO - not even by a $200k-a-year uber-architect-cum-process-guru who's equally happy wearing patent leather shoes or pizza-stained trainers.

Of course there is a need to bring people together to push through significant IT and business transformations, such as those required to make the most of the promise of SOA and BPM initiatives. I would wholeheartedly back ZapThink and others in that. But in the real world - particularly in large organisations - people who drive these change programs aren't able to directly push everything, as ZapThink seems to be advocating: they have to be influencers and coordinators first and foremost. Think of an enterprise architect you know. If they're successful, chances are one of their key skills is in how they influence others' behaviour and get different stakeholders working together.

Even if you believe that one role can drive all this - especially from within the IT organisation - then your VP of SOA will be a transitory role. If your SOA initiative succeeds in its mission, then SOA becomes part of the furniture, and when that happens, roles like this one melt into the responsibilities of other, "business-as-usual" roles. If your SOA initiative doesn't succeed, then SOA is seen as yet another over-hyped industry silver bullet - and your $200k-plus hire is now seen as an expensive mistake.

Posted by neilwarddutton in Architecture • BPM • IT Governance | Permalink | Comments (0) | TrackBacks (0)

Arch BPM blogger-cum-analyst Sandy Kemsley references an interesting conversation she had with some webMethods customers at Software AG's Integration World event where the customers "pooh pooh the BPM vendors who don't provide the whole integration stack". To me, this is interesting because (as Sandy calls out) "these customers are coming from the traditional EAI-type usage of webMethods".

One of the challenges in the growing market for Business Process Management (BPM) technology is the fact that there are many different technology providers bringing tools to the market, and each has its own technology background and heritage customer set with its own expectations. In truth, there isn't "one BPM".

What makes things particularly challenging is that it's very difficult to find a vendor that can truly support a rich range of different types of processes from the perspective of modelling, analysis and optimisation; while at the same time supporting complicated integration requirements. The task is particularly difficult if you're looking for an elegant technology solution with no duplication (some vendors can point to good coverage of all the main functional requirements today, but they can only do this by bundling overlapping and poorly-integrated products and technologies together).

It's a bit of a simplification, but broadly speaking, vendors fall into a "business process specialist" camp, where sophisticated modelling, monitoring and optimisation tools are provided; or a "process integration" specialist camp, where the main centre of gravity is being able to orchestrate services and applications in relatively sophisticated ways. The smaller, specialist vendors (such as Lombardi, Pegasystems, Singularity, Appian) fall into the former camp; the larger, generalist vendors (such as IBM, Software AG, TIBCO, Oracle) fall into the latter camp. Interestingly, BEA (and also TIBCO) actually span the camps as they've both bought pure-plays as well as having integration-centric backgrounds.

Next spring we'll be launching a major research programme looking at the discipline of BPM and the technology you need to support it - but until then the most pithy advice I think that can be given to an organisation looking to purchase BPM technology is:

Understand what, exactly, you want to do with BPM. Understand the key characteristics of the processes you're trying to improve, and equally importantly, who's driving the work - is it business people, IT people or both?

Unfortunately, getting to the bottom of things is not as simple as saying "I need a human-centric BPMS" or "I need an integration-centric BPMS".

Posted by neilwarddutton in BPM | Permalink | Comments (3) | TrackBacks (0)

I've lost count of the number of times I've seen throwaway comments exhorting companies to "create a centre of excellence (CoE) (mostly, for initiatives like SOA or BPM). Vendor / pundit / analyst / journalist: "Having trouble? Establish a centre of excellence!" Customer: "Oh, that's OK then, I'll do that."

But let's take a deeper look. Quite aside from the role that one of these beasts plays (something I'll attack in a future post), what does a best practice CoE look like?

From what I've seen out there in real-world implementations of SOA and BPM initiatives, I suspect that the best results come from having a good mix of responsibilities / personalities in the group. Something like an even distribution across this matrix of perspectives:

Although it's tempting to staff a CoE with good dependable technical people that you understand, you need a good mix of business-focused types and technology-focused types, because those business-focused types will help keep expectations practical, and help keep business people from outside the CoE engaged and willing to help. And it's vital to get a good mix of practical and visionary focus, because rolling out new concepts and approaches to delivering IT capabilities requires both "selling" and getting things done.

That's my view. What do you think?

Posted by neilwarddutton in Architecture • BPM • IT Governance | Permalink | Comments (0) | TrackBacks (0)

Andrew McAfee at Harvard Business school poses an interesting question:

do 'managers' belong on the list of knowledge workers whose jobs are being transformed by information technology?

His question is prompted by a number of interesting examples of the use of IT in areas such as "fluid" building fabrication, sculpture, BMW car design and poker playing. He then goes on to describe, based on the experience of his course teaching, that most general managers do not believe that IT can help them in their roles as leaders, change agents and value generators because:

until fairly recently the profession of general management was actually not one of the ones deeply affected by technology. Prior to the mid 1990s the footprint of most corporate IT -- the sphere of direct influence for a piece of technology -- was the single function or task. This made for a happy marriage between technology and knowledge workers like engineers, scientists, and analysts because these workers stayed within a single function. But general managers, by definition, do not. They're responsible for orchestrating the work of multiple groups. So from their perspective, IT was actually delegable and low level.

This chimes well with some of the points we raise in our March 2005 BPM report (which will be updated next month). In it we highlight that much of IT discussion of business process is actually about the shadow that IT automation casts on real business processes. The real world of business processes is much more complicated than would appear to be case based on what IT can support. There are business processes which serve to differentiate the business and there are those that are a cost of doing business. There are business processes which support day-to-day operational activities (or single functions or tasks as Andrew refers to them); there are those that support management of those operational activities; and ultimately there are those that govern strategy.

IT has historically played a prominent role in support the non-differentiating, operational processes. That role is significantly diminished when it comes to differentiating, management and strategy processes because they are more ad-hoc and collaborative and nature and depend on harnessing and exploiting a wide variety of applications and structured and unstructured information assets.

Andrew believes that the emergence of ERP and the Internet has enabled a new class of business process automation which operates at the level of the organisation and so are more suited to management processes. He also believes that "Enterprise 2.0" technologies (which Angela discusses in the broader context of enterprise collaboration in her recent report), by virtue of their emergent characteristics, promise to do the same and concludes that he is:

comfortable adding 'general managers' to the list of knowledge workers who have very powerful digital tools at their disposal, and who need to learn how to use them well. Does this also seem right to you?

His historical analysis of business process automation certainly seems right to us and we believe that a range of new IT capabilities have the potential to shift IT's supporting role in the direction of differentiating management and strategy processes. However, it's not just about managers learning how to use them well. As we highlight in our BPM and collaboration reports (and more broadly in our analysis of IT-business alignment), these management competencies must also address a broad range of organisational, cultural and governance challenges if these innovations are to fully realise that potential.

Posted by nmacehiter in BPM | Permalink | Comments (0) | TrackBacks (0)

Oracle today confirmed

that it delivered a letter to the Board of Directors of BEA Systems, Inc. (NASDAQ: BEAS) on October 9 in which Oracle proposes to acquire BEA for $17.00 per share in cash. The $17.00 per share offer is a 25% premium over yesterday's closing price of $13.62.

This acquisition has been long-discussed so I can't say I find the news particularly surprising, particularly with Carl Icahn recently upping his stake in the company. I think this just makes it more likely that Oracle's proposal will be accepted.

This is primarily as a market share grab by Oracle. It does plug some gaps in the portfolio - particularly around business process management (based on BEA's Fuego acquisition), where Oracle only has basic BPEL web services orchestration; adds some telecoms vertical market capabilities to complement Oracle's vertical market push and the virtualisation work that BEA has done with the WebLogic Virtual Server Edition. Also, there's the opportunity for Oracle to tap into the healthy Tuxedo base. With a significant chunk of Oracle's profitability coming from maintenance, the revenue from BEA's customer base will suit its business far better than it did BEA which was suffering with its inability to grow license revenues.

This is yet another example of the bigger specialist players getting squeezed out by the industry goliaths - IBM, Microsoft, Oracle, SAP - and the open source, smaller best-of-breed players. SAP's recent acquisition of Business Objects is another example (although that did plug a few more gaps). It 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. On the other, though, taking market share for those customers from BEA is one thing: taking it from Oracle quite another. Ultimately, IBM is the big beneficiary in this regard.

In summary, then, I see: the acquisition going ahead; BEA's customers looking worried as they see themselves with an application-dependent infrastructure stack; IBM looking happy at the prospect of providing those customers with an application-independent alternative; the likes of TIBCO and Software AG pondering their options; and SAP and Microsoft carrying on in there own sweet way.

Posted by nmacehiter in Architecture • BPM | Permalink | Comments (0) | TrackBacks (0)

I was on the way back to the office from a briefing with BPM vendor Pegasystems yesterday, where we'd had an interesting discussion about the relative roles that BPM and SOA can play in business transformation for customers.

We agreed that BPM, done right, is as much of a discipline that organisations can use to transform the way that they do business, as it is a technology (or set of technologies). What's more, we observed that many BPM initiatives revolve around making big changes to the way that organisations deal with customers, partners and suppliers - and creating organisations that are really focused around delivering real service to those other parties.

Let's review that for a second: BPM thinking helps organisations get their houses in order so that they can deliver coherent and quality services (and not just disjointed experiences).

So from a business perspective, it's BPM that delivers service-orientation!

But wait - in IT we're saying that service-orientation comes from something called SOA. And in IT circles, there's a lot of discussion that positions BPM as if it's a layer of technology that sits on top of SOA technology. Kind of like we've just reinvented three-tier application design with BPM instead of business logic, and SOA instead of database access logic.

This "application architecture" lens for BPM and SOA is all wrong. It's another example of small thinking.

The more profitable way of thinking about the relationship between BPM and SOA is not to think of them as a stack of technologies: it's to think of BPM as being about "how" you do things and service-orientation being about "what" you do. Service definitions are definitions of commitments: they say what you will do, how well you can do it, and (possibly) how much it will cost you to use. Process definitions are definitions of work: they say how commitments will be fulfilled, by whom, and under what conditions.

So, BPM and SOA are interlinked - but not because one adds value to the other or because one sits on top of the other: both ideas are two sides of the same "business and IT transformation" coin.

If you do insist on thinking of the world in terms of stacks of technology tools or stacks of models or assets, think of SOA and BPM as alternating layers of concepts and practices. Services define "what" you will do at a given level; processes define "how" services will be delivered. Processes rely on foundation services to get some work done; those services in turn rely on processes of some kind.

I'm sure not everyone will agree with this, but I do hope there's one thing we can all agree on - as Sinatra once sang: "this, I tell you brother: you can't have one without the other."

Posted by neilwarddutton in Architecture • BPM | Permalink | Comments (1) | TrackBacks (0)

I have just returned from a couple of days in Orlando, where I attended a Microsoft Server and Tools Business analyst summit which coincided with the company's TechEd conference. The RedMonkers James and Coté did a great job of live blogging the event (here, here, here, here, here and here) - and there was even some Twittering - but I needed the joys of a 9 hour transatlantic flight to collect my thoughts.

The big news at TechEd and the focus of the analyst summit was Microsoft's Dynamic IT for the People-Ready Business (Dynamic IT) strategy, which the company describes as building

on the company’s Dynamic Systems Initiative and ongoing Application Platform efforts to provide customers with the key areas of technical innovation necessary to make their IT and development organizations more strategic to the business

In other words it's a framework which builds on a number of Microsoft's most significant, but historically largely disconnected, initiatives which is designed to help customers understand how they can be combined to increase the business value of IT. This is long overdue, for a couple of reasons.

First, whilst Microsoft has used language in the past which implies linkage between the different initiatives and associated products, such as 'design for operations' for DSI and .NET, it's not always been clear how the implication becomes reality. For example, how do the System Center management tools exploit operational policy requirements defined in Visual Studio and how do those requirements map to policies defined in Windows Communication Foundation? Dynamic IT sets out to make the linkage explicit.

Second, Microsoft has lacked a cross-company vision for enterprise IT (for want of a better term) within which to frame discussions with customers and around which it can rally the troops. I'm thinking here of things like IBM's On Demand, HP's Business Technology, Oracle's Fusion etc. There's People-Ready of course but I think that's about more than Enterprise IT. Dynamic IT provides Microsoft with a competitive alternative and one that is more reflective of current reality than future aspiration.

There are four aspects to Dynamic IT where Microsoft plans to focus innovation:

* unified and virtualized
* process-led, model-driven
* service-enabled
* user-focused

built on a federated, interoperable and secure foundation. Obviously, it's still very early days but I do think Microsoft has a lot of work to do if it's going to achieve what I believe it hopes to with Dynamic IT.

For example, in his keynote when Bob Muglia talked about process-led, model-driven he discussed process-led in terms of the application lifecycle, BizTalk, Windows Workflow Foundation and Office Business Applications and model-driven in terms of System Center and IT management models (based on Service Modelling Language and the Common Model Library). What he didn't do was explain the relationship between the two. When describing service-enabled, he focussed on .NET, SOA, web services and software plus services, primarily from the bottom-up, developer perspective (consistent with Microsoft's initial foray into SOA) but failed to tie that into the end-to-end service lifecycle - Big SOA - and thus process-led, model-driven. (As an aside, I think Microsoft is also missing a trick when it comes to information and data as a service but that's for another day).

As well as explaining the relationships between the different aspects of Dynamic IT, Microsoft also has to be very careful that it doesn't fall back into the trap of using it simply as a framework for categorising its products. Increasingly, the key concerns of the people it is trying to reach with Dynamic IT don't fall into neat product categories and Microsoft has struggled in the past to articulate the joined-up propositions required to address these concerns because of its focus on product stovepipes (as I discussed here).

What I think Microsoft needs, as I explained during various meetings at the summit, are scenarios and associated case studies to bridge between the framework and the products and emphasise the linkage. This will also serve to highlight the importance of the three foundational aspects - federated, interoperable and secure - which might otherwise be lost and to tie into Core, Application Platform and Business Productivity Infrastructure Optimization roadmaps which Microsoft is using to help customers understand how they move forward from where they are today.

For Microsoft's customers and potential customers Dynamic IT is a positive sign that company is beginning to recognise that you are more concerned with the outcomes from deploying the company's technologies than you are about the technologies themselves or the way that Microsoft chooses to structure itself to develop and sell them. Over the coming months you should be looking to Microsoft to fill out the framework and seek explanations for how the pieces fit together today and how the company plans to enhance that integration going forward.

Posted by nmacehiter in Architecture • BPM • IT Service Management • Software Lifecycle | Permalink | Comments (0) | TrackBacks (0)

The ever-vigilant Redmond watcher Mary Jo Foley over at ZDNet reports that Microsoft's Server and Tools unit (but not the P&L - Microsoft will still report server and tools financials), which is responsible for Microsoft Windows Server, SQL Server, Visual Studio, System Center management products and Forefront security products, is now part of the Business Division, the home of Office and Dynamics.

Mary Jo finds this move 'curious' but I can see the logic. It's hinted at (if you get past the marketing speak) in the company's official statement that it made the move to:

sharpen leadership focus on the company’s top priorities and align its organization for innovation, ultimately enabling it to deliver even more value to its customers.

I think this is all about making it easier for Microsoft to articulate propositions which resonate with the key concerns of senior business and IT people. The reality is that key strategic business and IT initiatives - SOA, BPM, compliance ... - increasingly depend on multiple technologies and associated competencies, which cross traditional stovepipes. Big SOA, for example, is about managing IT work across the entire service lifecycle and so touches project and portfolio management, software development and integration, IT service management. BPM, as the other Neil pointed out, is about Office as much as it is BizTalk and Workflow Foundation.

In the past, the way that Microsoft has been organised has worked against the articulation of such joined-up propositions (that's in part why it took the company so long to talk about SOA). Customers would get different answers to the same cross-cutting requirement depending on which Microsoft stovepipe they were talking to: you need BizTalk and SQL Server; you need OBA and SharePoint. [As an aside, I said much of this in an interview with Microsoft PR earlier in the week].

Obviously, shifting branches of the org chart is comparatively easy (even it is very big). The hard part is going to be changing behaviour, joining up the marketing etc. The creation of the Connected Systems Division back in 2005 shows that the company can pull this sort of thing off (albeit on a smaller scale in the Server and Tools Business as was) and Jeff Raikes, who now owns the combined entity, has the influence and power to drive things through at this larger scale.

I am off to a Server and Tools Business analyst event in just over a week so I will hopefully learn more then.

Posted by nmacehiter in Architecture • BPM • IT Service Management | Permalink | Comments (0) | TrackBacks (0)

In October Microsoft finally got SOA (kind of)... now has it got BPM?

I've not had a briefing on Microsoft's BPM initiative, but I did see the announcement of the Business Process Alliance partner initiative. And I also read Sandy on Microsoft's BPM presentation at the Gartner BPM event - and I for one pretty much always go with what Sandy thinks around BPM.

It's interesting that on Microsoft's website both BPM and SOA topics live within the BizTalk product pages. That might tell you all you need to know. Knowing what I know about Microsoft's software infrastructure market approaches generally, I'm not at all surprised that the meat of its BPM story seems to be "Sharepoint + BizTalk".

Of course Microsoft isn't the only big software platform player giving themselves a BPM makeover - IBM is at it too. Like Microsoft, it's reacting to customer demand for help with BPM initiatives. Revitalised offerings are pledged to arrive soon.

It looks like Microsoft is cooking plans to create a more compelling "proper" BPM proposition over time as the Windows Workflow Foundation gets inserted as a common process automation engine into future BizTalk and Sharepoint releases, but we'll have to wait and see. Just the other day MS announced BPEL 1.1 support on Workflow Foundation, implemented as a Domain Specific Language (DSL), but there are currently no plans to support BPMN. Public commitments for delivering Biztalk on Workflow Foundation are currently vague - beyond saying "in the Longhorn Server timeframe".

If I learn any more I will share!

Posted by neilwarddutton in BPM | Permalink | Comments (0) | TrackBacks (0)