MDM, SOA and BPM - making processes simple

BPM is once again a hot topic. It seems several years ago where I said "if you want to get enterprise cash, learn BPEL"... in fact it was 5 years ago! However BPM really hasn't delivered on the promises and that is for three reasons

1) The Promises were too big
2) The implementations were too complex

3) BPEL rapidly became a Visual COBOL approach

Now I've said before that BPM screws up SOA and that SOA makes BPM simple, I'll stick with that and I'll now raise another piece in conjunction with SOA and MDM. This is actually a way to make BPM work more effectively, more simply and reduce the issues around elements such as process [de|]hydration. Namely that if you are in an area where BPM is the best implementation approach for a specific service's capability then using MDM helps to make its implementation simpler as you can work on key exchange rather than on content exchange.

Rather than BPM folks worrying about the schemas and exchange of core information that is left to MDM (where it belongs) and the SOA pieces handles the business domains part to make sure processes have clear boundaries and can be well managed.

Technorati Tags: SOA, Service Architecture

Christmas SOA

I've been reading some things lately that talk about business people being "in control" of process diagrams so I thought it was worth while reprising something I wrote back in 2005 and which is in the book around how there is a big difference between the perceived business process and the actual execution process. Now I have two kids and its coming up to Christmas and their view of what happens at Christmas is of course completely different to what actually happens. The kids are the business at Christmas its all about meeting their business expectations and goals. 

As the parents we have only one job to do and that is to deliver Christmas in the manner the business expects to see it. This means that we have to hide from the business the technical delivery elements and just show Lana and Louis the vision they want to see... now of course the question is how do we deliver an SOA Christmas? At the top level 0 its all pretty simple all the business wants to see is presents coming from as many different channels as possible. 

 As the kids are both still young the metric that will matter is volume of presents and its by this that success will be judged. At Level 1 they have the concept that Santa Claus is the centre of the present giving universe and it is to Santa that the list of request should be made. Santa is then responsible for distributing the list to everyone else for the things he doesn't want to get. So at a process level the business view is that the list goes to Santa, who sends it on, there is a view that there are things called shops out there involved in some way, but that isn't important to the business. Santa then delivers presents to the stocking while the parents deliver to the tree. Any person coming through the door over this period is also expected to enable the business to get presents. This is the perceived business process and its this that the kids want to be able to effect. Can the list be delivered in person? Emailed? Sent via some slightly dubious chat service? Or maybe posted the old fashioned way? 

There is a, reluctant, acceptance from the business that the 25th December is the delivery date and that this isn't movable and that some suppliers will miss the delivery date and provide presents at the first available point after the main day. Santa however is never late. Now the goal of the parents (IT) is to deliver Christmas in the way that the kids expect and to ensure a successful and happy Christmas period. 

Unfortunately the parents also know that Santa needs some manual intervention to get things moving. So first of all they have to provision the infrastructure, namely Santa and the Tree, then they have to co-ordinate the present buying to minimise duplicates. A spree of present buying is then underway, as is an increase in debt, followed by delivering the presents in the right manner to the places the business expect them to be. This therefore is the execution process. This process might get much more complex if you have to add in balancing acts between the business people so there is the perception of present equivalence or if the parents are actually hosting Christmas this year so the workload goes through the roof. This all demonstrates that within SOA, there might be a commonality in an understanding of the services being provisioned, but the actual manner of provisioning and the additional actions are only of interest to the implementors and should be hidden from the business, and other consumers as they are irrelevant to them as long as their objectives are being met. This is one reason why SOA makes good BPM but BPM makes bad SOA 

This is just one of the reasons I tend to say that business process is an IT myth. You need to understand both the business view of what must be achieved (often goal driven) and how it is measured (the implicit process) and then map this down to how IT will deliver that goal and measures (sometimes via an explicit process). In this world of separation its nonsense to argue that the business is "in control" of the execution processes beyond the level of defining the important elements of KPIs, goals and implicit process. Having this explicit process implemented within the services rather than across them (for a blog outline there is chapter on this in the book) also helps to scale as the services are coordinating effort rather than having to have a process per child. 

