A comprehensive analysis of IBM's BPM Suite

After months of tweaking and review, our coverage of IBM's BPM technology offering is now live. It joins our coverage of Appian, BEA (we're keeping an eye on this, of course, and will update it as soon as is practical), Lombardi, Software AG and TIBCO.

We've been working on this assessment since the autumn of 2007: the delay is mostly due to the breadth of IBM's portfolio (the assessment report runs to 33 pages, whereas most of the others come in around 20 pages) - combined with the fact that, just as we were about to finalise the report, IBM changed its portfolio positioning, introducing the BPM Suite. Anyhow the effort has been worth it - we think the result is pretty comprehensive and definitely worth reading if you're in the process of selecting a BPM technology vendor.

The IBM BPM assessment report is available as part of our Guest Pass library, here; the detailed comparative scoring information, which you can personalise in line with your preferences and constraints, lives in the online vendor comparison tool that's part of our BPM continuous advisory service. Although this service isn't free, you can get a 7-day free trial, so you can use the tool now to see how IBM stacks up in the context of your own environment and preferences - just fill in this form.

Next up is Pegasystems - the assessment process is already underway.

Labels: BPM, ibm, MWD

posted by Neil Ward-Dutton @ 2:41 PM 0 comments permalink

Two new BPM reports

We just published two new "On The Radar" reports on business process technology vendors in our open "Guest Pass" research library. Both vendors are taking an approach that's outside the mainstream, and both are focusing primarily on opportunities with small-to-medium businesses.

RunMyProcess provides a process design and deployment platform that's been designed up-front to be delivered through a software-as-a-service (SaaS) model - aimed at helping SMEs with commitments to investing in SaaS integrate their applications and augment them with hosted process flows. Colosa, on the other hand, offers an open-source BPM technology toolset, ProcessMaker, that's entirely written in PHP.

