Archive | SOA RSS feed for this section

SOA vs Efficient & Agile vs Differentiation

7 Apr

One of my friends recently sent me an article from CIO connect that stated “IT Agility Trumps IT Efficiency”.  Essentially the drift of the argument was that agility was becoming a much greater driver than efficiency, citing a survey in which executives placed IT agility at the top of their wishlist.  Taking this point a little further the article suggested that many people now saw SOA as the best route to achieving greater IT agility and that this was now becoming the main motivator for adoption.

I obviously found this interesting but unsurprising – I’ve always believed that SOA was the quickest route to increasing agility and would only extend this to cover the use of service-orientation to organise the business around the delivery of services and not just the IT.

More broadly, however, I had some comments in relation to sources of sustainable differentiation and where it comes from; in this context I had some specific comments around efficiency and agility – the two options from the article. 

Now the big problem with efficiency is that it often becomes an end in itself.  Anything you can make more efficient is codifiable – whether through the use of SOA or not – and therefore can be copied by others.  Therefore efficiency is unlikely to be a long term differentiator.  Worse than that people who spend all of their time trying to be efficient gradually turn inwards and lose sight of why they were doing things in the first place (i.e. to give their customers what they want at best value). 

Interestingly, using SOA to realise greater agility is also not really a long term differentiator since having access to technology that allows you to change your codified processes more rapidly is fine but such technology is available to everyone and therefore agility as an end in itself ceases to be a reliable source of differentiation.  Whilst not moving to service-oriented business models in order to become adaptable will undoubtably be bad for your business, it cannot be considered a sustainable source of differentiation given that the option is there for everyone.  In this context it is more important to identify those services within your business that capture differentiating IP or talent and which would benefit from agility to keep you ahead of your competitors. 

In both of these instances the real advantage comes from recognising those services within the organisation that are key assets – and leveraging them mercilessly – whilst also identifying those things that are non-differentiating – and getting rid of them.  There is no point trying to invest in the efficiency or adaptability of non-core services since in that context you are just competing with other people in areas that provide no long term differentiation.

The only real and true differentiation is increasingly going to be in the 20% of services that encapsulate IP or amplify talent – true agility will therefore require us to codify non-differentiating capabilities and – where possible – get rid of them to specialised providers whilst maximising the leverage of the tacit knowledge we have in the form of our most talented people or the IP that they generate.  Ironically a search for control and efficiency in the new connected world will often disenfranchise the very people that we should give the greatest freedom to, stifling their judgement, talent and ability to create valuable relationships and in the process destroying a potent source of competitive advantage.

So is a search for efficiency and agility necessary?  The answer of course is yes but they are now just the way we win the right to stay in the game and not a source of competitive advantage by themselves.  A search for efficiency is often best realised through the leverage of partner services in place of endless tinkering with non-differentiating services of our own, whilst agility comes far more from our ability to leverage a web of partners who really care about service than from our own mediocre and uncaring supporting functions.  At the end of the day it’s how we deliver our service that matters and for this you need your best people in the front lines supported by technology that enables them to amplify their talent or maximise the leverage of IP but not driven by technology through highly restrictive processes in the pursuit of efficiency or wasting their valuable attention implementing and supporting agility in the wrong places.

BPM vs SOA – Why so hard?

7 Jan

Just wended my way through the blogosphere from Joe McKendrick’s discussion of EDA and SOA to a transcript of a conversation on EBizQ about the relationship between BPM and SOA.  I’m still struggling to come to terms with the issues that people have in this space given that I believe that service-orientation is all about structure – i.e. what gets done – whilst processes are all about implementation – i.e. how things get done – but a few things stood out in the conversation that I really disagreed with.

Firstly there was a general consensus that SOA was a technical ‘thing’ whilst BPM was a business ‘thing’.  A representative comment here would be this statement from JT Taylor:

“And the reason is, is because SOA, first off, as I’ve think we’ve agreed is a very technical approach to delivering a collection of services.”

Any regular reader of this blog will know that I wholly refute this kind of argument – at the end of the day SOA – or service orientation as I prefer to call it – is a conceptual model that allows us to attack complexity and increase adaptability through componentisation.  I strongly believe that this conceptual model has equal applicability in a business context – lowering transaction costs will open  the door to greater specialisation but such opportunities will rely on an ability to componentise the business in order to understand what services make up a total offering to customers.  In this context service-orientation – as a discipline – has much to offer.

The other major thrust that I took issue with was the assumption that you start with business processes and then try and find services from these.  Another representative set of comments from JT Taylor (who was supported by the other participants, I must stress – his comments were just the most quotable in this context):

“I guess my opinion is that the business processes should govern the organization behavior and systems should support that. So I would actually start from the process angle first and then take the SOA approach as an implementation approach.”

