It’s about umm… Services, duh!

<Rant>

Every now and again you see something that makes you realise that you’re on a different planet to many other people.  In this instance it was an article by Dan North aimed at demystifying SOA (http://dannorth.net/classic-soa), applauded by Joe Mckendrick for taking a technology-agnostic view of the thing.

Now don’t get me wrong - I absolutely agree; service orientation is an abstraction that allows us to consider things from the perspective of services, their providers, their consumers and the agreements that exist between them.  What freaks me out (often) is that this seemingly simple concept is ignored by most people who fly into acronym and technology land - SOA, ESB, BPM, Registry, Repository, Legacy enablement, web services, SOAP, REST etc. etc - or even worse product land - microsoft biztalk, websphere ESB, weblogic application server, Jboss, <insert whatever pointless thing you’re now in a rage that I’ve left out>.  In both cases people get in to the most heated arguments about which technology or vendors approach to any particular issue is ‘the one true way’ (a point made by Joe).  Essentially they pile into explaining and arguing about ‘how’ - in the form of immense and complex technical detail and the exponential combinatory options - rather than succinctly trying to express ‘what’ - in terms of understandable concepts, benefits and outcomes.

But why do people do this?  Why do they try to explain SOA in those terms and more importantly why does the power of the concept get swamped in pointless arguments about subtle ways in which different ways of realising some insignificant part of it are better than another way of realising that same insignificant part?  What is so hard about the concept of services?  We all consume hundreds of them every day.  Why do those who try to simplify the concepts of SOA end up taking about Lego?  What’s wrong with services - banking, retail, media - we buy services from service providers all the time, each where we desire something that they are willing to provide agreed through the medium of a contract of some sort.  Would you build and run a bank at the bottom of the garden just to keep your own money in?  How much of your time would that take and wouldn’t that time be better spent living your life?  How good an interest rate could you give yourself given the small amount of money involved and wouldn’t it be better to pool your resources with others to maximise the economies of scale?  And how risky would it be to try and guard your money yourself - how much security could you afford?  Of course this would be a ridiculous proposition.  So if using service providers makes sense in our personal lives why do our companies do their own logistics/finance/underwriting/branding/whatever when we could increase our performance and focus whilst reducing risk through using services provided by specialists in a similar way?  Even if we’re shy of co-sourcing wouldn’t it be better to increase transparency by understanding what services are being provided by capability units within the organisation and how well they manage performance, cost and risk in their specialism on behalf of the company?

To be honest if people aren’t having the sorts of conversations that Dan brings out with their business colleagues - i.e. ones about who is responsible for realising what value for whom and to what level of service - then I despair of SOA ever delivering anything - we are such an immature industry.  From  a product provider perspective of course they are going to be talking about technology and features as realistically they have their own interests at heart rather than those of the business they are talking to (bit harsh but realistic) but surely service companies such as the one that I work for or internal IT departments should be able to help their business colleagues grasp the concepts and benefits whilst becoming expert realisers of those benefits and hiding all the crap?  If people went into a garage looking for a car and a hundred people descended on them shouting about different brake pads, spark plugs and rivets and why in each case the ones that they want you to buy are better then we’d all still be walking with no idea as to what the benefits of a car actually are. 

Why does this have to be so complicated?  The concept you’re looking for to help explain service oriented architecture is.. um… services.  Your colleagues are smart people - give them a real world concept and they’ll get it.  Concentrate on helping them to understand what their business would look like as a set of services, what benefits this brings - using real world, familiar examples - and leave all the grubby technical bollocks in the shed until you actually need to do the digging so that you don’t mess up the nice clean offices of people who just want to get things done.  Any implementation of SOA needs to be based on business value and outcomes and until you can explain why it’s a good idea there’s no point even putting the usual acronym laden presentation together - everything you write will be bollocks until you make it real and understandable using - unbelievably - plain english and the simple truth.

</Rant>

 ADDENDUM:  Just also read Bobby Wolfe’s article over on developerworks about ESB-oriented architecture and it made me laugh out loud.  Different angle but similar argument about the futility of technology navel gazing.  Really appreciated IBM’s quick disclaimer about the value of ESBs, too, lol (another of my pet hates, btw, given that they are basically (nearly) all proprietary hub-and-spoke products that fly in the face of all of the lessons of the last 10 years with regard to federation).

:: :: :: :: :: :: :: :: :: :: ::

Killer, Gorilla, Guerilla SOA

The Proposition

Just read an interesting post by Jim Webber about a lighter weight technique for SOA implementation that he calls Guerilla SOA.  This spurred a number of comments from people such as Joe McKendrick, Tony Baer and ZapThink’s Jason Bloomberg.  Generally the comments were positive excepting the usual concerns about bottom up implementations leading nowhere.

Guerilla Campaigns Need Direction

As I’ve discussed previously I’m a big fan of thinking broadly but starting small, since with difficult to grasp concepts like SOA we have to rapidly and continually deliver benefit to generate buy in from our business colleagues.  As a result I am intrigued and broadly supportive of the concept of guerilla SOA implementation.  The key thing in my view, however, is to start in the right way by concentrating initially on getting a broad view of the business capabilities needed by the enterprise through a rapid approximation and then use these as a governing framework for the implementation of services within the organisation. I’m a firm believer in mixing systematic design with a dash of chaos - essentially govern the top level business capabilities required by the organisation but then delegate responsibility for the realisation of these downwards (and since this is a fractal process there are a limited number of capabilities at each level and as such the decision making process is made simpler by restricting the number of abstractions that any one group of people need to manage).  As a result we allow capability owners to realise services any way that they want - potentially meaning that many replicated services spring up across the organisation within the control of different capabilities - since the only thing we care about is that we have the ‘right’ capabilities and that these perform to the cost and quality metrics that we require.  In this context sharing of services at lower levels of granularity will be an emergent property caused by attempts to improve the cost effectiveness and quality of capabilities rather than something that is planned for from day one (which requires a deep and complex understanding of how everything in the organisation works from top to bottom - an impossible task despite the best efforts of many current enterprise architecture approaches).  Equally importantly in this context, attempting to force capability owners to share smaller granularity services by looking for ‘reuse’ often damages these business capabilities in subtle ways that are impossible to guess ahead of time - as a result independence with future emergent sharing opportunities based on metrics is a more appropriate mechanism IMHO (which now that I’ve read that sounds a bit like the agile principle of only building what you need - hadn’t really thought about it within a business context like that before - gives a whole different spin to the hackneyed term ‘agile business’).

Executing Your Campaign

Now the question is how this relates to the discussion of guerilla SOA?  I would argue that the notions of business capabilities and guerilla SOA are orthogonal and complementary.  Essentially you map out the broad ’shape’ of the organisation (your campaign goals) using business capabilities - consider this the horizontal dimension - but then concentrate on federated projects (guerilla operations) that maximise value in the improvement of these capabilities and fill them out using agile implementation styles, essentially rapidly implementing elements of capabilities with focused projects - consider this the vertical dimension.  The reality is that no business design (or indeed guerilla campaign) can ever be correct and pre-planned from top to bottom at any point in time and so the key is to rapidly approximate the systematic capabilities needed by the organisation and then get on with implementing value in a stepwise fashion.  Your governance process will need to be able to cope with changes - e.g. versioning of capabilities, business messages and everything else - as your transition to SOA proceeds but there is no way to nail all of this up front and for ever and so you’d better get used to that and move on.  Essentially anyone who comes to you and suggests a top-down process re-engineering exercise should be politely shown the door, since such exercises take years, are always out of date and never actually deliver any sustainable value.  Let’s call this top down approach “Killer SOA” as it is guaranteed to go nowhere and will quickly lead to a morass of paperwork that scuppers your attempts at SOA.  Conversely however just pitching in like a gorilla without any context will make you look busy and actually deliver some stuff but it won’t really add up to anything that makes a significant difference to your organisation - the sum of the parts will really be just the parts (and it’ll be more complex and expensive to deliver, operate and manage).  Let’s call this bottom up approach “Gorilla SOA” as we can imagine it as a chase for the next banana without any concern for what such plundering might do to the environment that sustains us.  To me Guerilla SOA takes the best approach possible, relying on a combination of a broad plan and lots of loosely coordinated and federated cells with the power to implement in a situationally appropriate way.  

Enable Guerillas to Improvise in Realising Goals

This approach to business capability realisation is also applicable in the technology space as well.  I am glad to see Jim stating (and an increasing number of other people realising) that technology as architecture (e.g. ESBs/application servers/whatever) is both meaningless and dangerous.  As I’ve discussed in the past trying to force centralised architectural approaches onto an essentially heterogeneous business environment (heterogeneous from a requirements perspective (e.g. QoS or cost requirements) as well as a technical one) leads to an environment that is fit for nobody.  Architectural approaches should concentrate on the space between capabilities (i.e. standards that support interoperability (or an overall loose coordination of cells)) and on the governance of the required outputs (i.e. capability metricisation and performance management (or realisation of strategic operations)) and enable capability owners (and guerillas) to maximise existing assets or new approaches that best map to their goals and aspirations rather than on trying to use technology as an excuse for architecture (I have to also admit to having a particular distaste for ‘ESBs’ which in most incarnations are just hub-and-spoke message hubs with proprietary transport which undermine the very notions of SOA - i.e. federation, standardisation and interoperability - but I guess that’s another post, grrr ;-)).