We hope you enjoy them! As always, you can access these reports with a free subscription (you can enrol here if you're not one of the 3,000 or so existing members).

Labels: BPM, Colosa, MWD, RunMyProcess

posted by Neil Ward-Dutton @ 10:53 PM 0 comments permalink

More BPM coverage, and our other blog(s)

In my recent post highlighting our new line of services, I neglected to mention an important facet of our new BPM continuous advisory service, and the other services we're working on: each service has a companion blog.

The "service blog" allows our analyst teams to not only highlight new research in the service, upgrades, outages etc - but also highlight other research or information out there that's likely to be of interest to anyone working in the area of service coverage. The idea is to make each service blog a valuable resource in its own right.

Here's our new BPM service news blog. The latest post highlights the addition of coverage of BPM specialist supplier Appian.

In keeping with our philosophy, anyone can subscribe to the blog - it's not exclusively for our paid-for subscription customers. Anyone can access the Appian assessment, too - it's part of our "guest pass" research library that we're continuing to add to, even though we're now also offering paid-for subscription services. Just sign up for free and you can look at what we think of Appian's BPM offering, as well as checking out BEA, Lombardi, Software AG and TIBCO. If you're a paid-for subscription service licensee you'll get access to additional data that will help you compare these vendors side-by-side, in the context of your own environment and priorities - as well as gaining access to exclusive BPM research study findings, best-practice case studies, one-on-one analyst access, and more.

Of course, if you want to see how all this paid-for subscription stuff looks, you can sign up for a free trial of that, too... it's easy.

We'll be adding IBM to our BPM coverage in the coming week or two, and Pegasystems should follow in the next month. If you want to make sure you're up-to-date with what we're doing in BPM, just point your feed-reader here.

Labels: BPM, MWD

posted by Neil Ward-Dutton @ 8:03 AM 0 comments permalink

Which comes first: process or service? Part 2

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.

Labels: BPM, EA, SOA

posted by Neil Ward-Dutton @ 3:50 PM 1 comments permalink

Which comes first: process or service? Part 1

Over the years I've been helping to run MWD I've been to quite a few events, talked to many enterprise IT folks and talked to many tech vendors, too - and one of the topics that comes up most often is the relationship between BPM and SOA. There's been a bit of a run on the topic in the blogosphere lately. First, I was alerted to this post on CIO.com via the EDS fellows' blog in a post called SOA is a Business Process Architecture. At around the same time, I read The Problem with Process by Nick Malik (always good to read).

Too often, in presentations and papers, I see diagrams that replicate the old three-tier architecture of the '90s, but with a twist: instead of user interface, business logic and data access layers, now I keep seeing portal, BPM and SOA layers. Portals provide user interaction, and invoke processes; processes invoke services. Job done.

Looking at BPM and SOA purely in this way is short-sighted, disingenuous and dangerous. It looks at both initiatives through a very focused lens, and essentially says "BPM and SOA are about building and integrating applications". Not your father's applications I'll grant, but applications nonetheless - things with hard boundaries that have little awareness of other systems or resources that might exist, and little conceptual relationship to broader architectural or business considerations.

The first, and most obvious, point to make that blows this kind of picture apart is that it's mind-numbingly straightforward to wrap a process (or at least the initial invocation of a process) as a service. So *now* what's "on top" - process or service? This realisation has led to more enlightened commentators advocating that organisations consider processes and services more like a lasagne, with alternating layers of the two concepts. Services expose processes, processes call services, etc etc ad infinitum.

However even here we're only part way to the real answer, because this view also stems from seeing both BPM and SOA primarily from a "bottom up", software development- and integration-centric perspective. Of course, many people refute a view like this, and point out that "BPM is a business management approach, and SOA is a technology architecture approach - you can't lump them together so easily". In other (very simplistic) words BPM is a top-down, business-driven initiative, whereas SOA is a bottom-up, technology-driven initiative.

The two articles I've linked to above are great because they start to take a deeper look at the architectural and conceptual relationship between service and process. Both EDS Fellow Fred Cummins and Nick Malik start to pick away at the simplistic views that seem to hold sway in the minds of many at the moment.

Neither quite take the argument as far as they might, though. Through our industry research (for our book as well as our various free reports and consulting gigs), we've come to see that the value of both BPM and SOA comes from considering them neither purely as bottom-up initiatives focused on improving the development / integration of applications and resources, nor as top-down initiatives focused on exploring and elaborating business architecture. We already have a champion in the case of "top-down SOA" - the OASIS SOA Adoption Blueprints team. The real insights come, I think, when you see how top-down *and* bottom-up perspectives of service-orientation *and* process-orientation can all come together in a more holistic view of business and technology architecture.

I'll expand on what such a view entails in a Part 2 of this post, in the next few days.

Labels: BPM, EA, SOA

posted by Neil Ward-Dutton @ 9:55 AM 0 comments permalink

Assessing technology: life after MQs and Waves

Earlier in January, BPM consultant-cum-analyst Sandy Kemsley made some interesting points about how the big analyst firms "parcel up" their analyses of technology areas and vendors. Her catalyst was an observation on the way that Gartner and Forrester each segment the BPM technology space.

BPM isn't unique, but it is challenging as a segment for the big analysts, because there are so many viable vendors offering interesting technologies that customers should know about. So - what to do?

Forrester has taken a "divide and conquer" approach, splitting the segment up into four sub-segments: human-centric BPMS (Java), human-centric (Microsoft), integration-centric and document-centric. If a vendor offers technologies which fit multiple of those sub-segments, Forrester covers them in each segment - each with its own Wave.

As Sandy points out, the challenge of Forrester's approach for the customer is that real-world scenarios don't segment themselves according to Forrester's criteria. Most companies have both Java and Microsoft platforms in place, and need to work with both. In most large companies, processes often have human-centric elements, integration-centric elements and (yes) document-centric elements. The customer has to do a fair bit of work to find out what's going to suit them best.

Gartner, on the other hand, produces just one Magic Quadrant for BPM technology - but by necessity (I imagine to do with usability rather than analyst resources - but this is pure speculation, I don't have any "Gartner insiders" to help me with this) it has scoped a number of what I would say are important vendors out of its analysis. No Microsoft, K2, Intalio, Vitria, OpenText. This is puzzling (to me at least). By representing the whole of the BPM technology space with one logical model, the result is a rather "vanilla" perspective.

This is hardly news of course. So why am I so exercised by it?

The answer is that we think there's a better way to provide comparative vendor analysis to customers.

A key problem underlying both Forrester's and Gartner's approaches is that in order to work within the constraints of their analysis and publishing infrastructure and processes, they're having to make quite a few assumptions about what kind of technologies and companies customers are interested in, and why. The hope, presumably, is that any mismatch between customer expectations and the analyst firms' delivery methods will be met through one-on-one consultation with analysts, who will interpret their own papers on the phone, (hopefully) in the context of their customers' needs. If a you don't have an opportunity for one-to-one consultation, then... it's up to you to try and figure it all out.

Wouldn't it be better if there was an approach that made as few up-front assumptions as possible, but instead provided an online, hosted interactive environment, accessing data from one broad vendor and technology database, where customers could shape analysis and recommendations themselves by providing information about what was important to them and what wasn't?

Such an environment would take customer "preferences" and use them to tune the rankings that were presented. Ideally, preferences wouldn't just be focused on elements of functionality, but also on attributes of vendors themselves (for example - do you only want to buy from big companies, or companies with offices in your geography?), technology dependencies (for example - do you only want to buy from companies who can run their software on Linux or support a certain standard?). Customers wouldn't have to provide such "preferences" - but the more information they provided about their constraints and interests, the more relevant the analysis would be.

Does that sound like too much to ask?

We don't think so. We think customers of industry analyst firms often have to do too much work in order to get relevant advice. So we're using approach described above for new MWD analyses of BPM technology offerings and Enterprise Collaboration technology offerings. We're launching new interactive, online comparison and ranking tools for these two areas as part of two new advisory services which will launch in the coming months.

Oh, and if this sounds interesting, don't worry that you'll have to pay an extortionate amount of money to get access to these tools. We'll be offering free trials to enterprise IT departments :-)

Watch this space.

Labels: BPM, collaboration, forrester, gartner, MWD

posted by Neil Ward-Dutton @ 11:22 AM 0 comments permalink

Pure-play partnerships: helping light the way to BPM + SOA?

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.]

Labels: Appian, BPEL, BPM, Cape Clear, ESB, Lombardi, sonic

posted by Neil Ward-Dutton @ 10:50 AM 0 comments permalink

Please don't hire a VP of SOA

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.

Really? I haven't seen that. If some organisations (maybe US based ones?) are doing this, I hope they're more focused on business transformation than on IT implementation - and that SOA isn't in their job title.

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.

Although it's slightly off the topic of this post, I wonder how many people fitting this description are out there? If SOA success relies on you hiring someone with all these capabilities, then I think we're going to see a hell of a lot of failures. This is where I get seriously worried though:

This position reports directly to the CIO with dotted line responsibility to the COO, and will be responsible for a seven-figure annual budget... job responsibilities include:

• Provide executive-level management leadership to all architecture efforts across the enterprise. The directors of Business Architecture, Enterprise Architecture, Technical Architecture, Data Architecture, and Network Architecture will all be your direct reports.


• Drive all Business Process Management (BPM) initiatives enterprisewide. Coordinate with process specialists across all lines of business, and drive architectural approaches to business process.

Ummmm... so this role reports to the CIO, but drives all BPM efforts across the company? Even though the note says "even though the VP of SOA reports to the CIO, the role is primarily a business role" this is pure fantasy. Unless you're in a small-to-medium business it's just not practical to make this happen.

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.

Labels: BPM, SOA, toddbiske

posted by Neil Ward-Dutton @ 4:50 PM 0 comments permalink

Not all processes are created equal - at least under the lens of IT

Labels: BPM, collaboration, enterprise 2.0

posted by Neil Macehiter @ 5:15 AM 0 comments permalink

Who do you put in a Centre of Excellence?

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?

Labels: BPM, governance, SOA

posted by Neil Ward-Dutton @ 8:20 PM 1 comments permalink

Ah yes, it's BPM... but which BPM is it?

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.

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".

UPDATE: Some folks from BEA got in touch, and asked "why isn't BPM in your list"? I had no idea I was so influential! ;-) So, for the record... BEA is an interesting BPM vendor, as it has some integration-focused history with its WebLogic Integration capabilities, but it's garnered a much more interesting position by buying former BPM specialist Fuego. It now straddles both camps - as, strictly speaking, does TIBCO (following its acquisition of Staffware).

