Industrialised Service Delivery Redux II

In my previous post I discussed the way in which our increasingly sophisticated use of the Web is creating an unstoppable wave of change in the global business environment.  This resulting acceleration of change and expectation will require unprecedented organisational speed and adaptability whilst simultaneously driving globalisation and consumerisation of business.  I discussed my belief that companies will be forced to reform as a portfolio of systematically designed components with clear outcomes and how this kind of thinking changes the relationship between a business capability and its IT support.  In particular I discussed the need to create industrialised Service Delivery Platforms which vastly increase the speed, reliability and cost effectiveness of delivering service realisations. 

In this post I’ll to move into the second part of the story where I’ll look more specifically at how we can realise the industrialisation of service delivery through the creation of an SDP.

Industrialisation 101

There has been a great deal written about industrialisation over the last few years and most of this literature has focused on IT infrastructure (i.e. hardware) where components and techniques are more commoditised.  As an example many of my Japanese colleagues have spent decades working with leaders in the automotive industry and experienced firsthand the techniques and processes used in zero defect manufacturing and the application of lean principles. Sharing this same mindset around reliabliity, zero defect and technology commoditisation they created a process for delivering reliable and guaranteed outcomes through pre-integration and testing of combinations of hardware and software.  This kind of infrastructure industrialisation enables much higher success rates whilst simultaneously reducing the costs and lead times of implementation. 

In order to explore this a little further and to set some context, let’s Just think for a moment about the way in which IT has traditionally served its business customers.  

We can see that generally speaking we are set a problem to solve and we then take a list of products selected by the customer – or often by one of our architects applying personal preference – and we try to integrate them together on the customers site, at the customers risk and at the customers expense. The problem is that we may never have used this particular combination of hardware, operating systems and middleware before – a problem that worsens exponentially as we increase the complexity of the solution, by the way – and so there are often glitches in their integration, it’s unclear how to manage them and there can’t be any guarantees about how they will perform when the whole thing is finally working. As a result projects take longer than they should – because much has to be learned from scratch every time – they cost a lot more than they should – because there are longer lead times to get things integrated, to get them working and then to get them into management – and, most damningly, they are often unreliable as there can be no guarantees that the combination will continue to work and there is learning needed to understand how to keep them up and running.

The idea of infrastructure industrialisation, however, helps us to concentrate on the technical capability required – do you want a Java application server? Well here it is, pre-integrated on known combinations of hardware and software and with manageability built in but – most importantly – tested to destruction with reference applications so that we can place some guarantees around the way this combination will perform in production.  As an example, 60% of the time taken within Fujitsu’s industrialisation process is in testing.  The whole idea of industrialisation is to transfer the risk to the provider – whether an internal IT department or an external provider – so that we are able to produce consistent results with standardised form and function, leading to quicker, more cost effective and reliable solutions for our customers.

Now such industrialisation has slowly been been maturing over the last few years but – as I stated at the beginning – has largely concentrated on infrastructure templating – hardware, operating systems and middleware combined and ready to receive applications.  Recent advances in virtualisation are also accelerating the commoditisation and industrialisation of IT infrastructure by making this templating process easier and more flexible than ever before.  Such industrialisation provides us with more reliable technology but does not address the ways in which we can realise higher level business value more rapidly and reliably.  The next (and more complex) challenge, therefore, is to take these same principles and apply them to the broader area of business service realisation and delivery.  The question is how we can do this?

Industrialisation From Top to Bottom

Well the first thing to do is understand how you are going to get from your expression of intent – i.e. the capability definitions I discussed in my previous post that abstract us away from implementation concerns – through to a running set of services that realise this capability on an industrialised Service Delivery Platform. This is a critical concern since If you don’t understand your end to end process then you can’t industrialise it through templating, transformation and automation.

In this context we can look at our capability definitions and map concepts in the business architecture model down to classifications in the service model.  Capabilities map to concrete services, macro processes map to orchestrations, people tasks map to workflows, top level metrics become SLAs to be managed etc. The service model essentially bridges the gap between the expression of intent described by the target business architecture and the physical reality of assets needed to execute within the technology environment.

From here we broadly need to understand how each of our service types will be realised in the physical environment – so for instance we need a physical host to receive and execute each type of service, we need to understand how SLAs are provisioned so that we can monitor them etc. etc.

Basically the concern at this stage is to understand the end to end process through which we will transform the data that we capture at each stage of the process into ever more concrete terms – all the way from logical expressions of intent through greater information about the messages, service levels and type of implementation required, through to a whole set of assets that are physically deployed and executing on the physical service platform, thus realising the intent.

The core aim of this process must be to maximise both standardisation of approach and automation at each stage to ensure repeatability and reliability of outcome – essentially our aim in this process is to give business capability owners much greater reliability and rapidity of outcome as they look to realise business value.  We essentially want to give guarantees that we can not only realise functionality rapidly but also that these realisations will execute reliably and at low cost.  In addition we must also ensure that the linkage between each level of abstraction remains in place so that information about running physical services can be used to judge the performance of the capability that they realise, maximising the levers of change available to the organisation by putting them in control of the facts and allowing them to ‘know sooner’ what is actually happening.

Having an end to end view of this process essentially creates the rough outline of the production line that needs to be created to realise value – it gives us a feel for the overall requirements.  Unfortunately, however, that’s the nice bit, the kind of bit that I like to do. Whilst we need to understand broadly how we envisage an end to end capability realisation process working, the real work is in the nasty bit – when it comes to industrialisation work has to start at the bottom.

Industrialisation from Bottom to Top