It’s the Difference Between Killer, Gorilla and Guerilla that Matters

In the broader context the question is whether Jim’s comments reflect an anarchic and directionless dead-end of random service implementation or a dynamic and manageable way to break the SOA deadlock within organisations.  To me the question you have to ask yourself is whether you are a Killer that drowns your organisation in paperwork, a Gorilla who just wades into SOA in an elemental fashion with little thought beyond the moment or whether you are a Guerilla who is part of a larger group of loosely federated fighters striving to realise a shared vision. 

P.S.

I realise that many people refer to ‘Guerilla SOA’ as ‘Middle Out’ (see Nick Malik for an example).  To me the two terms describe the same thing but whereas ‘Guerilla’ makes me think of glamour, adventure and action ‘Middle Out’ makes me think of the male aging process and brings to mind increasing flabbiness around the midriff and balding.  Just sounds less exciting doesn’t it, especially when we’re trying to convince people to follow us into action, LOL

:: :: :: :: :: :: :: :: :: :: ::

SCA = Scary Component Architecture?

Only just catching up with SCA/SDO as part of some work with a current client and have to say that there seems to be a great deal of confusion around these essentially useful specs.  First of all read the threads over at Joe McKendrick’s blog where a conversation raged for a while over the utility of SCA but then also came across this blog post by Dana Gardner over at FASTForward complaining about Microsoft’s unwillingness to play ball.  This latter post confused me deeply.  Dana (and others that he references) seem disturbed by the fact that Microsoft are not involved in this effort and that this represents a blow to ‘SOA interoperability’ and an unwillingness from Microsoft to be open.  This seems like a strange statement to me as from what I can glean from the specifications for SCA and SDO - and from great resources such as those provided by Dave Chappell - these proposals seem to be more about how you create components that sit within a particular realisation environment - realistically Java ones given the spread of vendors involved - and they seem to say nothing about interoperability per se.  Interoperability across realisation technologies (even across specific containers in fact) is left - very sensibly in my view - to existing web service standards.  So far so good in my view as the Java community have badly needed some support in simplifying the creation of lighter weight services of the sort needed in a federated world, since Java EE’s component roots are based on a previous generation of architectural model, IMHO, and as a result it has become way too complex.  Suggestions that Microsoft are not ‘open’ however on the basis of the fact that they only provide support for interoperability standards seems perverse to me.  Whether you are using SCA to compose applications that will realise services within a specific Java vendor’s environment, using WCF within the Microsoft world - or indeed ignoring all of these and resorting to simpler, more dynamic environments such as Ruby - surely having a range of programming models and platforms competing to realise services most efficiently is a healthier model than trying to force them to create service realisations in the same way?