To make things fair, I should perhaps call out some other vendors not mentioned in the original list above: Adobe, Cordys, DST, EMC Documentum, Fujitsu Software, Global 360, Handysoft, Intalio, K2, MEGA, Metastorm, Microsoft, Proforma, SAP, Savvion, Ultimus, Vitria...

Labels: BPM

posted by Neil Ward-Dutton @ 9:07 PM 0 comments permalink

Oracle proposes to buy BEA

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.

Labels: BEA, BPM, ibm, Microsoft, Oracle, Progress, Red Hat, SAP, SOA, Software AG, TIBCO

posted by Neil Macehiter @ 4:57 PM 2 comments permalink

More big vs small thinking: SOA vs BPM

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."

Labels: architecture, BPM, Pegasystems, SOA

posted by Neil Ward-Dutton @ 3:25 PM 1 comments permalink

Microsoft server and tools is now part of the business division

Labels: BPM, compliance, ITSM, Microsoft, SOA

posted by Neil Macehiter @ 5:19 PM permalink

Has Microsoft got BPM? Part II

Back at the beginning of March I asked "has Microsoft got BPM?". At that time I hadn't had the opportunity to get a briefing from Microsoft on its recent BPM moves, but now I have.

So - has Microsoft got BPM? Yes and no.

Microsoft is not about to become a fully-fledged BPM solution provider. Rather, Microsoft is attempting to do to BPM what it attempts to do in all the areas of enterprise software it's played in (think DBMSs, development tools, middleware, portals, etc etc) - commoditise the core technology and make it part of an integrated software platform that's digestible by mainstream medium-to-large enterprises. Sun wasn't the first company to realise that "volume drives value" - it's taken a leaf out of Microsoft's book.