If you imagine the creation of a production line for any kind of physical good they obviously have to be designed to optimise the creation of the end product. Every little conveyer belt or twisty robot arm has to be calibrated to nudge or weld the item in exactly the same spot to achieve repeatability of outcome. In the same way any attempt to industrialise the process of capability realisation has to start at the bottom with a consideration of the environment within which the final physical assets will execute and of how to create assets optimised for this environment as efficiently as possible. I use a simple ‘industrialisation pyramid’ to visualise this concept, since increasingly specialised and high value automation and industrialisation needs to be built on broader and more generic industrialised foundations. In reality the process is actually highly iterative as you need to continually be recalibrating both up and down the hierarchy to ensure that the process is both efficient and realises the expressed intent but for the sake of simplicity you can assume that we just build this up from the bottom.

So let’s start at the bottom with the core infrastructure technologies – what are the physical hosts that are required to support service execution? What physical assets will services need to create in order to execute on top of them? How does each host combine together to provide the necessary broad infrastructure and what quality of service guarantees can we put around each kind of host? Slightly more broadly, how will we manage each of the infrastructure assets? This stage requires a broad range of activity not just to standardise and templatise the hosts themselves but also to aggregate them into a platform and to create all of the information standards and process that deployed services will need to conform to so that we can find, provision, run and manage them successfully.

Moving up the pyramid we can now start to think in more conceptual terms about the reference architecture that we want to impose – the service classifications we want to use, the patterns and practices we want to impose on the realisation of each type, and more specifically the development practices.  Importantly we need to be clear about how these service classifications map seamlessly onto the infrastructure hosting templates and lower level management standards to ensure that our patterns and practices are optimised – its only in this way that we can guarantee outcomes by streamlining the realisation and asset creation process. Gradually through this definition activity we begin to build up a metamodel of the types of assets that need to be created as we move from the conceptual to the physical and the links and transformations between them. This is absolutely key as it enables us to move to the next level – which I call automating the “means of production”.

This level becomes the production line that pushes us reliably and repeatably from capability definition through to physical realisation. The metamodel we built up in the previous tier helps us to define domain specific languages that simplify the process of generating the final output, allowing the capture of data about each asset and the background generation of code that conforms to our preferred classification structure, architectural patterns and development practices. These DSLs can then be pulled together into “factories” specialised to the realisation of each type of asset, with each DSL representing a different viewpoint for the particular capability in hand.  Individual factories can then be aggregated into a ‘capability realisation factory’ that drives the end to end process.  As I stated in my previous post the whole factory and DSL space is mildly controversial at the moment with Microsoft advocating explicit DSL and factory technologies and others continuing to work towards MDA or flexible open source alternatives.  It is suffice to say in this context that the approaches I’m advocating are possible via either model – a subject I might return to actually with some examples of each (for an excellent consideration of this whole area consult Martin Fowler’s great coverage, btw).

The final level of this pyramid is to actually start taking the capability realisation factories and tailoring them for the creation of industry specific offerings – perhaps a whole set of ‘factories’ around banking, retail or travel capabilities. From my perspective this is the furthest out and may actually not come to pass; despite Jack Greenfield’s compelling arguments I feel that the rise of SOA and SaaS will obviate the need to generate the same application many times by allowing the composing of solutions from shared utilities.  I feel that the idea of an application or service specific factory assumes a continuation of IT oversupply through many deployments; as a result I feel that the key issue at stake in the industrialisation arena is actually that of democratising access to the means of capability production by giving people the tools to create new value rapidly and reliably.  As a result I feel that improving the reliability and repeatability of capability realisation across the board is more critical than a focus on any particular industry. (This may change in future with demand, however, and one potential area of interest is industry specific composition factories rather than industry specific application generation factories). 

Delivering Industrialised Services

So we come at last to a picture that demonstrates how the various components of our approach come together from a high level process perspective.

Across the top we have our service factory. We start on the left hand side with capability modelling, capturing the metadata that describes the capability and what it is meant to do. In this context we can use a domain specific language that allows us to model capabilities explicitly within the tooling. Our aim is then to use the metadata captured about a capability to realise it as one or more services. In this context information from the metamodel is transformed into an initial version of the service before we use a service domain language to add further detail about contracts, messages and service levels. It is important to note that at this point, however, the service is still abstract – we have not bound it to any particular realisation strategy. Once we have designed the service in the abstract we can then choose an implementation strategy – example classifications could be interaction services for Uis, workflow services for people tasks, process services for service orchestrations, domain services for services that manage and manipulate data and integration services that allow adaptation and integration with legacy or external systems.

Once we have chosen a realisation strategy all of the metadata captured about the service is used to generate a partially populated realisation of the chosen type – in this context we anticipate having a factory for each kind of service that will control the patterns and practices used and provide guidance in context to the developer.

Once we have designed our services we now want to be able to design a virtual deployment environment for them based wholly on industrialised infrastructure templates. In this view we can configure and soft test the resources required to run our services before generating provisioning information that can be used to create the virtual environment needed to host the services.

In the service platform the provisioning information can be used to create a number of hosting engines, deploy the services into them, provision the infrastructure to run them and then set up the necessary monitoring before finally publishing them into a catalogue. The Service Platform therefore consists of a number of specialised infrastructure hosts supporting runtime execution, along with runtime services that provide – for example – provisioning and eventing support.

The final component of the platform is what I call a ‘service wrap’. This is an implementation of the ITSM disciplines tailored for our environment. In this context you will find the catalogue, service management, reporting and metering capabilities that are needed to manage the services at runtime (this is again a subset to make a point). In this space the service catalogue will bring together service metadata, reports about performance and usage plus subscription and onboarding processes.  Most importantly there is a strong link between the capabilities originally required and the services used to realise them, since both are linked in the catalogue to support business performance management. In this context we can see a feedback loop from the service wrap which enables capability owners to make decisions about effectiveness and rework their capabilities appropriately.

Summary