The suggestion that we would have a common programming model that transcends implementation language, however, (as seems to be implied by Dana’s post and indeed others that I’ve read) seems a bit oxymoronic to me as surely our existing XML standards (of whichever flavour you prefer) take care of the multi-language aspect of the problem space, leaving composition as the main issue to be addressed (since BPEL only partially addresses this space).  I’m all for interoperability as a way of enabling competition in the provision of implementations but less ecstatic about the idea of trying to arrive at a converged programming model with a confusing mix of service and implementation metadata.  To be honest I feel that trying to mix the interoperability and implementation spaces by pushing a converged realisation model onto vendors introduces unnecessary complexity and so would not be a good approach to solving the issues around service composition.  Trying to talk SCA up as a way of enabling interoperability across implementation technologies (which again I have to stress is not something I believe the spec authors are doing) is a shame as it confuses an area around which we absolutely need more research and guidance, namely specific ways of modelling composite services - whether UML-based via the OMGs recent call for a services profile, as part of the STP project within Eclipse or via DSLs such as those supported by Microsoft. In each case, however, I feel that these should be at a level of abstraction above the individual technologies being composed since surfacing this information makes consumption a much more complex proposition by putting the onus on the consumer to take responsibility for integration rather than forcing the provider to expose their services using existing standards.

I guess I’m also influenced by the fact that I lived through the CORBA period where we tried to implement a standard programming model and - realistically - failed.  When I compare the subsequent success that the industry has had by concentrating on simplicity and interoperability suggestions of conformity of approach across realisation  technologies feels - to me at least - like a backward step out of touch with the current zeitgeist; currently we’re increasingly looking at simple, open, web based technologies that are ‘good enough’ and rail against the complexity of WS-*.  Such pragmatism has unleashed a wave of innovation from companies both large and small and anything that could introduce constraints and confusion to this model by trying to develop an uber-model of implementation feels to me like a bad idea. One of the great drivers of recent success has been federation - moving responsibility for service enablement to the endpoints (i.e. providers) to enable consistent and simplified consumption of these by consumers.  Trying to deliver a cross-language rather than web based composition model feels to me very much like the old school EAI approach that we have only just recovered from, moving information about endpoints back into the consumer space and increasing the complexity of the composition space.  it all makes me feel vaguely like I’ve returned to the mid-90s (not something you want to do if you’re Welsh as it was probably one of the worst periods in the checkered history of our rugby team).  At the end of the day I would rather see standardisation at the ‘what’ level (i.e. interoperability) than at the ‘how’ level (i.e. programming model) since it feels to me that this is the sweet spot for having your cake and eating it - an ability to work simply and consistently with anyone whilst allowing them maximum scope for innovation on your behalf. 

Whilst being uncomfortable with the idea that SCA represents some kind of uber-programming model, however, I do absolutely recognise the need to simplify service realisation in the Java space and therefore am heartily on side with it’s core aims.  I guess I’m more interested in the next level of composition, however - i.e. composition across standards-based services - rather than just on improvements in the way that one or more particular technology stacks supports developers in the creation of services that execute within their environment.