So a big part of the focus is on providing the technology foundation for BPM. Here Microsoft has a couple of formidable weapons:

1. Office. Office is the defacto productivity suite in enterprises - and with Office 2007, is becoming the front end infrastructure for BPM scenarios in Microsoft's world, as well as a suite of apps. It's an environment very familiar to business people, so if those people are looking to get a BPM initiative started, Microsoft's proposition could look pretty attractive. [If you don't believe us about Office, see this research from our partner Freeform Dynamics.]


2. Workflow Foundation. This is a core component of .NET 3.0 (the native programming model for Longhorn Server and Vista). It provides embeddable workflow execution services for both highly structured business process automation scenarios and less structured, collaborative scenarios. It's becoming the foundation of both BizTalk Server 2006 (which will drive structured process automation scenarios) and Sharepoint 2007 (which is more suited to unstructured, collaboration-focused processess). Workflow Foundation really is neat.

The big caveat, of course, is that all these weapons only really come into play if and when organisations buy into the current tranche of product releases - Office 2007, BizTalk 2006, Visual Studio "Orcas" and the Visual Studio Tools for Office (VSTO), and .NET 3.0.

Although all these pieces are either released or coming very soon, where customers have a significant investment in Microsoft in these kinds of areas, it's far from certain that they will upgrade or migrate quickly. Microsoft's success in engineering an integrated platform of software infrastructure is also a weakness, in other words - people who buy into it tend to have a lot of capabilities riding on it. That drives caution and risk aversion.

Microsoft's BPM foundation is mainly focused on the development and deployment of processes, and although BizTalk 2006 has some BAM capabilities (through integration with SQLServer OLAP and BI functionality) Microsoft isn't focusing primarily on providing tools for modelling and simulating, analysing or optimising processes. It's developed a coterie of "Business Process Alliance" partners to fill in the gaps, and also to help it accelerate demand for the new versions of its key BPM foundation components. When it comes to Workflow Foundation in particular, the huge Microsoft-focused packaged application vendor (ISV) community which so effectively drove adoption of SQLServer will also be a key element of Microsoft's strategy.

So on paper Microsoft has a good BPM story - if you're prepared to put a lot of skin in Microsoft's game and if you're prepared to upgrade to the latest Microsoft infrastructure. The company isn't yet pushing the base technologies aggressively and directly to customers, but it is priming its partners and channels and these will drive uptake.

Another interesting angle to the technology piece of this story is the recently announced BizTalk Services offering - a set of integration capabilities "in the cloud" which offer a hosted complement to on-premise BizTalk integration implementations. These services are designed to, in theory (it's early days), make the creation of highly federated, distributed service and process networks much more simple to develop and operate. It's a fascinating development that has some parallels with what Salesforce has been doing with the Salesforce Platform Edition, and (a little less so) with what BT is attempting to do with BT Integrate.

One last small thing though. If it's serious about BPM, at some point Microsoft's going to have to sort out the difference between this BPM and this BPM...

Labels: BPM, BT, Microsoft, SaaS, Salesforce, Workflow Foundation

posted by Neil Ward-Dutton @ 9:01 PM 0 comments permalink

Has Microsoft got BPM?

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!

Labels: BPM, Microsoft

posted by Neil Ward-Dutton @ 9:49 PM 0 comments permalink