In this second post of three I have demonstrated how we can use the increasing power of abstraction delivered by service-orientation to drive the industrialisation of capability realisation.  Despite current initiatives broadly targeting the infrastructure space I have discussed my belief that full industrialisation across the infrastructure, applications, service and business domains requires the creation and consistent application of known patterns, processes, infrastructures and skills to increase repeatability and reliability. We might sacrifice some flexibility in technology choice or systems design but increasing commoditisation of technology makes this far less important than cost effectiveness and reliability. It’s particularly important to realise that when industrialising you need to understand your end to end process and then do the nasty bit – bottom up in excruciating detail.

So in the third and final post on this subject I’m going to look a little bit at futures and how the creation of standardised and commoditised service delivery platforms will affect the industry more broadly – essentially as technology becomes about access rather than ownership so we will see the rise of global service delivery platforms that support capability realisation and execution on behalf of many organisations.

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

Industrialised Service Delivery Redux I

I’ve been terribly lax with my posting of late due to pressures of work but thought I had best try and put something up just to keep my blog (barely) alive, lol.  Following on from my previous posts on Cloud Computing and Service Delivery Platforms I thought I would go the extra step and actually talk about my views on Industrialisation in the platform and service delivery spaces.  I made this grand decision since my last post included a reference to a presentation that I did in Redmond last year and so I thought it would be useful to actually tell the story as well as just punt up the slides (which can be pretty meaningless without a description).  In addition there’s also been a huge amount of coverage of both cloud computing, platform as a service and industrialisation lately and so it seemed like revisiting the content of that particular presentation would be a good idea.  If I’m honest I also have to admit that I can largely just rip the notes out of the slideset for a quick post, but I don’t feel too guilty given that it’s a hot topic, lol.  I’ll essentially split this story across three posts: part I will cover why I believe Industrialisation is critical to supporting agility and reliability in the new business environment, part II will cover my feelings on how we can approach the industrialisation of business service delivery and part III will look at the way in which industrialisation accelerates the shift to shared Service Delivery Platforms (or PaaS or utility computing or cloud computing – take your pick).

The Industrialisation Imperative

So why do I feel that IT industrialisation is so important?  Well essentially I believe that we’re on the verge of some huge changes in the IT industry and that we’re only just seeing the very earliest signs of these through the emergence of SOA, Web 2.0 and SaaS/PaaS. I believe that organisations are going to be forced to reform and disaggregate and that technology will become increasingly commoditised. Essentially I believe that we all need to recognise these trends and learn the lessons of industrialisation from other more mature industries – if we can’t begin to deliver IT that is rapid, reliable, cost effective and – most importantly – guaranteed to work then what hope is there?  IT has consistently failed to deliver expected value time and time again through an obsession with technology for it’s own sake and the years of cost overruns, late delivery and unreliability are well documented; too often projects seem to ignore the lessons of history and start from ground zero. This has got to change. Service orientation is allowing us to express IT in ways that are closer to the business than ever before, reducing the conceptual gap that has allowed IT to hide from censure behind complexity. Software as a Service is starting to prove that there are models that allow us to deliver the same function to many people with lower costs born of economies of scale and we’re all going to have to finally recognise that everyone is not special, that they don’t need that customisation or tailoring for 80% of what they do and that SOAs assistance in refocusing on business value will draw out the lunacy of many IT investments.

In this three part post I therefore want to share some of my ideas around how we can industrialise IT. Firstly, I’m going to talk about the forces that are acting on organisations that will drive increasing specialisation and disaggregation and go onto to discuss business capabilities and how they accelerate the commoditisation of IT.  Secondly, I’m going to discuss  approaches to the industrialisation of service delivery and look at the different levels of industrialisation that need to be considered.  Finally I’ll talk about how the increasing commoditisation and standardisation of IT will accelerate the process of platform consolidation and the resulting shift towards models that recognise the essentially scale based economics of IT platform provision.

The Componentisation of Business

Over the last 100 years we’ve seen a gradual shift towards concentration on smaller levels of business organisation due to the decreasing costs of executing transactions with 3rd parties. Continuing discontinuities around the web are sending these transaction costs into free fall, however, and we believe that this is going to trigger yet another reduction in business aggregation and cause us to focus on a smaller unit of business granularity – the capability (for an early post on this subject see here).

Essentially I believe that there are four major forces that will drive organisations to transform in this way:

1) Accelerating change;

2) Increasing commoditisation; and

3) Rapidly decreasing collaboration costs due to the emergence of the web as a viable global business network.

I’ll consider each in turn.

Accelerating Change

As the rate of change increases, so adaptability becomes a key requirement for survival. Most organisations are currently not well suited for this challenge, however, as they have structures carried over from a different age based on forward planning and command and control – they essentially focus inwards rather than outwards. The lack of systematic design in most organisations means that they rarely understand clearly how value is delivered and so cannot change effectively in response to external demand shifts. In order to become adaptable, however, organisations need to systematically understand what capabilities they need to satisfy demand and how these capabilities combine to deliver value – a systematic view enables us to understand the impact of change and to reconfigure our capabilities in response to shifts in external demand.

Increasing Commoditisation

This capability based view is also extremely important in addressing the shrinking commoditisation cycle. Essentially consumers are now able to instantly compare our goods and services with those from other companies – and switch just as quickly. A capability-based view enables us to ensure that we remove repetition and waste across organisational silos and replace these with shared capabilities to maximise our returns, both while the going is good but also when price sensitivity begins to bite.

Decreasing Transaction Costs

The final shift is to use our clearer view of the capabilities we need to begin thinking about those that are truly differentiating – the market will be putting such pressure on us to excel that we will be driven to take advantage of falling transaction costs and the global nature of the web to replace our non-differentiating capabilities with those of specialised partners, simultaneously increasing our focus, improving our overall proposition and reducing costs.

As a result of these drivers we view business capabilities as a key concept in the way in which we need to approach the industrialisation of services.

Componentisation Through Business Capabilities

