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.

What a surprise: Oracle says WebLogic is its future strategic server

Today I received on of the newsletter to which I subscribe. I read it because of an article which seemed to be very interesting “Oracle says Weblogic is its future strategic server”.
In the beginning, I liked this assertion “To many, the Oracle products seemed a mere adjunct to its data base”. Great! I like it!

The author, then, references the article Oracle re-brands BEA WebLogic as its strategic server for SOA. In this article, there is an even better quote, from Bloomberg:

“If you read between the lines, when Oracle now says ‘Oracle WebLogic Server Enterprise Edition is the application server of choice’, what they mean is that the application server they had before the BEA acquisition, to put it mildly, wasn’t the application server of choice — for just about anybody”.

🙂

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 !

Are Mashups Web-based only offering?

An interesting article “Barrelling Through The Web 2.0 World” highlights parts of a recent Gartner’s report on Web2.0. The article features my friend and IBM colleague Dan Gisolfi.

I extrapolated the sentence

Who is to say the mashup has to remain a Web-based offering ?

because I think that it is very interesting… Not because of its “Web 2.0” bias (as the article implies) but because of the implications that the mashup technology could have well outside pure browser-based technologies.

Web-based technologies go well beyond their utilisation in browsers. I think that they have their place in Rich Client applications also.

I am thinking here to technologies I know, such as Lotus Expeditor or Lotus SameTime. Where the Composite application model actually allows the integration of content and application delivered over the internet with content and application aggregated from the enterprise SOA.

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.

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