:: :: :: :: :: :: :: :: :: :: ::

Where To Start With SOA

Introduction

I was talking to one of my colleagues a few days ago about some of the issues he’s having helping his customers make the scary transition to a more adaptable organisational style based on business capabilities and service-orientation.  I thought I would briefly capture some of the questions and my feelings on the answers.

Questions, questions

1 Looking for a clear start position (“where do we start to eat the elephant”)

I firmly believe that structural changes driven by increasing interconnection across organisations require organisations to atomise - essentially break into their component parts and then specialise in those that will enable them to excel whilst offloading other capabilities onto partners.  Business capability modelling allows us to set the scene for this transition by considering an organisation in terms of what it does and then placing commitments and metrics around these capabilities.  Considering business capabilities therefore allows us to understand the shape of an organisation in terms of what it does and then ask questions about the performance of those capabilities in the here and now.  This gives us an excellent start point since any initial capability-based view of the organisation is likely to highlight many misalignments and performance issues based on that particular organisations journey to it’s current state; surfacing these issues with some well crafted value questions can really help us to pick a good area to begin the transition whilst simultaneously giving us the strategic backdrop to prepare for atomisation.  Anybody looking to take this journey - and this should really be everybody - should adopt a philosophy of “get the (broad) big picture, identify and prioritise improvements, start small, deliver incremental value and then broaden the scope”.  A recent presentation I saw (somewhere - sorry lost the reference) on SOA adoption from a US government agency said “think big, start small, fail, fail, fail, succeed, scale rapidly”. I think this would summarise my preferred approach.  My particular interest is in how we use industrialisation to reduce risk during the ‘fail, fail, fail’ part of the story.  One key way to do this is to look at shared service platforms that take care of the technology end of the issue for you.

2 How do we encourage our staff on this journey (The carrot not the stick)

Business capabilities (particularly when supported by industry metrics from a framework like APQC) give us the ability to set people ‘challenges’ by highlighting the gaps between their performance and external averages. This is not really a carrot or a stick specifically but it’s an important aspect of starting the journey, since focussing pressure onto people within the business through highlighting performance gaps helps to reduce the pressure on us in justifying why they should engage.  In many cases the surfacing of metrics that are actually aligned to organisational needs turns the conversation around such that customers are asking us for help to meet their newly minted metrics rather than us trying to sell some notional concepts such as ‘agility’ or ‘cost effectiveness’.  All of these may be important aspects of the way we do things but they need a proper context in which to be governed and delivered; essentially we need to shift away from the notion of ‘general’ improvement across everything due to technology (e.g. 10% reduction in applications delivery time) to specific, governable and business focused metrics (e.g. £50 reduction in the cost of widget procurement).  Again in this context industrialisation - rather than SOA per se - allows the pitch to be about the greater reliability and lower risk of transitioning to a capability-based approach (and hence aligning their delivery capabilities with their metrics) to improve their performance rather than on trying to sell the abstract notion of SOA.

In the longer term the aim should be to support capability owners in the monetisation of services and thereby give rise to much more innovative compensation schemes based on known, concrete and defensible metrics.  It is only through having commitments and rewards properly aligned and - equally importantly - the means of collecting and surfacing the information needed to assess against these metrics - that we truly develop a culturally holistic organisation. 

If the question being asked is more about how customers encourage developers to share, however, then the question is at wholly the wrong level; essentially we should be considering how you give capability owners a sufficiently high leverage view that they can make sourcing decisions for themselves.  At the end of the day the end state requires that procurement decisions shift focus away from IT and onto capabilities (which will include the IT specific to their implementation).  In that context the capability owner is making a decision between buying or building a capability and developers will never be involved until after  those decisions have been made (potentially not even then if the capability owner decides to contract the work to an external provider or buy a SaaS proposition).

3 How do we gain traction and momentum (early wins)

One of the key tenets of any successful approach IMHO is that although we take an initial (rapid) view of the breadth of capabilities within the organisation to support ongoing governance, we then quickly zero in on specific projects that deliver attributable, high value improvements.  We should always pick sensible early projects based on high impact but low risk, but then have the ability to rapidly scale out based on successes, since successes breed their own momentum.  In particular, if we have metricised the capabilities that the organisation has then we’ll potentially  have two very favourable conditions:  a backlog of performance gaps within the capability map (and thus people looking for help to meet their commitments) and demonstrable early successes in helping other parts of their organisation succeed in this aim.   As a result momentum will build organically - and potentially rapidly - if we get the early project decisions right.  One of the key benefits of the capability approach as scale builds, however, is that it enables much more parallel working on smaller improvement programmes, since commitments are scoped to providers as a ‘black box’ and thus the amount of cross enterprise coordination is reduced (not eliminated, just reduced).

4 How do we make this sustainable (culturally imbedded)