So I’ve talked a lot about capabilities – how do they enable us to react to the discontinuities that I’ve discussed? Well to address the issues of adaptability and understand which things we want to do and which we want to unbundle we really need a way of understanding what the component parts of our organisation are and what they do.

Traditionally organisations use business processes, organisational structures or IT architectures as a way of expressing organisational design – perhaps all three if they use an enterprise architecture method. The big problem with these views, however, is that they tell us very little about what the combined output actually is – what is the thing that is being done, the essential business component that is being realised? Yes I understand that there are some people doing stuff using IT but what does it all amount to? Even worse, these views of the business are all inherently unstable since they are expressions of how things get done at a point in time; as a result they change regularly and at different rates and therefore make trying to understand the organisation a bit like catching jelly – you might get lucky and hold it for a second but it’ll shift and slip out of your grasp. This means that leaders within the organisation lack a consistent decision making framework and see instead a constantly shifting mass of incomplete and inconsistent detail that make it impossible to make well reasoned strategic decisions.

Capabilities bring another level of abstraction to the table; they allow us to look at the stable, component parts of the organisation without worrying about how they work. This gives us the opportunity to concentrate systematically on what things the organisation needs to do – in terms of outputs and commitments – without concerning ourselves with the details of how these commitments will be realised. This enables enterprise leaders to concentrate on what is required whilst delegating implementation to managers or partners. Essentially they are an expression of intent and express strategy as structure. Capabilities are then realised by their owners using a combination of organisational structures, role design, business processes and technology – all of which come together to deliver to the necessary commitments.

In this particular example we see the capability from both the external and internal perspectives – from the perspective of the business designer and the consumer the capability is a discrete component that has a purpose – in this case enabling us to check credit histories – and a set of metrics – for simplicity we’ve included just service level, cost and channels. From the perspective of the capability owner, however, the capability consists of all of the different elements needed to realise the external commitments.

So how does a shift to capabilities affect the relationship between the organisation and its IT provision?

IT Follows Move from “How” to “What”

One of the big issues for us all is that a concentration on capabilities will begin to push technology to the bottom of the stack – essentially it becomes much more commoditised.

Capability owners will now have a much tighter scope in the form of a well defined purpose and set of metrics; this gives them greater clarity and leaves them able to look for rapid and cost effective realisation rather than a mismash of hardware, software or packages that they then need to turn into something that might eventually approximate to their need.  Furthermore the codification of their services will expose them far more clearly to the harsh realities of having to deliver well defined value to the rest of the organisation and they will no longer be able to ‘lose’ the time and cost of messing about with IT in the general noise of a less focused organisation.

As a result capability owners will be looking for two different things:

1) Is there anyone who can provide this capability to me externally to the level of performance that I need – for instance SaaS or BPU offering available on a usage or subscription basis; or

2) Failing that who can help me to realise my capability as rapidly, reliably and cost effectively as possible.

The competition is therefore increasingly going to move away from point technologies – which become increasingly irrelevant – and move towards the delivery of outcomes using a broad range of disciplines tightly integrated into a rapid capability realisation platform.

Such realisation platforms – which I have been calling Service Delivery Platforms to denote their holistic nature – require us to bring infrastructure, application, business and service management disciplines into an integrated, reliable and scalable platform for capability realisation, reflecting the fact that service delivery is actually an holistic discipline and not a technology issue. Most critically – at least from our perspective – this platform needs to be highly industrialised; built from repeatable, reliable and guaranteed components in the infrastructure, application, business and service dimensions to guarantee successful outcomes to our customers.

So what would a Service Delivery Platform actually look like?

A Service Delivery Platform

In this picture I’ve surfaced a subset of the capabilities that I believe are required in the creation of a service delivery platform suitable for enterprise use – I’m not being secretive, I just ran out of room and so had to jettison some stuff.

If we start at the bottom we can see that we need to have highly scalable and templatised infrastructure that allows us to provide capacity on demand to ensure that we can meet the scaling needs of capability owners as they start to offer their services both inside and outside the organisation.

Above this we have a host of runtime capabilities that are needed to manage services running within the environment – identity management, provisioning, monitoring to ensure that delivered services meet their service levels, metering to support various monetisation strategies both from our perspective and from the capability owners perspective, audit and non-repudiation and brokering to external services in order to keep tabs on their performance for contractual purposes.

Moving up we have a number of templatised hosting engines – essentially we need to break the service space down using a classification to ensure that we are able to address different kinds of services effectively. These templates are essentially virtual machines that have services deployed into them and which are then delivered on the virtualised hardware; essentially the infrastructure becomes part of the service to decouple services both from each other and physical space.

The top level in the centre area is what we call service enablement. In this tier we essentially have a whole host of services that make the environment workable – examples that we were able to fit in here are service catalogue, performance reporting, subscription management – the whole higher level structure that brings services into the wider environment in a consistent and consumable way.

Moving across the left we can see that in order to deliver services developers will need to have standardised and templatised shared development support environments to support collaboration, process enablement and asset management.

Across on the right we have operational support – this is where we place our ITIL/ISO 20000 service management processes and personnel to ensure that all services are treated as assets – tracked, managed, reported upon, capacity managed etc etc.

On the far right we have a business support set of capabilities that support customer queries about services, how much they’ve been charged and where we also manage partners, perform billing or carry out any certification activity if we want to create new templates for inclusion in the overall platform.

Finally across the top we have what I call the ‘service factory’ – a highly templatised modelling and development environment that drives people from a conceptual view of the capabilities to be realised down through a process of service design, realisation and deployment against a set of architectural and development patterns represented in DSLs.  These DSLs could be combinations of UML profiles, little languages or full DSLs implemented specifically for the service domain.

Summary

