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

SOA v POA, EDA, GDA

First of all a warning... I have an SOA hammer and maybe everything does look like a nail.

SOA - Service Orientation - I tend to see SOA has the bit where I stand looking at the toolbox wondering what I should use to get the job done, its key aim isn't to do the detail, its to help select the right tool to do the detail. In this SOA attempts to define the broad areas and capabilities, not to focus on specifics at the start. So starts by understanding the "What" of the enterprise, the broad "what do we do" questions, it then worries about "who" do we interact with and finally "why" do all these things work together. It doesn't deal with the "How" of implementation it just creates the framework within which that can be done.

There are other options as to where you start of course, and I'd like to start by saying if it works for you then fine, but I'm not liable to be joining you.

POA - Process Orientation - This is IMO the most broken model of all, often building on business school work of the 1990s it suggests that organisations are oriented around their processes and that by understanding the end-to-end processes. The problem is that businesses aren't oriented like this, processes go across many areas and process based implementation tends to lead to brittle and inflexible solutions. Organisations aren't process oriented. POA also actively prevents SOA as its a bugger to try and retro-fit decent service granularity into a process model, and equally if you just have lots of small components managed by big processes then its just Visual Cobol with components.

EDA - Event Driven - Identify the events first says this approach and then you can understand the business. The problem I have here is that this is to me just the capabilities bit of SOA, you need the encompassing service for two reasons. Firstly to provide context as to what the event is about and what is its surrounding business environment, and secondly to provide a place into which new business events can be added. Viewing businesses based on their events quickly creates large lists of events and its pretty tough to add a structure, even if you do event chaining, because it is just single events calling other single events. While not as bad as POA this approach still takes the approach that organistions operate based around single events rather than taking a more holistic view.

GDA - Goal Driven - Identify the business goals and you will then be able to move onto how to deliver against them. This isn't that bad an approach as Goals are often complex composite things for a business and they do help you understand the key drivers and principles of an organistion. The trouble is, particularly if you are more extreme and gather goals in a "flat" way rather than concerning yourself with the domain within which the goal is managed or attained means that you again have a set of singletons interacting which can make creating simple architectural solutions a bit of a challenge.

The good news is that all of these things are great second steps if you take a good business service oriented view. If you have one service that is best modeled by thinking of it as processes then POA within that service is a good thing. If you have a reactive system based around events then EDA will work within that service. If you have a goal oriented area that is best described in terms of its outcomes then GDA is right within that service. if its best to model Beliefs, Drivers and Intents then BDI is liable to work within that service. You could even say that SOA models the services, EDA the capabilities and the POA how some of those capabilities are implemented, but either way its the service that needs to come first.

EDA, POA, GDA and BDI and even OO are great ways to model how a service should work, or more specifically how the capabilities on a service should work. This is the key, EDA, POA and GDA are all aiming to define the capabilities that an organisation, enterprise or project should have, SOA aims to provide the mechanism for containment and abstraction for those capabilities and this is why it needs (IMO) to come first.

You don't start modelling an Object Model by listing out all the methods and attributes then trying to fit them into classes, you start with the classes then wonder what the methods and attributes should be, then worry about how to model their implementation. Its no different with SOA but operating at a business rather than a technical level. The first question is what are the containers, the buckets, the blobs... the services, then and only then should we worry about the capabilities, and once we have them we should worry about how you implement them.

Like with Web 2.0 v SOA its not actually one or the other. SOA provides the context, the others worry about the details.

Technorati Tags: SOA, POA, EDA, GDA, Service Architecture