The key aspect of a sustained change is the realignment of commitments around systematic boundaries (i.e. the capabilities).  The use of capabilities and metrics to specify the required outputs enables us to gradually transition behaviours and organisational structures - business capabilities can be ‘logical’ during the early stages of a transition to service-orientation and layered over the top of existing hierarchies.  Concentration on required outcomes will tend to gradually shift organisational structures to best realise commitments, however and to maximise specialisation - as structures that do not align well to commitments (or capabilities that try to do too much) will struggle to realise their cost and performance metrics.  Equally fundamental to sustainability, however, is the need to ensure that service provision within the enterprise becomes  monetisable in order to ensure that capability owners have the scope to:

• Invest in building and extending their services based on their commitments and the needs of their consumers;
• Clearly see the impacts of building instead of sourcing (since it will have to go onto their cost base rather than come from some nebulous central benefactor);
• Can compare the costs of internal capabilities against those from external providers (whether those capabilities that they leverage as services such as recruitment or those that they leverage in order to improve their own capabilities such as IT service provision);
• Generate reward schemes based on achievement of the metrics that are important to the organisation.

Summary

In order to genuinely realise the potential benefits of service-orientation in the short term and - more importantly - prepare for the coming wave of atomisation and capability unbundling, organisations need to find a digestible and sustainable route through the transition process.  Such a route needs to be incremental (but holistic), foster decentralisation (but systematic design) and to ensure sustainability through the alignment of metrics, rewards and monetisation strategies.  Using capabilities as a logical framework enables much more coherent decisions about organisational specialisation, improvement and delivery, and - equally importantly - generates a pull for the requisite assistance as people struggle to realise their commitments rather than a befuddled ‘huh?’ from people whose metrics encourage them to maintain the status quo.

:: :: :: :: :: :: :: :: :: :: ::

Summer Hiatus

Well it’s been a long break since my last post as I’ve been coping with the long summer break - both my own (well deserved) and others (totally undeserved) holidays.  In the former case I obviously left everything in good order for my colleagues but in the latter they obviously left me a pile of stuff to deal with in their absence. 

In any case I’m back now and have made a number of resolutions:

1. To post more often
2. To post less lengthily (if that is a word)
3. To comment more on other people’s posts.

In deference to the second aim I’ll stop there and go and post something short and more useful; although it’ll take a train journey or something before I’m able to post about other people’s stuff

:: :: :: :: :: :: :: :: :: ::

Bottom Up or Top Down (ahem)

In a related discussion to my previous post Nick Malik and Joe discuss approaches to delivering SOA within the organisation.  I am wholly onside with Nick’s notion that the key advantage of SOA is the ability to federate decisions about implementation out to the individual service providers and that the role of enterprise planners is to facilitate connections across these providers in a light touch manner.  As a result I believe that the identification of the capabilities required by an organisation - along with their responsibilities and metrics - belongs with enterprise planners but that anything from this point on  is federated out to service providers (whether internal or external).  Essentially I feel that the best way to manage service orientation in a sustainable way is to concentrate on metricisation and monetisation and leave the rest to the ‘market’ (whether internal or external); essentially let self interest flourish within the bounds set by the organisational context as long as it delivers cost-effective services but punish it by outsourcing where it doesn’t.

As I understand Nick’s description of his view of middle out I believe that it is similar to the combination of top down and bottom up that I’m describing here.  I think that this is on the money as neither top down nor bottom up are sufficient on their own; you need top down to deliver the systematic view of the enterprise required to support adaptability and effective sourcing but at the same time need to empower people at the edges (i.e. the bottom) to deliver on their commitments rapidly and in a way that meets their needs.  As a result I believe that the best approach is a combination of governance and anarchy - govern the commitments assigned to the atomic parts of the business but delegate all further implementation concerns to the owners of these atomic units (and this obviously cascades downwards given the fractal nature of services).  In this context there may be many duplicated services implemented but this is OK; where there needs to be duplication to support independent operation or because individual services are not economically viable for implementation by a third party there can be, whilst for services that can economically be shared joint ventures or enterprising third parties will emerge to profitably fill these spaces in a way that is sustainable (i.e. the services can be profitably sold and thus sustained rather than just being an overhead and a source of drag on each provider - which is where the link back to my previous post pops in).  This approach contrasts with some of the more naive approaches to service-orientation I have seen where people obsess about forcing business units into the use of shared services that are not actually economically viable and which - at the same time - prevent them from adapting independently in response to market changes.  Essentially services become an onerous tax imposed by IT rather than a real enabler for change and value creation.

Decide what you need and then depend on the endless ingenuity of your colleagues, partners, customers and suppliers to deliver a response without trying to control how they deliver.  You’ll unleash a whole lot more innovation, much more rapidly - and that will be to everyone’s benefit.

:: :: :: :: :: :: :: :: :: ::

SOA and Market Forces