In this post I have discussed my views on the way in which businesses will be forced to componentise and specialise and how this kind of thinking changes the relationship between a business capability and its IT support.  I’ve also briefly highlighted some of the key features that would need to be present within an holistic and industrialised Service Delivery Platform in order to increase the speed, reliability and cost effectiveness of delivering service realisations.  In the next post I’ll to move into the second part of the story where I’ll look more specifically at realising the industrialisation of service delivery through the creation of an SDP.

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

SOA vs Efficient & Agile vs Differentiation

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.

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

Stability, Relationships and Institutional Innovation as Pillars of Success

Just read a few pieces from John Hagel – one of my favourite writers – whilst catching up on my blog backlog.  Essentially two posts caught my attention, one describing some areas of concentration for the coming year and another exploring the concept of institutional innovation.  Both of these posts resonated strongly with me and I felt that elements of both were strongly – even inextricably – linked together.

The two main points from the first post that caught my attention were around the value of stability in a changing world and on the decreasing value of transactional behaviour.  These ideas were reinforced by the second post about institutional innovation as I believe that such transformational innovation requires us to recognise the need for stability whilst simultaneously downplaying transactional behaviour in favour of mutually beneficial relationships.

I’ll explore this a little further.

The importance of internal stability

I’ve discussed many times how I believe that in order to be successful in a rapidly changing world we need to look at the structural properties of our organisations before considering how they work.  In this context understanding the capabilities that we need to be successful – along with the metrics that they need to support – is a key lever to greater organisational adaptability.  This is so since these abstractions allow us to concentrate on what we need to achieve whilst burying the detail of how we achieve it to prevent ourselves from being overwhelmed and therefore powerless to act decisively.  Equally importantly, however, a concentration on structural components and their relationships allows us to escape from tightly coupled process-oriented thinking and move to an organisational style that is more loosely coupled and output-driven. 

In this discussion, however, the key characteristic of interest in a structural view is that of stability – essentially a structural, capability based view of an organisation is far more stable than a dynamic, process-oriented one.  This is because the things that we do broadly remain static over time whilst the way in which we do them can be impacted hugely by influences such as technology advances, economic pressures or the talent pool we have at our disposal.

As increasingly rapid change impacts our organisations and forces us to rethink how we do things, the value of understanding explicitly what we do cannot be overstated.  Chaos ensues when people have no fixed reference points around which to manage change; a stable view of intent, however, allows us to have the benefit of both worlds – a stable understanding of things that need to be achieved and therefore a clear field of operations in which to implement change in a decisive and systematic fashion. 

The importance of external stability

Taking this thinking to the next level, increasing pressures on organisations will increasingly force them to look at the set of capabilities that they have and decide which ones represent their core areas of expertise (it is worth stating here that this is another, related reason to take a systematic view of the capabilities an organisation needs but that is assumed in this post).  This choice will increasingly be driven by economic forces and so – to use another of John’s broad ideas – organisations will need to decide whether they major on customer relationships, infrastructure or innovation.  Making this decision will be a further expression of stability at the macro level, however, since our organisation will now be signaling to its wider ecosystem that it has capabilities of a particular nature that can be leveraged and also that it will be looking for partners to provide other elements of the value chain on its behalf.  At the top level well positioned service providers can therefore become points of stability in the changing landscape of an industry, enhancing both their own positions but also providing reference points to new entrants trying to excel in a different section of the value chain. 

The futility of transactional behaviour

One of the key issues that emerges as we begin to seek complementary services from partners is the nature of the relationships we wish to build.  Current transactional based thinking would tend to treat partners as ’suppliers’ held at arms length and squeezed for the minimum costs sustainable.  This approach ignores the far greater benefits to be accessed by building and leveraging these relationships to achieve profitable and sustainable growth on both sides and represent a zero sum game in place of efforts to mutually grow the available opportunities.  Many kinds of emerging relationships – whether those lauded by social networking advocates mentioned by John or those enabled by increasing B2B information exchanges – are merely transactional in nature and not relationships in the true sense of the word.  If we are to maximise our opportunities and accelerate the improvement of our chosen capabilities then we must build deeper relationships in place of impersonal transactions in order to leverage complementary expertise and expand our influence and opportunities into new markets.

The increasing importance of deepening relationships

Increasingly we are seeing a shift away from consumer-supplier relationships where one side owns the power towards a situation in which different organisations are composing value for customers out of their complementary capabilities.  In this context relationships are of far greater value than the lowest possible cost because we now need to leverage our combined talents to improve all of our services and by extension the overall result as experienced by the end customer.  We are therefore going to be looking to leverage our different perspectives and expertise in order to look at the overall value being created and to realign our individual services to improve the output of our joint activities

Two points in particular stood out for me in John’s post in the context of relationships:

• Deep relationships become increasingly valuable in times of widespread change;
• in fact, deep relationships are essential to capture the full value of weak ties.

Again one of the broader questions around the need for stability is what and who we can count on to help us make sense of the changes that are happening around us.  In this context the deeper our relationships with our partners the more we can both consider them a point of stability and support as we deal with change but also the broader range of perspectives and insight we have in making sense of change and in deciding how to react most effectively. 

In the second case it is worth highlighting the fact that deep relationships do not automatically infer tight integration.  In building relationships with partners who will offer their complementary capabilities to us we need to ensure that we deliver the loosest possible coupling between our respective services.  Counter-intuitively perhaps this is not because we wish to return to a view of our partner as a supplier to be easily swapped out but rather that we wish to give them the maximum scope for innovation in the services that they deliver to us.  In this context – again counter-intuitively perhaps – we require much deeper relationships and trust to be in place before we will consent to the loose coupling required to maximise innovation – the natural tendency when we unbundle capability to another is to want to understand and control the way in which things are done on our behalf.  This is limiting behaviour since we fail to take advantage of the complementary expertise of the specialised partner and instead continue to project our inadequacies onto their delivery and constrain their ability to deliver the best possible service on our behalf.  Breaking this habit requires deep and trusting relationships, however, since the more interdependent we become the more we each depend upon the other for mutual success and therefore the more we tend to want to feel in control.