Switching back to more normal IT should the sales director worry that that simple two steps of "check fraud then get payment" might require a complex series of processes and integration to external 3rd parties? Should the LOB manager who wants to get their current key suppliers need to know that this integrates with 20 backend systems and has a complex Master Data Management solution? No that is the reason IT is there to take the business goals and KPIs and best surface them in the way that the business wants. This is why business people shouldn't care about their BPMN diagrams being what are being executed they should just care that they are being delivered. Remember folks, SOA isn't just for Christmas.

Technorati Tags: SOA, Service Architecture

Why BPM screws up SOA

I've often argued that Services are containers for implementation and that processes are not the ultimate thing in business, and a key part of this is the idea that Service != operation. This last piece appears to be one of the most beguiling myths about BPM and SOA and its surfaced yet again:

"SOA is an architectural style the recognizes services (functionality representing process steps) as components."
Jack Van Hoof

Emphasis mine. But I'm willing to give Jack the benefit of the doubt as there are two ways of reading that. The less charitable reading is the one that was jumped on someone talking about CRM (quell surprise)

"Let me start by defining that a service is a specific business process step that can be composed and reused in different business processes."
Kjell-Sverre Jerijærvi

Now this really does leave no room for maneuver, and it is completely and utterly wrong. This is one of the big challenges of BPM and SOA in that if you start with BPM, which is about co-ordinating steps, then suddenly every service looks like a step. I've seen this problem on several occasions now, and heard it repeated by many others so it looks to be pretty endemic in BPM driven solutions.

To be 100% crystal clear. If you are doing BPM and then just saying "step = service" then you are doing VISUAL Cobol and replacing function calls with service. The fact that you are using WS-* or XML does not make these elements services. As the SOA-RM says "A service is a mechanism to enable access to one or more capabilities", so it is possible for it to be a single capability, but that is certainly not the only, or indeed the most likely, number of capabilities in a service.

BPM driven SOA tends to make bad SOA as it is driven from a procedural and process view, has poor separation of concerns and is mostly all about driving things from the technology perspective.

SOA makes great BPM, BPM makes crappy SOA.

Technorati Tags: SOA, BPM, Service Architecture

SOA and the Swiss Railways - or another reason why processes aren't everywhere

I've just come back from a very pleasant little trip to Switzerland with the family (family friendly doesn't sum up the country... even the TRAINS have play areas!). The Swiss train system is rightly world renown for its punctuality and co-ordination, we had 4 trains to catch to cross the country (Google Earth map) and the changes between the trains were 10-15 minutes at each of the stations.

Why is this relevant for SOA? Well here is an example of an incredibly efficient batch system which is based around time synchronisation and which therefore is able to move large numbers of people successfully around. A "real time" process based solution would be the car. Start at A, do lots of steps, arrive at B. But with the railway system, which is much more event based, is able to achieve the same end game (indeed there are parts of Switzerland where cars cannot reach) but do so in a way that reduces stress and increases efficiency.

So when you are looking at replacing those old Batch processes which look so inefficient, ask yourself whether they are batch processes because that is all that could be done, or whether you have a Swiss Railway implementation that you are about to replace with a butt ugly SUV.

Technorati Tags: SOA, Service Architecture

SOA isn't about technology

I've been having various discussions recently around SOA where a certain mindset is coming over loud and clear. That mindset is that SOA is just a technology thing, its about the specific technical end points, and that above all these end-points are relatively fine grained, from a business perspective, and are there to enable "BPM" to shine through as the one true way to work with the business.

I've said it before and I'll say it again... business process isn't everything. Right now this focus on BPM is driven by one thing and one thing alone, the fact that every single vendor's stack tops out at business process. Now most of these don't even have a decent way of handling services (i.e. one interface = one process = what a load of crap interfaces you have) but that is beside the point. What they are proposing is that the IT/Business model looks like this


Its a simple stack based view of the world, business at the top, techy IT at the bottom and BPM as the medium for communication "at the business level", people who talk about this view tend to talk "bottom up" with "services exposing legacy and BPM orchestrating services". Its pretty amazing how this view just happens to match the product vendors stacks, this means that either

1. This is the end of IT product development we have fixed it all, we are done
2. Its bollocks