Just a quick comment on a post by Joe Mckendrick while I’ve been on holiday.  Essentially Joe discusses the need to demonstrate the value of IT - and hence SOA - through ensuring that people are charged correctly for their consumption.  As I’ve discussed many times I totally agree with this with one exception; basically I feel that organisations need to get a more coherent view of their business capabilities and then charge for the delivery of those capabilities.  At the end of the day IT has no value to an organisation beyond its contribution to the delivery of discernable business value.  As a result the requirement from my perspective is to use metrics and charging to surface two different but related issues for both the enterprise and the owners of individual capabilities:

1) Is the business capability offered to the enterprise at a competitive price; and 2) Does the cost of the IT needed to run my capability enable me to be competitive. 

I believe strongly that current one-size-fits-all approaches to enterprise architecture will rapidly be exposed as one-size-fits-nobody as capability owners understand the costs of IT provision and the enterprise gets better metrics with which to squeeze them. 

As a result, apportioning the costs of IT to each capability owner and then allowing them to cross charge for the total service that they offer seems to me a more visible and sustainable way of demonstrating value.

:: :: :: :: :: :: :: :: :: ::

Is BPEL4People really for The People by The People?

I was interested to read lately that the long and tortuous process of arriving at some level of human process support within BPEL continues.  Now I have to be honest and say that to me this seems like a really dumb concept.  If you look at service-orientation as a way of abstracting away from issues of implementation and concentrating on outcomes then I really don’t understand how creating an implementation specific extension makes any sense at all (implementation in terms of service realisation type rather than technology in this context).  What other specific kinds of service types are we going to implement?  BPEL4CICS?  BPEL4ESB?  all of which take account of the differences of implementation or interaction model forced by these implementation choices?  Surely any work that needs to be carried out by people is just another service with a contract, service level agreement and cost?  Yes there will need to be a suitable implementation of that service that supports its execution by people but the fact that the task is carried out by a human should surely be transparent to the consumer (which in this case is the BPEL process).  To be honest I have never been particularly keen on the idea of people support within BPEL as I have always viewed it as a standard which provides support for the creation of ‘Macro’ level processes that represent overall value-chains spanning services.  The services themselves will obviously require many specialised implementation methods but this is where service providers will compete and where technology providers will compete in supporting them most efficiently.  The value of BPEL appears to me to be that it allows us to leverage all services in a consistent way and so extensions to support a particular kind of implementation choice seem to lack elegance to me.

Equally importantly in this discussion, however, is the desirability of the kind of process support that BPEL can implement for people.  As I discussed in a previous post, increasing reliance on talent and the collaboration of talent for competitive differentiation means that the kinds of industrial age processes supported by standards like BPEL will be wholly insufficient.  Essentially BPEL implements pre-configured, task driven processes and cannot support the kinds of collaborative, human driven processes that we will increasingly need to leverage the talents that we have both within and across organisations.  As we increasingly automate the rote tasks - ably supported by BPEL - there will be diminishing returns available and certainly little or no competitive differentiation, since by definition anything that can be codified into a consistent transactional process can be copied.  As a result we need to concentrate on how we maximise the effectiveness of our people as they use their talent, discretion and imagination in responding to service requests in appropriate ways.  BPEL4People does not address these needs in any way since it simply treats people as transactional resources who will tick the pre-configured box as part of the wider machine. 

As a result I think that BPEL4People is a pointless exercise since it extends BPEL with unnatural concepts tailored towards a specific kind of service implementation whilst simultaneously failing to present us with a solution to the real problems of people centric processes.  I strongly believe that we need to accept that the issues to be addressed by transactional and tacit processes are very different and that we should therefore embrace these differences rather than try and create an inappropriate uber-model.  In both cases the concepts of service orientation can be used to offer up the resulting implementations in a consistent way - as long as we continue to adhere to interoperability standards in making the services available for consumption.  As an example Keith Harrison-Broninski talks about using services to allow interoperability between transactional processes implemented by BPEL and any supporting tacit processes implemented by Human Interaction Management products.  The key point in all of this, however, is that services will be realised in many different ways, often very specialised to the domain of implementation and I feel that we should recognise this rather than try and mix abstract process control across consistently described service interfaces with the special ways in which those services are implemented.

As a result I believe that BPEL should be left to cover the consistent orchestration of services irrespective of whether the services are implemented by machines or people and that other more promising techniques should be used to realise services appropriate to the way in which people really work.  The fact of the matter is that BPEL4People seems more like BPEL4Vendors to me; they all want to be seen as BPM vendors rather than integration vendors and in so doing appear to be missing the point completely by treating people like the machines they’re used to dealing with.  The irony of rigid process support appropriate to machine integration being touted as ‘for people’ seems as amusing as it is sad.  The shame is that many organisations will follow the lead of these technology companies as they muddy the water for their own ends and will therefore continue trying to squeeze their people into inappropriate processes that fail to deliver the support that people need in the new connected economy.  In particular, inappropriate use of BPEL4People due to the ‘people’ moniker will:

• Fail to support collaboration and talent amplification by setting out processes as a set of rigid tasks passed out to individuals;
• Constrain innovation in service delivery by assuming that processes can be designed and fixed in advance, making the contextual tailoring needed during human effort extremely difficult;
• Fail to deal with the increasingly dynamic reality at the edge of organisations through rigidity of process and thereby put strain on customer interactions by making them unnatural; and
• Destroy morale and productivity by forcing people to work in ways that are alien to them and in so doing become something to waste time working around rather than a valued support tool.

In many cases these issues will lead to the work being pushed out to people with no hope of actual process support, since there will be a recognition that they will work in some unstructured way to complete the broad task stated.  In this context the work disappears into the shadowlands of the unknown until someone helpfully comes back and updates the system (maybe) - not really a good way of tracking where we are with the mass of human effort that goes on within our organisations every day.

As a result the choice would appear to be to constrain people unacceptably or lose control over what they are doing.  Does that constitute BPEL4People?  Not for this person.

:: :: :: :: :: :: :: :: :: ::

SaaS, Appliances and Industrialisation

Picked up a couple of posts over the last few days with respect to on-premise SaaS offerings.  First up was Gianpaolo Carraro over at Microsoft talking about intra-preneurial SaaS.  This is a topic that I’ve discussed a number of times and whilst I’m in complete agreement that taking the benefits of SaaS into the enterprise is a good thing I also feel that it’s in enabling business capabilities to be delivered as services that the real value lies; i.e. conceiving of the organisation as a set of collaborating service providers rather than just encouraging the IT department to make applications available in a new way.  Such a model enables greater focus on the capabilities that actually add value to the organisation and prepare the ground for future unbundling by raising management purview to business capabilities in place of applications and technology.  In this context I was also delighted to see Gianpaolo describe the supporting infrastucture as a ’service delivery platform’, since to me the need to deliver such future business capabilities as viable services with proper management, reporting and monetisation is a critical requirement and one often overlooked by SOA implementors.  Taking this argument a bit further - especially given that the question originated from Sinclair Schuller over at SaaS blogs (who is connected with Apprenda) - the question for me is whether the service delivery platforms to enable intra-preneurial SaaS are better built in house or leveraged from external platform provders?  For me the answer is that enterprises should absolutely use external utility computing platforms to support the service enablement of their business capabilities and stop wasting time, money and brain power grubbing about in the weeds of technology.  A big issue with this currently, however, is one of trust; many large companies have not yet achieved a level of comfort with externally provided, multi-tenancy service platforms that would enable them to make this giant leap forward.

As a result of this I was delighted (again) to read a post by Phil Wainright over at ZDNet talking about SaaS appliances.  In this context I’m thinking more of the service delivery platform being delivered as a ‘SaaS appliance’ but the argument still holds.  As I stated in this post, I believe that there will be a place for both multi-tenancy and onsite utility computing provision and so again, I am in complete agreement that the provision of SaaS offerings need not always be across the network.  In fact I believe that ‘utility computing’ platforms will be available both in a centralised, multi-tenancy form but also as an on-premise option linked into the wider management processes of the service provider.  Either way the service provider can take advantage of standardisation and economies of scale across customers, even where some parts of the platform that they support are physically located outside of their data centre.  This ability to provide standard service delivery platforms across customers is, however, a key element of IT industrialisation, a topic discussed by Nick Carr in another recent post.  Nick’s post basically summarises an article that he’s written for the Guardian newpaper in the UK where he points out the increasingly onerus tasks of managing the infrastructure needed to deliver services in the new on-demand world; as an end enterprise who wants to concentrate on differentiating myself in my chosen market why wouldn’t I take advantage of the investments of infrastructure providers in the creation of bullet-proof service delivery platforms rather than continue to invest and suffer the pain of creating smaller scale, less reliable infrastructures for myself?  The beauty of all of this, however, is that I will increasingly be able to start small by delivering some initial services on utility platforms deployed within the bounds of my own organisation - since even there my costs will be lower than extending my current environment due to the infrastructural providers’ economies of scale - and transition away from my bespoke, costly environment over time.

:: :: :: :: :: :: :: :: :: :: ::

Getting IT "Just Right"

The more I read on Steve Jones blog the more I find to like about what he has to say.  One of his recent posts discusses the futility of trying to cover every eventuality by producing a paper trail long enough to circle the earth and the moon one million times.  I’m really interested in this whole area of ‘just enough’ consideration as I think that one of the keys to business agility is to make more appropriate decisions about solutions that match the reality of the business capability that requires them.

In one of my previous posts I’ve discussed the phenomenon (you’ll have to dig for it as the post wasn’t specifically about that) of ‘enterprise IT’ as often delivered by IT departments - and in particular enterprise architecture efforts -as basically being inappropriate for everyone rather than right for anyone; the basic premise was that:

• Small, nimble parts of an organisation have to contend with huge lumbering infrastructures enforced upon them at more cost than they can afford and more importantly that make everything move much more slowly than they can live with.  In particular - as Steve points out - IT departments generally want to consider every possible usage that could ever be made of a solution by every other part of the business and therefore deliver a solution that is way beyond appropriate “just in case” or alternatively force the new functionality into an existing ‘box’ even if its cost or capability isn’t wholly appropriate.  This includes the sorts of inappropriate questioning and high beaureacracy that Steve talks about, which is a result of trying to make everyone fit the same profile; and
• Larger business capabilities get an environment that may approximate to their needs but they also end up subsidising other areas of the business because they pay for infrastructure and software that then gets used by everyone.  This leads to all kinds of bun fights and ill feeling about who funds upgrades or extensions forced by capacity etc, particularly as IT departments are generally not able to deliver true shared services due to a lack of service enablement capability (i.e. service management, usage billing etc.).  At the same time whilst larger units may get appropriate IT from the context of scale or function they still chafe against the beaureacracy and tardiness of change that their supporting IT delivers.

In general the issue is threefold; basically IT people are a) looking to cover themselves against failure because they take such a beating from their business colleagues about value for money and so they try to imagine every potential future use case to protect themselves against accusations of ill-preparedness, b) they can only afford to manage a limited solution portfolio cost effectively and so try to squeeze every business need into this limited space - essentially the focus is on making life easier for the IT department by standardising rather than on delivering the right ’size’ of solution with the right characteristics at the right time and c) there has traditionally been a lack of abstractions that allow IT to understand what a ‘right sized’ solution looks like for each business capability that they deal with.  All of these things have traditionally resulted in the ’shadow IT’ so bemoaned by enterprise architects as end users take the issue into their own hands and bypass the IT department completely.

Now the reason that this area interests me is because service-orientation deals with the third issue and thereby enables us to think differently about the first two - i.e. it provides a set of abstractions that allow us to reason about the business capabilities that we need within the organisation, the levels of service we need from them and the costs we can afford to bear in their provision.  Essentially SOA breaks the organisation down into a set of collaborating service providers (i.e. capabilities) and thereby delivers an optimal problem solving layer not previously available.  Whereas in the past the problem solving layer has been the technology in the form of application portfolios - linked, if we’re lucky to some loose notion of business processes - the focus can now move to the ‘what’ in place of these ‘hows’.  This is a significant change as it allows us to see the wood for the trees by moving away from standardisation on applications and technology and into standardisation of capabilities.  This delivers a much clearer statement of the context in which IT needs to be delivered if it is to realise capabilities in a way most appropriate to the environment in which they operate - i.e. a capability that needs to be operated at low cost and which changes a lot is unlikely to be a good candidate for squeezing into the ERP implementation that we have; as a result we will need to find a way of providing service to this capability that much more closely matches their needs. 

So what does all this have to do with Steve’s post about people covering their arses?  Essentially I believe that this helps us in three main ways:

1. We can much more rapidly agree what needs to be delivered because we can have conversations with our business partners centred around what needs to be done rather than suffer the traditional impedance mismatch between business and IT.  This makes agreements - in the form of contracts, service levels and costs - much easier to formally document and removes a whole layer of arse covering from the process aimed at caveating everything to cope with the essential lack of understanding between the partners involved;
2. As IT people we can much more easily understand the needs of the business areas with whom we deal and rapidly see what level of provision is appropriate based on the characteristics of the capability i.e. does it differentiate? what scale does it operate at? how often does it change?  how much can we afford to pay for it? is it highly regulated? etc.  These characteristics give us a clear field of operation when considering the degree to which we need to cater for Albanian watch sellers (lol) and to therefore source IT that aligns more realistically with the needs of the consuming business capability.  This again removes the need for endless speculation about what might happen in 5 years time as the commitment of the IT organisation is either to deliver a service within the constraints identified or to decide that they can’t do it and help outsource the IT (or even the entire business capability) to an external provider; and
3. Separating the delivery of the IT required by different capabilities (at least logically) enables much more rapid change since we can reduce the dependencies between different business capabilities.  We do this by concentrating on service dependencies and shared capability rather than by forcing shared use of technology.  Where we do share technology - infrastructure, applications and platforms - we maximise the virtualisation of this provision so that we’re really offering shared technical capability on a multi-tenancy basis rather than trying to squeeze everyone together and thereby coupling them and reducing their ability to change independently.  This will require IT departments to either deliver real service delivery platforms - which include the capabilities needed to enable both themselves and their business partners to deliver what they do as a managed, billable service - or partner with external utility computing providers who can offer them this capability as a service.  Enabling much more rapid change by implementing a more flexible IT model would further reduce the need for arse covering as a) we would have a better relationship with our business partners due to improved service provision and b) changes can be accommodated much more rapidly and therefore the need to plan for all eventualities to save time ‘in the future, maybe’ would be much reduced.

All of these things drive towards putting much more pressure on the business to describe what they do and equally importantly on IT to make what they do far more transparent and to be more pragmatic in the way in which they do things.  Essentially as focus falls increasingly on getting the right IT at the right time and at the right cost IT departments can’t afford not to become far more flexible and less dogmatic, since the rise of SaaS and external service provision will increasingly give people easy alternatives to the monopoly we’ve enjoyed over the last 30 years.

:: :: :: :: :: :: :: :: :: :: ::