Leveraging stability and deep relationships to realise institutional innovation

These ideas around the importance of stability and the inadequacy of transaction thinking lead onto a consideration of John’s other post around institutional innovation.  Developing a stable view of your organisation, zeroing in on your key capabilities and then concentrating on changing the nature of your relationships with partners can open the door to the benefits of institutional innovation:

Stability:  We know what we do and what our partners do and so can successfully build relationships around these points of stability.  We have a context for innovation across organisational boundaries.

Modularity:  A shift to a stable view also drives a more modular approach.  We can therefore minimise coupling and maximise innovation opportunities.  We therefore have a context for distributed and deconflicted innovation implementation.

Relationships:  Developing deep, positive sum game relationships enables us to jointly seek mutual advantage with our partners through leveraging our diversity.  We therefore have a context for longer term capability development and organisational growth.

Essentially as we and our partners become more dependent on each other to realise value so we also become dependent on each other to realise such value in the most effective way possible.  In this context innovation is no longer something that happens within the bounds of your organisation but rather is most potent at the intersection of your capabilities with those of your partners. 

As John points out such innovation transcends current practices around ‘open innovation’ and moves from point attempts to leverage occasional 3rd party expertise to inform our own innovation towards sustained and systematic examination of innnovation opportunities across our partner ecosystem.  This broader approach requires us to continually leverage the diverse experience, expertise and perspective of our wider ecosystem to look for mutual advantage, a subtle but important difference.  Essentially such innovation recognises the increasingly symbiotic nature of partnership and the huge opportunities to create breakthrough innovation through diversity  Such innovation may come in the form of improvements to individual capabilities as a result of partner feedback, in improvements in the functioning of the overall value web or in insights regarding new joint offering or market opportunities. 

Summary

This is an emerging area that requires us to rethink the way in which we deal with partners, the way in which we locate our people and the tools and technology that we can use to support distributed co-creation and innovation.  It may be that some of the tools are already here – I’ve written about using Web 2.0 techniques to leverage talent, for example – but our understanding of the practices and processes that will enable us to really exploit these opportunities is still limited.  Given the rich seam of benefit to be mined through broader, more collaborative innovation, however we all have a duty to promote and develop these ideas as quickly as possible.

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

The Departing CIO

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

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!

<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).

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

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.

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

Does ERP Suck?

I’ve been wondering a lot lately to what extent service-orientation and capability unbundling will affect ERP vendors.  Whilst idly musing on this subject I came across Shai Agassi’s post on the same subject, following on from an article at Infoworld.  As a result I thought I’d put down some of the questions that I’ve been asking myself about this subject.

• ERP - by definition – codifies commoditised capabilities as a way of supporting the implementation of standard, tightly coupled business functions within many consuming organisations.  Essentially they allow enterprises to standardise the processes that their people use in executing non-differentiating capabilities.  As I’ve discussed previously, the main reason that most organisations choose to execute these non-differentiating capabilities is to minimise the transaction costs of collaboration.  If new technologies and methods enable us to collaborate with other partners and make specialisation more attractive, however, then we’re likely to see commoditised processes consolidated into specialised providers who rely on economies of scale in their execution.  Essentially the mode of delivering commoditised practices moves away from the dissemination of best practice to many organisations in the form of applications to underpin business capabilities and into a few large scale service providers who execute the whole capability (software and services) on your behalf;    
• Another issue that I’ve been thinking about concerns the tight integration of capabilities within ERP packages.  As Richard Veryard points out, ERP has taken a set of uncontrolled processes and tightly coupled them; such command-and-control models of management are increasingly unsustainable in the face of increasing levels of change, however.  Organisations are now looking for increased adaptability, and this will require systematically defined business capabilities that can be ‘pulled’ into dynamic value-chains in place of static processes within a monolithic software system.  Such drivers at best lead to a disaggregation of the ERP system into modular software services that support the execution of such capabilities but at this point you again begin to wonder why – if I have defined and metricised these capabilities (and therefore understand the results that I need) – I would purchase and run IT to support my people in executing these capabilities internally rather than go to a specialised provider to do it all for me?
• The next question that occurs to me is if enterprises no longer buy systems that allow them to implement processes they want to unbundle then who will replace them as buyers of ERP?  I wonder whether the resulting consolidated service providers are likely to want to offer all of the capabilities codified within such systems either?  Consolidated service providers are more likely to specialise on just a subset of the capabilities traditionally offered within big applications in order to a) focus and b) support inclusion within the adaptable value chains that their partners require.  Irrespective of service scope, is it likely that providers will choose to have ’standard’ implementations of practices given that they have chosen to specialise – and potentially differentiate - in one of the capabilities previously provided to enterprises through such standard applications?  Currently enterprises want standard outputs but they also want to do it in a well understood, standard way because they don’t care about being better than others in these commoditised capabilities; if my whole purpose is to deliver these capabilities, however, then I may well be more interested in how I can deliver the standard outputs in a way that differentiates me from the competition;
• Even if providers do purchase disaggregated packages to underpin their provision of commodity services, such packages are still consolidated into far fewer, higher scale providers.  In this instance is the software still viable given the drastically reduced market?  Do service providers in this context not just absorb the software needed to deliver services, offering the results of using software to deliver real value to customers rather than just the tools needed to get results for yourself?

Contrary to all of this, however, Shai contends that ERP systems are more necessary than ever for a number of reasons (I’m paraphrasing):

• Semantic consistency;
• Consistent ’APIs’;
• Compliance; and
• External partnering.

In many ways I think that these issues tend more towards unbundling than they do towards consolidation within the organisation:

• In my view consistency and the ability to build propositions on top of known ‘APIs’ will come from rigorous business architecture that systematically designs and metricises the capabilities needed by the organisation rather than from software packages.  Such organisational practices will need to become common in any case as enterprises seek to understand where value is created and destroyed and to make themselves more adaptable.  Mapping the differences in semantics between the architecture of the organisation and the services of any provider would not then appear to be an insurmountable task;
• In terms of compliance there are many laws and regulations being passed on a regular basis that impact particular capabilities within the business and even particular geographies (e.g. employment laws).  Where commodity processes remain within the organisation the onus is on the people delivering the capabilities to ensure that they are compliant (which software alone won’t deliver).  Where the capability has been outsourced to a specialised provider, however, the onus is on that organisation to remain current.  Additionally – given their focus and expertise – they are far more likely to remain so than non-experts working within a non-core capability internal to an enterprise.  As a result it may be that replacing your ERP supported internal capabilities is a more robust way of remaining compliant to the myriad of regulations within which an organisation operates; and
• In terms of the last point, Shai more specifically contends that “…the coming wave of implementations will be driven by the need for consolidation, networked value chains and increased speed of process change”.  I completely agree with this but feel that consolidation will be delivered from a business perspective (i.e. increasing specialisation) rather than from a software perspective (i.e. more ERP) and that the networked value chains will be complementary partners orchestrated using technologies that enable rapid process change.  I feel that these things are orthogonal to the concept of an integrated ERP, however, with horizontal process based technologies pulling together a network of specialised providers who will have taken over many of the tasks that I would previously have needed an ERP to control.

The one area that I did agree with both Shai and Richard was around the fact that none of this unbundling and specialisation can take place just on the basis of granular web services that have been thrown together; we need to get to a level where we can express the capabilities of an organisation as a set of services that represent access to significant business functionality.  Only service providers who have been through this exercise will be mature and stable enough for us to place our trust in them.  This is not an easy endeavour but I feel that the drivers towards specialisation will compel us to address these issues and that the resulting ability to procure commoditised services from consolidated providers will undermine the value of ERP software.

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

Elements of the Future Business Ecosystem (Part I)

The Wild Outside

It’s no secret that the global business environment has changed radically over the last twenty years due to the effects of globalisation, radically increased competition, pervasive regulation and rapid commoditisation. In addition the increasing information content of products and services is leading to a rapid decline in cycle times as their creation, maintenance and suspension is far more rapid than that of physical goods.  We’re all therefore continually striving to find more innovative propositions with improved service at lower cost - as a result we’ve never needed to be more responsive. Unfortunately, however, most organisations are hampered by organisational, process and technology practices belonging to a less dynamic age, making them unable to adapt within the time and cost parameters increasingly demanded.  These practices make it difficult for us to recognise opportunities in the mass of data with which we’re increasingly being overwhelmed and then frustrate us in any subsequent attempt to adapt, with change being complex, time consuming and hugely expensive.

Whilst these issues have been bubbling away with increasing ferocity under the apparently calm surface of many organisations over the last decade, those people who are continually running ever faster just to keep a lid on things are in increasing trouble – the global environment is set to accelerate further over the next few years.  Technology is increasingly enabling the creation of new business models in support of customers and partners who expect continual service on their own terms – where, when and how they want it – and the speed of change enabled by technology innovation on the Internet represents an almost continuous source of change.

In order to succeed in future, we’re going need to find ways of facing these new realities.  In particular we’re going to have to address the following major issues:

• The need for greater adaptability: The increasing pace of change will force us to adopt strategies that specifically stress adaptability.  Current – mostly dysfunctional – command and control structures that attempt to predict demand and ‘push’ resources will increasingly break down due to the unpredictable nature of the environment.  Organisations will thus need to reinvent themselves as a set of modular business capabilities that provide specific, known and costed services that can be reconfigured on a ‘pull’ basis in response to changing demands; and
• Increasing specialisation: New collaborative technologies and interoperability standards will continue to reduce the transaction costs of collaboration with other organisations.  These changes will enable organisations to replace mediocre internal capabilities with world class services provided by partners, helping us to concentrate on what’s truly important and combat increasing attention scarcity.  We will therefore see increasing specialisation, with organisations who do not outsource non-core concerns finding themselves at an increasing cost and capability disadvantage.

Let’s have a quick look at each of these issues.

The Need For Greater Adaptability

In order to address the need to survive in an increasingly uncertain world organisations need to adopt strategies that specifically stress adaptability – at the end of the day the only way to deal successfully with uncertaintly is to be able to adapt successfully to the changes that occur.  In order to achieve adaptability, however, we must first understand what capabilities are needed to deliver to our stakeholders before considering exactly how all of these component parts combine to deliver value.  Gaining this higher level view of the organisation requires a systematic approach to enterprise design which emphasises the creation and coordination of shared business capabilities in place of hierarchical silos with cross cutting concerns.  Such an approach concentrates on reconceiving the enterprise as a set of collaborating business capabilities which have well understood commitments to the rest of the enterprise and which are firmly placed within the context of the overall value chain.  In particular each capability is expressed only in terms of its commitments – there is no external view of the way in which the capability delivers on these commitments in order to ensure loose organisational coupling.  These changes deliver a set of abstractions that allow senior management to define what the organisation should do without surfacing the mass of how, delivering greater adaptability at both levels.  This brings benefits at a number of levels:

• Organisational leaders are able to concentrate on what they are trying to achieve at the enterprise level by ensuring that they have the correct capabilities and that these capabilities are offering the cost and service levels that the organisation requires.  In addition such leaders are able to concentrate on macro level changes, reconfiguring value chains and renegotiating commitments with the capability owners in response to changes in external demands; 
• Capability owners – including partners – have clear responsibilities and are empowered to innovate within the bounds set by these commitments.  In effect the design of the organisation only constrains the capability owner in terms of required outputs – they are free to produce these outputs in any way they choose as long as they continue to offer competitive services; and
• Organizationally we have much greater adaptability, since change can be understood and managed at multiple levels of abstraction – capability owners can implement changes – for example service improvement or regulatory requirements - without impacting the wider organisation whilst enterprise management have a system of abstractions that allows them to understand the impact of change and to  rework the organisation appropriately.