I’ve discussed before why I think that this is a poor model but basically I believe that we need to first separate what gets done before we start to get into the detail of how to do it.  As a result I believe that the appropriate place to start is with higher level abstractions – call them business capabilities, business services or whatever – which capture metadata and information about the structural properties of an organisation and their required outcomes – before you start looking at how you implement them.

More broadly, however, I believe that the relationship between SOA and BPM is essentially fractal based on the ‘what’ and ‘how’ dimensions I’ve discussed.  Essentially the questions are:

  • What do organisations offer their consumers? um services.
  • But what implements those services? um. business processes.
  • And what do business processes consume? um services.
  • And.. um where was I again?

Again to stress the point: services describe what the organisation does and to what level (in terms of metrics and commitments) whilst business processes describe how each individual service is implemented and the commitments met (and the model is fractal).  That’s why I believe that the notion of starting with BPM (which is a technology-oriented view of business processes, btw) is upside down – what’s the service you’re implementing again….?

Happy New Year, btw.

The Departing CIO

30 Oct
Everyone is different… aren’t they?

Just read a post by Nicholas Carr about the diminishing role of CIOs.  Not sure whether I am ready to believe that CIOs are not necessary yet but I certainly believe that they need to get their asses out of the dead end of operations and management of IT and much more into the role of trusted adviser to the board around innovation and access to the right services at the right cost.  Slightly tangentially, though, one comment really caught my attention.  Buried amongst a load of stuff about how CIOs were effectively being left marginalised by increasing technology maturity and commoditisation was the following comment answering a number of points from the post (original post content being commented on underlined):

Hopper, who predicted that IT would come to be thought of more like electricity or the telephone network than as a decisive source of organizational advantage.”

From a software perspective, I have my doubts that it will ever happen. The goal of IT is business process automation. But businesses processes are inherently different across businesses. For example, no two business does finance the same way. No two real estate company processes loans or property inspections the same way. Therefore, they each need their own specialized applications.”

Umm… why?

Umm… why?  Why do no two businesses do finance in the same way?  I accept that this may be the current state but I see no reason why this should be accepted as the right way?  What competitive differentiation does doing 80% of non-differentiating things in different ways provide to the organisations concerned?  Given the fact that I tend to believe strongly in capability driven organisations I can see a case for co-sourcing these functions with specialised providers – in that context no two finance providers will necessarily have the same processes but all other kinds of companies will increasingly just integrate these standardised offerings from third parties and will therefore absolutely share the same services – why wouldn’t they?  In this context the IT becomes just a component part of the shared capability being offered and thus the need for consuming organisations to each have their own applications in non-differentiating areas is gradually reduced over time.  This will increasingly occur across all capabilities that organisations have – they will outsource, co-source or share non-differentiating capabilities in order to concentrate on those that are truly differentiating, leveraging these outstanding capabilities into wider value networks to maximise their value whilst simultaneously multiplying their value by combining them with others best in class capabilities.  As I’ve discussed before, the capabilities around which an individual company wishes to differentiate itself may still need IT support to realise effectively but this will increasingly not require the ownership of that IT.

The bald truth

I’m getting fairly tired of having these conversations with people so let’s put it down in bullet form:

  • You are not special – 80% of what you do is not special and you’re just wasting money and attention competing with other people who are equally dumb.  Understand your capabilities, understand where you are special and unbundle the rest for pities sake – find specialised providers, talk to IT service companies about offloading the stuff or work with your competitors to pool resources.  In no circumstances be tempted to customise packages or implement applications or processes in non-differentiating capabilities – either deploy or (better still) gain access to standard offerings;
  • IT is not differentiating – Owning and operating IT gives you no competitive advantage; in fact it drains your resources, locks you into processes that are simultaneously uncompetitive and non-differentiating, is ridiculously expensive to scale or right-size and gives you your own islands of function that stagnate outside the rapid learning possible for IT service providers.  What you do with IT – in terms of process enablement for differentiating capabilities – may be important depending on your industry but you don’t need to own and operate the IT platforms required to do it any more than you need to own electricity infrastructure to work the photocopier – it’s increasingly going to become a utility and should be treated as such.

Different types of value

