I’m republishing here an interview I originally did for BPM Delivers quite a while ago - but updating it with further comments which are in italics. Strangely, not much has changed.

Question 1: In Delphi Group recently surveyed 110 firms about their 2006 investment priorities. The top three responses were related to Service Oriented Architectures (SOA) and Business Process Management (BPM). Is this a hype or a real trend?

Answer: The trend is real. A number of major organizations that I’ve talked to – mostly in the financial sector – have multi-year projects running in these areas. As time passes the number of such companies just grows. In my view BPM ceased being hype in 2004 and SOA ceased to be hype in 2005. Those were the years when I noticed genuine benefits being delivered to IT users by these respective technologies (neither of which, by the way, are mature).

Comment: Now, of course, there’s no question. All the questions are about the maturity of the technology mostly from the sudden discovery that there are lots of technology gaps that need to be plugged. Now we’ve moved into a software world that is driven by components, engines and platforms. It’s the world of SOA whether it’s good SOA, bad SOA, or so what SOA.

Question 2: What is your personal definition of the two approaches?

Answer: Technically, BPM is the marriage of work flow with web services. It is a business process designing and building capability that empowers business analysts. The important point is that you can design and implement end-to-end processes utilizing existing business applications and adding new business logic where necessary.

As for SOA, I like to think of BPM as the tip of the iceberg with SOA being the iceberg. SOA embraces BPM because it is the architecture that best enables BPM. But SOA also orchestrates the IT infrastructure and delivers sustainable IT service levels. If you want a definition, try this: SOA is an architecture for building business applications as a set of loosely-coupled black-box components orchestrated to deliver a well-defined level of service.

Comment: There’s nothing to add. The SOA definition here is the one we used in SOA for Dummies and it has legs. It’s now used everywhere.

Question 3: How do they relate to each other? Is there success for one without the other?

Answer: I answered the first part of this in the last question. So, could SOA be successful without BPM? In theory it could, but SOA does so much to enable BPM that it is difficult even to imagine any organization implementing SOA without BPM. Why would anyone do that? It would be like building a boat and not sailing it anywhere.

Can BPM be successful without SOA? Well, to be honest, it could. Some of the workflow and document management systems of the past could be called BPM-without-SOA. The problem is that without SOA you end up over-investing in technology and ultimately you run into scalability problems - and actually many other problems too. No-one in their right mind would implement BPM without planning to implement SOA at some point. Mix a lot of BPM with too little SOA and you will surely have a mess on your hands.

Comment: We’ve moved on a little here I think. Now everyone sees BPM and SOA as brother and sister.

Question 4: What do you consider the greatest myth about BPM and SOA?

Answer: There are a number of myths surrounding BPM and SOA. Choose your favourite. All are equal, but some are more equal than others.

  • BPM and SOA are just marketing terms. Not so, but they are terms that do seem to confuse marketing people.
  • BPM mandates rules-based software development. Only if you’re a salesman of rules-based BPM tools.
  • We can do BPM with the software tools we’ve got. And you can fell a tree with a hammer rather than an axe, but it takes a lot longer and it’s not clever.
  • SOA is just Object Orientation with a new hat on. Not so. It’s got a new wardrobe entirely and it’s had surgery.
  • SOA is like sex with aliens, you hear reports but there’s no evidence that it happens. Actually, close encounters of the third kind do take place.

Comment: Nobody would now dispute that SOA really happens and happens in your back yard. The jury is still out on sex with aliens.

Question 5: What are the most difficult steps within a BPM project – and what makes a SOA project tedious?

Answer: The most difficult steps within a BPM project are the early ones. The problem is cultural. As a fact of business history and IT history, all organizations are siloed. Hell, I know it’s a cliché and a platitude, but its also true. The siloed nature of organizations is ingrained. You have to get people to think end-to-end rather than silo. This means everyone, the business folk and the IT folk and any other folk who happen to be around. The IT folk are siloed too, you know. You need to “get their minds right” because with BPM you need cross-discipline teams who don’t indulge in turf wars.

As for SOA projects, I don’t believe one should even think in terms of implementing SOA as a project. SOA is a road and it’s a road that everyone will ultimately have to take, because it’s the road that the IT industry has already taken.

Is there anything tedious on this road? Yes there is; turf wars and inadequate technology.

Comment: It’s still true. It’s still the case that the cultural problems are the biggest block to SOA.

Question 6: What best practices do you recommend to organisations looking to initiate a BPM / SOA project?
I could write a book about this, in fact we did write a book; SOA for Dummies. So let’s just pick two things that I believe to be critically important:

Answer: Get sponsorship right from the top. There are many reasons why this is necessary, because SOA and BPM usually cause significant changes to an organization.
Also pick an easy first target. Make sure to go for low hanging fruit on the first project. You know what I mean, low risk, high benefit. You really don’t want the first project to stall in any way.

Comment: Now I would add, that you should look to implement comprehensive Identity Management as soon as possible and also go after coherent Asset management. The big note on the wall shoudl read: “It’s the plumbing, stupid.”

  Subscribe to HaveMacWillBlog in a reader