Although these concepts all sound pretty cool, until recently we’ve lacked a consistent set of abstractions with which to define capabilities, the services they offer and the costs and service levels that they conform to.  In the last few years, however, the concepts of service orientation have emerged. Service orientation allows us to view complex systems – such as an enterprise – as a group of collaborating services that can be coordinated to deliver value, each with its own purpose, contract and service agreement.  These techniques can thus be used – with some extension – to form the basis for the systematic design of the enterprise by helping us to understand and define the business capabilities that are needed whilst deferring their implementation to capability owners. Each business capability can then be delivered using an arbitrary combination of people, physical resources and technology.  This removes the artificial boundaries between different kinds of resources by concentrating on how they combine to deliver service commitments rather than splitting them into – for example – ‘business’ and ‘IT’ and thereby losing the necessary value context.  From an IT perspective this cuts across the traditional view of ‘Enterprise IT’ since capability owners are free to procure any necessary services – potentially including IT – from anyone. 

Increasing Specialisation

Despite the efficiency benefits of specialisation most firms continue to be generalists, executing non-core capabilities in-house rather than rely on other specialists to execute such services on their behalf.  The main reasons for this have been twofold:

• Current organisational structures do not allow for easy outsourcing due to the lack of clarity around discrete business capabilities – it has generally been difficult to untangle consistent threads from the hairball of organisational structure; and
• The transaction costs of collaboration have largely been a barrier to the leverage of external capabilities since such costs have traditionally been sufficiently high as to negate the benefits gained through specialisation.

The former issue will increasingly be resolved through the use of methodologies – such as service orientation – that enable business capability mapping in the search for greater agility.  Transaction costs, however, are a different issue. Traditional economic theory suggests that firms exist to maximise efficiency; in order to do this they organise services internally to themselves in order to minimise the costs of transacting business with third parties. These costs consist of the effort required to find, establish, execute, manage and conclude partnerships for the provision of services.

Until recently these issues have been a sufficient barrier to the emergence of a specialised service provider market, with external transaction costs remaining sufficiently high to prevent large scale outsourcing in all but a few areas of broad applicability (e.g. HR or Payroll).  The increasing capabilities of the Internet are set to change this pattern, however, with key standards facilitating the exchange of information between organisations in a much simpler way.  In particular web service standards – both WS-* and Web 2.0 based - allow documents to be exchanged with partners over the web, forming a basis for a contractual commitment and enabling them to execute some service on our behalf.  When we also add in the more human-collaborative aspects of Web 2.0 and the increasing convergence of communications technology we can see that we have a powerful platform for cross-organisational collaboration. 

By lowering the costs of information exchange and collaboration these developments are opening the door to a change in the nature of the enterprise.  We are headed to a market where organisations will be increasingly virtual - the enterprise will no longer exist to maximise efficiency by minimising transaction costs but to pull together a network of highly efficient, specialised providers in order to deliver an overall proposition.  These changes will be complemented by the modularisation of enterprises, since the definition of a business as a set of services enables us to make clearer decisions about how we realise them.

This process will deliver advantage to organisations in three major ways:

• Enabling tighter focus on the provision of differentiating services: Currently organisational attention spans a myriad of business capabilities, most of which – whilst critical to the overall delivery of value – are not key areas of focus.  Such non-core capabilities represent a diffusion of attention, increasing the information to be absorbed in order  to remain competitive and wasting organisational energy.  As we’re increasingly overwhelmed by information about change – whether competitive, technological or sociological -  attention will become a highly valuable asset and will need to be focused in the correct areas if we are to have any chance of making a sustained impact in our chosen field;
• Boosting wider performance by replacing mediocre internal capabilities with world class services provided by specialised providers: Non-differentiating services will already suffer from a lack of focus and therefore be less effective than those provided by people whose sole concern is to deliver sustained excellence in those capabilities.  As increasing competition and attention scarcity begin to bite we will have even less spare energy within the organisation to devote to these supporting capabilities, leading to rapid degradation.   Those organisations that take the opportunity to leverage 3rd party providers, however, will be exponentially better than those that do not - they will benefit from the ability to focus on their own areas of specialisation whilst simultaneously benefiting from the continual improvement of their specialised partners;  and
• Maximising learning opportunities by working with other specialised providers to improve the overall value chain:  The emergence of extended value chains will see many specialised providers coming together in order to deliver overall propositions to the market.  Where these providers come together there will be abundant opportunities to leverage their different perspectives to generate innovation around the way in which the overall value-chain functions – such innovation will be continuous, sustained and generate improvements at a rate that is inconceivable in today’s static organisations. In addition, the fact that each provider works with many other organisations maximises their opportunities for learning, a stark difference to current internally focused capabilities whose horizons are highly limited.  

Standing back we can see that the move towards specialised service provision further destroys the notion of enterprise IT; as capabilities are unbundled to other providers the only ‘architecture’ that remains critical is adherence to interoperability standards.  Each specialised provider needs to be able to interact with the cloud but can no longer expect to force a unified IT architecture across everyone in the value chain.

Conclusions

In this first post I have considered some of the broad changes that I think are going to have a major impact on enterprises but I’ve really only brushed some of the implications from an IT perspective.  I guess the big take away from this initial post is that organisations – and therefore enterprise IT – are entering a period of fragmentation as unbundling occurs.  In future posts I’ll look at the potential effects of such fragmentation before going on to talk about the resulting future landscape from a business and IT perspective.

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