Now I'm backing option 2 on this list because I've worked with lots of businesses in various sectors and the most successful ones were those who used processes as required but who were primarily focused on goals and objectives with the actual implementation being flexible.

This is where SOA really earns its keep, not as the bit that delivers the solution but as the contextual framework within which that delivery can sit. SOA, and in particular a business service architecture, is all about understanding the various different "blobs" of the enterprise, how and why they interact and then choosing the right delivery approach for that service.
My view of the world has BSA being important, but as a contextual framework. When you get down to implementation you are still going to think about the specifics of the requirements or demands on an area and this means you will still have to speak to the business. The differences is that the BSA means you are talking within a business context where it has been decided that BPM/Technical SOA/GDA/EDA/People/Flying Monkeys/etc is the best way to solve that problem.

One size doesn't fit all, BPM is not the culmination of all IT. The challenge in IT and business remains the same, namely getting a contextual framework within which the problem domain can be understood and then choosing the right way to solve that problem. BSA isn't a hammer, its the plan that helps you decide when you use the hammer or when you use the saw.

BPM as the language of business is, IMO, snakeoil. I've heard many CEOs report on how their business is doing, I've heard sales directors report on sales... and I've never heard any of them step through a process of their business to describe where they are at.

Think first, plan first, then decide the way to go. Starting with BPM is as silly as starting with WSDL.

Technorati Tags: SOA,BPM, Service Architecture

Stop with the damn SOA technology

I came across a post talking about the challenges of SOA and Financial Silos which references an item about too much SOA technology and makes the good point that we can't expect the business to fund strategic IT and should concentrate on delivering against what the business wants.

I'm with that, especially as I don't think there is IT strategy but where I think this article misses the point is that it holds up its hands and says "okay then lets just to the techy stuff at the bottom" which really is just accepting that SOA is just EAI, and like in scrabble if you lay down those two you end up with the same score.

The real problem, which is referenced but then sort of glossed over, is that IT needs to be looking well away from the technology and away from the projects and doing two things. Firstly IT should be looking to get the investment to make changes by economising on those parts of the budget that they do control (i.e. support, development and infrastructure of existing systems) and Secondly IT should be looking to do the cheap things that will have the largest impact. This means organisational and governance changes and understanding what the business service architecture should be. The article (IMO) also makes the mistake of thinking that BPM is where the real end game is here, which it certainly isn't as BPM is just another execution choice for IT and not a different way of actually doing IT.

If you think "well we can't make any changes but at least we can use SOA technologies on this project, that will help won't it?" then you are deluding yourself.

Make the cheap changes first, then worry about the license costs.

Technorati Tags: SOA, Service Architecture

Why Sales isn't process driven

One of the statements I've made on a semi-regular basis is that the concept of business process being the most important thing in a business is a myth. The other day this was brought home to me perfectly when I was looking at packaged solutions and particularly pieces around the "sales process".

Now I'm not going to say that there is no such thing within an organisation as a sales process, of course there is, but what I'm saying is that this isn't actually the important factor when looking at the success or failure of a sales organisation. Having a process that says "Stage 3 - Agreed issue with client" and "Stage 9 - Contract Signed" isn't the thing that actually drives successful sales.

No its sales people, sales targets, bonuses and most importantly goal driven behaviour that is the important factor in sales. Understanding what the goals are is much more important that understanding what the process is, different people will have massively different approaches to the selling process and while they will move from one step to another and this will give you the ability to measure and audit their performance it will not give you the ability to help focus or improve it.

Its an old truism that KPIs drive behaviour and its massively the case in sales, it is therefore, when modelling the architecture, more important to consider these KPIs and the underlying business goals than to worry about the audit process that will allow elements to be measured. This is a great example of where the business value and importance is assessed via the KPIs and Goals, but is measured by the implementation of a process.

This is one of the critical things to remember when creating an SOA, understand that the mechanism for the implementation and measurement of a service can be different to the mechanism for defining the external drivers and business critical value of the service. In some cases process might be both of these elements, in some it will be none but do not fall into the trap that because the measurement is by process that this is actually the thing that drives the business behaviour and value.

In fact I'd say that for most Services the concept of "Goals" will be more useful than the concept of "Process".

Technorati Tags: SOA, BPM, Service Architecture