Blog Archives

Last week, the ebizQ site posted a forum discussion on the subject “Why Hasn’t BPM Taken Off Like ERP or CRM?”. Hre is the reply I posted in the forum.

When we work we actually execute one (or more) of the "business processes" of our company. I think that "business processes" are, actually, part of the plumbing of each enterprise. At a point that, sometimes, it is "hard" to describe it because we sort of "live it".
So, in that matter, BPM should be the obvious fit.

The fact that it is has been "hard" to introduce it in the enterprises makes me thinking to the following:

1. A business process which is not documented gives the possibility to be "adapted" more rapidly. Actually, a pre-requisite for adopting BPM will be to document what needs to be automated and managed
   So, the perception may be that the company would be “more agile” if something could be changed without running into a big Change Management process.
   One could, also, think that something that is “not documented” may not be accountable also…. but this may certainly be the “bad guy” who speaks in my head…
2. A significant business process often spans several domains.
   Formally describing it may introduce negotiation issues across departments and may imply some organizational changes.
3. Once a process is described and ready to be deployed, an owner will likely be required.
   The owner may not be clearly identified yet and this may require some further negotiation. And may imply,once again, some organizational changes…
4. As Nicholas Carr was saying in his book “The Big Switch”, it is easier today for companies to adapt themselves to the business processes embedded in the CRM and ERP tools they buy instead of investing time to describe and negotiate company specific business processes….

This said, I think that the maturity of the market and the maturity of the products are now helping a lot in the adoption.

I received a couple of wake-up alerts from some friends about the noise that Anne Thomas Manes article “SOA is Dead; Long Live Services” has made. The result of this noise has been: “Since SOA is Dead, what are we going to do next?“.

When better reading the article, though, what I think Anne actually wrote was that the need for a Service Oriented Architecture is here and well alive. What has to be revised is, probably, the hype around the all-powerful-magic-acronym, i.e. SOA.

I think the main point that Anne makes is that SOA has an interest if it is part of a real transformation, that goes beyond the tools or the IT projects or the tools themselves. This seems to be confirmed by the following quote from Anne’s post:

Business people no longer believe that SOA will deliver spectacular benefits…

…Successful SOA (i.e., application re-architecture) requires disruption to the status quo. SOA is not simply a matter of deploying new technology and building service interfaces to existing applications; it requires redesign of the application portfolio. And it requires a massive shift in the way IT operates. The small select group of organizations that has seen spectacular gains from SOA did so by treating it as an agent of transformation. In each of these success stories, SOA was just one aspect of the transformation effort. And here’s the secret to success: SOA needs to be part of something bigger. If it isn’t, then you need to ask yourself why you’ve been doing it.

The latest shiny new technology will not make things better. Incremental integration projects will not lead to significantly reduced costs and increased agility. If you want spectacular gains, then you need to make a spectacular commitment to change.

I think we experiment this with many of our customers (and, by the way, not only in the domain of SOA….). We are all caught in the spiral of delivering results before we even start working. The ROI is calculated on a quarter-based scale which prevents, so often, from engaging in transformations that could span the next one or two quarters timeframe.
Howard, vice president and service director for Burton Group, expressed last summer a similar concept:

Business executives often conclude that IT pros exaggerate predictions of reusability or underestimate project cost, Howard said. IT professionals are generally bad at presenting the business case for SOA, and need to get better at explaining the long-term benefits in cost and flexibility to CEOs, he said. This is difficult, given that businesses tend to focus on immediate rather than long-term cost savings, and point solutions rather than strategic goals…
..”We can spend a lot of time and energy making all this shared stuff that makes IT more efficient, but it doesn’t solve business problems,” …
..A good SOA project requires leadership from a C-level executive who can spur changes in a company’s culture,…We need to get better at trusting each other as human beings. None of this is really about technology,”
The problem’s not technology: people and processes are at the heart of what’s wrong with SOA as it currently exists in enterprises.

So, the problem comes back to the cultural shift that is required. Anne continues

Although the word ‘SOA’ is dead, the requirement for service-oriented architecture is stronger than ever…
…SOA is survived by its offspring: mashups, BPM, SaaS, Cloud Computing, and all other architectural approaches that depend on “services”

A couple of years ago, I wrote an article, “Two Faces of the same coin”, in which I started to develop the concept that the “Process Factor” is actually at the heart of the SOA game. What I think is that the difficulty to push a BPM-based approach resides in the lack of this cultural shift, which manifests itself in the difficulty of an organization to put itself under discussion and to reconsider the way in which internal power is distributed.  One of the evidences of this is that it is easier to push for a “messaging-based” integration instead than a “BPM-based” integration. The reason, in my opinion, is that when a “messaging-based” approach is pushed, no change in the internal power distribution is required. On the other hand, a BPM approach implies that someone clearly identifies a process and that someone is clearly appointed to “manage such process”. Even in an “undocumented process” already exists in the organization, the very fact that it is “formally defined” scrambles the power positions. And this is something that people do not accept very openly.

In this sense, I agree with what Anne wrote. The tools or the projects (especially if they are big) by themselves are not able to promote the change that is required. If SOA means flexibility, it needs to go hand-in-hand with a flexible organization, one that is willing to adapt.