If we look at the types of value chains that organisations typically bundle together – and which we fully expect to be broken up over the next few years to recognise the differences in economics and culture needed to be successful in their provision – these points can perhaps we made a little clearer:

  • Physical value chain:  In this context certain capabilities require the ownership and leverage of physical assets. The economics of these capabilities respond strongly to economies of scale and therefore tend towards shared usage rather than differentiation for each organisation.  IT platforms are increasingly tending towards economies of scale and are therefore likely to be increasingly consolidated over the coming years – essentially building service platforms that enable services to be created, deployed and delivered scalably are capital intensive activities that drive them towards being shared.  In this context anyone who aims to own and operate their own bespoke IT platforms and operations in the longer term is probably not concentrating effectively. 
  • Transactional value chain:  In this value chain we have information resources and business processes that implement capabilities.  These capabilities again tend towards economies of scale as 80% of capabilities are non-differentiating to individual organisations – as a result we would expect to see the emergence of specialised providers who leverage economies of scale by offering their capabilities for integration into the wider value web of their customers and partners.  In that context, again, trying to build and operate applications that you customise to allow you to execute non-differentiating capabilities – such as the finance example given originally – in ways which are different to others is a waste of time, money and focus.  For your own specialisation, however, you would absolutely want to create bespoke applications and services to support you in your endeavors but given the previous discussion on physical value chains you would want to ensure that you don’t have to take on the ownership and management of the platforms needed to do this – rather you would want to reduce risk and capital exposure by leveraging partners that can offer such service platforms to you on demand.
  • Knowledge value chain:  Knowledge value chains absolutely represent differentiation for your organisation as by definition you are dealing in capabilities that have knowledge and IPR not available to others.  Perversely, however, this does not mean that you necessarily need any particularly differentiating IT as software that enables you to capture, develop and leverage knowledge will be available in the transactional value chain.  Again in this context IT is not a differentiator and you need to focus on using standard applications and services to support you in your IP creation and leverage.

 So just stop

In breaking down the typical organisation we can see that IT provides very little differentiation in the majority of the work that gets done.  Platforms will increasingly be consolidated and shared, removing a large part of the IT related work that most organisations currently spend time and energy getting stressed about.  There will be some applications and services that represent your differentiation but in this context you will increasingly be using shared platforms to compose and deliver these services in ways that are different from the IT delivery of the past.  The challenge for CIOs is to understand how they remove themselves from daily battles trying to keep their heads above water in the physical value chain and concentrate more on helping their business colleagues to unbundle non-differentiating capabilities from the transactional value chain to improve focus and performance and on finding the best platform partner to rapidly compose differentiating capabilities that represent valuable IPR for their company.

Enterprise Architecture is yesterday’s news

19 Oct

Amazed to find this post that suggests that Enterprise Architecture is the next big thing.  I thought that EA was a late 90s, early 00s silver bullet and that we were now all moving on to a concentration on fractal business architectures supported by federated IT.  Now I realise that judicious EA can encompass this view – indeed that it should – but realistically EA as a term was hijacked by geeks who used it to enforce technical standards and who gibbered at their business colleagues in a threatening way about governance and compliance whilst creating impenetrable mountains of useless documentation that was out of date as soon as it was created (and made no sense to business people or developers). 

Worse than that most EA practitioners genuinely believe that they can document the whole organisation top down in a complex chain of dependencies – a horrible fallacy in a world of federation – and then micro-govern people by putting cumbersome processes in the way of getting anything done (and given the difficulty (nay – impossibility) of doing this they end up obsessing on forcing shared and inappropriate IT on people instead of supporting business improvement). 

Taking it all a bit further it’s also unfortunate that most EA efforts top out at business processes (rather than capabilities) and so are a pure expression of how things get done rather than a sensible framework for enabling decisions about what should be done (I enjoyed Steve Jones’s post about this very issue).

Before I get flamed to the extent that I am consumed by a terrible conflagration I have to say a couple of other things; are the aims of EA crazy (i.e. to understand and govern the organisation)?  Umm, no.  Should we still be seeking to do this?  Umm, yes.  Does the kind of top down, all encompassing approach taken by most EA efforts actually work?  Umm, no.  By saying that EA is no longer useful I’m basically saying that the concept is absolutely right, it is more necessary than ever in a world of services – indeed services could be the missing abstraction that finally fill the gap between intent and execution – but that initial efforts in this direction didn’t take sufficient notice (indeed why would they have) of unbundling and federation.  So I believe that EA needs to evolve to help govern the portfolio of capabilities required by an organisation to function and to include some light touch policies that specify how they should work together.  Below this level we start again, essentially with a smaller EA for each capability, recognising federation and unbundling will remove our ability to control every aspect of the way that an organisation works centrally and from top to bottom – EA essentially needs to become explicitly fractal.

Either way I’m not sure that EA is the next big thing, but then again maybe I’ve just dreamt all of this and the future is bright etc.

It’s about umm… Services, duh!

10 Oct


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 (, 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.


 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

21 Sep
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. 


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?

15 Sep

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

11 Sep

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.

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.

Bottom Up or Top Down (ahem)

2 Aug

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

2 Aug

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.


Get every new post delivered to your Inbox.

Join 172 other followers