Blog Archives

Why Hasn’t BPM Taken Off Like ERP or CRM?

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.

SOA is Dead; Long Live Services

SOA-extinction-3I 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.

BPM’s place in the upcoming decade of corporate change

I read this quote from Lombardi‘s president Phil Gilbert. I think it deserves a post:

BPM is the scalable program by which a company develops and maintains a capability for change. By “capability for change” I mean: having a corporate culture that will actively embrace change, without fear, and work to make that change good. Today, most cultures actively reject change, until forced by market conditions into it. And while companies are finding that the technologies of a BPMS ((roughly characterized as model-based design, business rules, business intelligence, business activity monitoring, and workflow) help, they don’t solve the cultural problem of people embracing change. The maturity of today’s BPMSs… may reduce the development time of a process application from, say, 90 days to 89 days. But it still takes months for a business case to get approved to charter the project. It still takes weeks to roll-out the new application. It still takes a year to get budget.

Mashups, web2.0 and the SOA cake

I read a commentary around the recent Gartner 10 Strategic technologies to watch in 2008.
In this commentary, Evan Data Corp. Joe McKendrick and Software AG Miko Matsumura say, very high, that even in SOA is not explicitely spelled in the recent Gartner’s report, SOA itself is the basis for what we are building today and in the future. There are some interesting quotes from the commentary that I wanted to highlight here, as they have really a lot to do with what we do everyday.

  • The consumption patterns of Web 2.0 and Enterprise 2.0 are made possible by SOA in this view.
    “The architecture has no value until it’s expressed in consumptions patterns. …The underlying service is just a generic-kind of service, but it comes to life when you put an Ajax interface in front or some kind of cool mashup in front of it. Once you’ve got a platform of business services, you can make mashups or Web 2.0 or a ton of really cool things.

  • “Turning to another goodies metaphor, …SOA is invisible in the same way the recipe for a cake is invisible. Even the most proud baker wouldn’t stop people from eating his cake while he read them the recipe. The consumers of cake or Web 2.0 applications want to enjoy them not hear a dissertation on how they were made, he said.
  • The status of SOA today is similar to where e-commerce was in the late 1990s. At that time everybody was building e-commerce applications using e-commerce tools. “Now, we’re doing the same thing with SOA. We’re saying this is an SOA project or this is an SOA tool. Today, you still use content management and application servers and Java as a language and Web interfaces, but you no longer call it e-commerce because now it’s just apps. It’s just how we do it. We don’t really think of it as e-commerce any more, it’s just the typical pattern for applications these days. I think exactly the same thing will happen with SOA.”
  • “When you say SOA no longer matters, it’s everything that SOA enables that matters, I totally think that’s right because SOA is a way to achieve certain things from an architecture and an alignment and agility point of view,”

I like all these quotes, because they really make the point!

Going back to what Gartner asserts, I obviously like the presence of the following 3 items in the top-ten list:

  1. Business Process Modelling
  2. Mashups and Composite Applications
  3. Web Platform and WOA

My readers know how much I consider “Business Process Modelling”, at the point that I did not hesitate to say that it is the glorification of any SOA, the way in which Services could become useful from a Business Point of view. I am not sure, though, that BPM will emerge (finally!!!). Not because it should not deserver a shining place, but because of the power implications it brings into a company’s organization (who owns the process owns the power….).

In this context, though, the emergence of the Mashups and Composite Applications, may slightly change the picture. “They allow you to rapidly tailor the functionality you want in one place, without having to re-create the original”  is the quote from Gartner. I still think what I wrote last year in “Composite Applications, Mashups and Portals: relay race or team spirit?” . Through Mashups and Composite Applications, the user will become an actor in the SOA. SOA will not stop anymore at the beginning of the HTTP pipe on the server…. it will continue, it will encompass the desktop.

The user will be allowed to integrate what the “portal” gives him with tools and content coming from elsewhere. The “portal” will provide the official company process and the mashup will provide the creativity, the differentiator by which a user would tailor the standard process and add his own touch !

BPM **is** a mashup

Wow! I think this is an interesting quote from the BPM and Enterprise 2.0 panel:

My favourite quote from the panel, from Phil Larson when speaking about mashing up BPM data: “BPM *is* a mashup”.

I never thought in this way, but this is certainly very stimulating as a concept. It is the way in which I always thought to this topic (BPM) in my mind; taking services and visually composing them together in a network in order to create a Composite, Multi-Role and Multi-Step Application.

Two faces of the same coin

A series of articles trigger this post. Among them, two above all:

I could summarize the ideas behind them in the following way.

Enterprise Mashups represent, on the desktop, what SOA represents on the server. And that what matters, on the client as well as on the server, is how these technologies allow the execution of Business Processes.

This is great!
In my presentation “Thoughts for a Rich Client”, I sort of developed the concept of 360 degrees integration.
See Explanation.  Clicking on the picture will download  the highest resolution version available.Let’s represent the integration space with our Globe: we have a Southern and a Northern hemisphere.

The Southern hemisphere represents the kind of integration that happens on th server. This integration is made possible by an architectural pattern (SOA) and conveyed to us by a Portal. Ismael’s article describes so well how this is all about Business Process, because the reason to adopt an SOA is indeed the one to automate an existing Business Process (or to implement a new one).
By the way, I have written a little comment to Ismael’s article in which I try to explain my position.

The Northern hemisphere is a new territory. Until recently, the desktop has been considered simply as a projection of something that was happening on the server. Infact, a Portal is aggregating content that is simply displayed inside a browser. In the Web world, the Presentation Layer of an application has normally been executed on the server, leaving to the desktops the simple task to display something happening elsewhere.
The advent of AJAX (and of other rich client technologies, including Lotus Expeditor) and the evolution of the technologies in the browser space made it possible to actually consider the client as a first-class citizen in the SOA world; for the first time in the web era, the Presentation Layer (or a part of it) could be implemented outside of the server, “after the web server”, on the other side of the pipe….
This makes it possible to perform aggregation also on the client. call this aggregation “enterprise mashup” or “rich portal”…. at the end, what these technologies allow, is the implementation of the client side of Business Processes.

The Business Process can now be described and properly automated in its more natural way: a rich set of cooperating tools, information and applications allow users, from their desktop, to properly use orchestrated services. The formal, top-down processes described and executed on the servers are made available to users who can recompose them in ways that exploit the innovation and foster the flexibility required by new enterprises.

So, BPM on one side and Enterprise Mashups on the other, can actually represent two faces of the same coin. The coin of the “enteprise business processes”.

P.S. Other articles that contributed to this where:

  • RSSRSS
  • Social Slider
  • RSS
show
 
close
rss Follow on Twitter facebook linkedin