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.

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

Does the Cloud lead to homogenised enterprises?

Just a quick follow on from my last post about cloud computing/service delivery platforms/platform as a service/saas platforms etc etc as. I was intrigued by a Joe McKendrick post on the merits of the model.  Joe’s analysis was pretty balanced as usual but one of his disadvantages caught my eye as I disagreed with it strongly.  Essentially Joe suggests that there is a perception that “Enterprises leveraging Cloud computing may become homogenized — and lose the competitive advantage that may come from custom-built systems”.  As I’ve previously discussed the concept of cloud computing drives people to finally decide what business they are in; if they work in an end user organisation then they need to recognise that and start treating IT like a utility rather than a differentiator.  In this context, however, I would argue that rather than homogenising the enterprise it will have the opposite effect – if we get rid of our IT platform to the cloud (who cares if it is homogenised – it’s just a technology platform), consume our 80% of non-differentiating business capabilities as SaaS or BPU services from the cloud (who cares if these are homogenised – they don’t differentiate us) and then focus all of our attention on realising the remaining 20% of differentiating capabilities – as custom built systems – more rapidly and cheaply on our chosen cloud computing platform(s) then we will be maximising our advantage whilst losing none of the benefits.  It’s important to realise that just because we don’t own and operate the physical technology it doesn’t mean that we can’t own the services that run on it  – we can still develop our custom-built systems to realise our differentiating capabilities.  And given that this is the only bit of the whole value chain that’s actually important for us to customise I would argue that we are – in reality – less likely to end up homogenised since we are more focused on where our value really lies and therefore more able to maximise our differentiation from our competitors. 

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

Service Delivery Platforms peek from behind the Cloud

Quick note having just read Dion Hincliffe’s article on Google App Engine and Amazon Web Services (their respective cloud computing infrastructures).  These platforms are early and very basic instances of the ’service delivery platforms’ I’ve talked about for the past few years (for an example see a presentation I gave at the MS SOA & BPM conference last year).  As I discussed during this talk, I use the term ’service delivery platform’ in place of ‘platform as a service’ or ‘cloud computing’ since in order to really support viable and fully rounded service delivery you need to provide far more than a ‘platform’ or ‘infrastructure’ – a topic I’m going to return to now that this area has been popularised by Google and I won’t seem like (such) a lunatic, lol.  More broadly, however, I’ve discussed a number of times why I feel that economics and technology commoditisation will drive people down this route eventually and I’m really excited now to see a number of competitors emerging in this space (with Amazon, Google and Salesforce now competing with a number of smaller startups (with more to follow)).  I know I’ve said this before but people are really going to have to start deciding what business they are in – if you work in an end user organisation then you need to recognise that and start treating IT like a utility rather than a differentiator; if you’re an IT service company, however, you’d better work out whether you want to be focused on relationship brokering and consulting, utility computing platform provision or  SaaS/BPU service offers, since the economics of each are very different (you may in fact want to play in all three but if so you’d best disaggregate your company and run them autonomously under your umbrella brand – or you’ll make a complete hash of them all).

One of the interesting things for me is whether a middle-ground model will emerge that enables enterprises to take advantage of the industrialisation and economies of scale available to service delivery platform vendors whilst also enabling the deployment of ‘edge’ infrastructures to customer specific environments.  In this context we may see locally deployed ‘chunks’ of the central service created for those organisations that are large enough or who have specific privacy or trust issues (still coordinated with and managed from the centre, however).  Whether such a model has a long term future is an interesting (but as yet undecided) question to my mind but in the short to medium term those SDP vendors who were able to deliver such a transitional solution would provide a compelling migration path to enterprises who are nervous about the implications of a wholesale shift to the cloud.

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

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.

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

SOA and Market Forces

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

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

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

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

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

SaaS, Appliances and Industrialisation

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

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

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

Getting IT "Just Right"

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

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

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

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

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

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

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

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

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

Building the Internal SOA Marketplace

The Lack of Cost Transparency

One of the drivers for looking towards increased service-orientation is the pursuit of transparency of cost. There are two issues that currently lead to a lack of transparency:

1. Businesses are not designed as systems and thus we have functional or product based silos that make it difficult to understand the cost of providing business capabilities; and
2. Implementation processes and supporting IT systems are delivered as individual applications within these mis-aligned business silos, resulting in even greater opacity.

This situation means that most organisations have no idea how much any given process or capability actually costs them and hence no worthwhile metrics to help them improve.

Service-Orientation for Business Design

As I’ve discussed previously, it is interesting to note that the concept of service-orientation has nothing to do with technology but is rather a structural abstraction.  As a result you can use the ideas of loose coupling, defined contracts and quality of service within business design as well as within IT – in fact service-orientation makes no sense when this business context is absent.  Service-orientation thus delivers a coherent method for the structuring of a business as a system, with services offered by business capabilities forming the system elements that are coordinated in the pursuit of value.

Service-based Costing

If we use these concepts to redesign the enterprise as a set of services realised by a combination of people, technology and processes then the costs of a given business service are the combined costs of these elements as they interact to deliver to the specified contract. This means that costs are now available at the business service level; i.e. for each service that the enterprise wishes to use they have a specific cost associated with it. When a number of business services are linked together, the cost of the aggregating service needs to be pitched by the owner at such a level that they can profitably aggregate the consumed services in order to deliver to their contract. 

Procuring Services

The expression of an enterprise as a number of collaborating business capabilities allows the organisation to consider how it procures the necessary functions; one option is to deliver a single service that supports the necessary function for the whole enterprise, a second might be to outsource the execution of the service to a specialised provider, whilst a third could be the use of multiple internal and external providers that compete for individual service fulfillment requests on the basis of cost and quality of service. In reality there are likely to be a variety of models applicable.

Utility Business

In order to enable the final transparency, however, and deliver utility style costs to the enterprise, each business capability owner will need to be able to charge for the usage of their services on a per transaction basis. For example, human resources will need to be able to charge for recruitment, induction or dismissal services. This will enable consuming capabilities within the enterprise to be billed for the specific services that they consume and thus see where their major costs lie. Such a model will enable capability owners to decide whether internal service providers represent a good deal or whether they should look to leverage the services of external specialised providers.  In addition service providers will have clear metrics for the costs that they charge to the rest of the enterprise, a view on the competitiveness of their services and a clear sphere of control within which to innovate in order to increase cost-effectiveness. Some service providers may even begin to charge a markup to reinvest in the improvement of their services rather than simply charge at cost.  In point of fact I believe that this will increasingly be the case (even within a given enterprise), since such a market approach drives the sustainability (or not) of a service by forcing it to be competitive or driving it out of the organisation and into the hands of an external provider.  For those capability owners who do succeed in making the transition, the opportunity will be there for them to offer their capabilities to external partners and grow their services as an independent business, taking advantage of greater economies of scale and scope.

Governing the Utility Business

As we increasingly conceive of an enterprise as a set of business capabilities so the focus of governance moves away from inappropriate concentration on technology and onto the portfolio of services that the enterprise needs to realise its goals.  In this scenario the implementation of business capabilities is wholly federated to the capability owners who have the right to decide how they implement the services that they offer to the rest of the organisation, resulting in a cascading (and greatly simplified) ‘business architecture’ where organisations only scope and govern services at the level at which they consume them, leaving onward decisions within the remit of their service providers.  This might seem to fly in the face of traditional notions of SOA where people bemoan the fact that most organisations are ‘project-centric’ and that there should be less ’selfishness’ but the fact of the matter is that if we charge people with delivering certain value – and we judge them on their performance -then the natural tendancy of human beings is to exclude anything that is orthogonal to the task at hand.  This means that rather than force people into situations where they come into conflict over differing priorities we need to realign the way in which people are judged – by charging them with the delivery of a service that meets the needs of the organisation as a consumer – whilst giving them total autonomy over how that service is delivered.  This delivers the best of both project and enterprise thinking by more appropriately aligning people’s responsibilities around system boundaries whilst satisfying their need to control their own destiny (this, incidentally, is a subject that was explored more lucidly by Todd Biske here!).  Such a model also helps to remove the tensions traditionally associated with inter-departmental integration – discussed by Joe McKenrick here – by realigning departments around the services that they provide, again moving the focus to system boundaries in place of overlapping hierarchies.

This will be a significant shift away from current, immature models of governance which focus on forcing shared IT services, applications and infrastructure onto business capability owners, thereby locking them into potentially inappropriate solutions and preventing them from changing independently.  In the business capability model we concentrate on discovering and managing those services that have value to the business and rely on market forces to drive capability owners to share (or not) services that can be conceived of and offered by third parties in a way which is monetisable and thus sustainable.  This covers the other points raised by Joe around governance given that the answer to all of the questions about ownership, charging, change, etc. are answered by the fact that there is a commercial (or at least pseudo-commercial) agreement between the consumers and providers of service within the enterprise, again driving a market approach in search of transparency and sustainability.  In either case sustainability is the key concern here, as current notions of reuse based on small granularity services are not sustainable given that they cannot generate sufficient revenue to ensure their own survival whilst they simultaneously place capability owners into lockstep for little value gained.  In this scenario the IT department is essentially levying a tax on the business in order to unfairly prop up a collection of services that result in an inflexible environment for the business capability owners,

Utility Platforms for Utility Business

In order to enable a more sustainable model based on market forces, service realisation platforms will need to demonstrate a number of characteristics:

1. They must be cost-effective:  As capability owners start to surface the costs that they incur in offering their services, so the cost of the supporting IT systems will come to light.  In many organisations IT has been seen as an unpleasant but necessary evil with the costs dispersed across the organisation in such a way as to make it feel like an ungovernable black hole.  If you suddenly find yourself tasked with delivering a set of services competitively, however, and find that your specific share of the IT costs makes you uncompetitive in doing so you are going to be very concerned.  This will force capability owners to take a long hard look at the costs that they incur and look for ways of reducing IT expenditure.  In this scenario it is likely that they will begin to look at shared platforms from utility computing providers in place of expensive, home grown, inflexible infrastructures and architectures that don’t support them in delivering, robust, monetisable services;
2. They must support service provision: As well as requiring increased quality and robustness, providing services to consumers requires that there be a host of supporting functions in place, including management, reporting and monetisation.  As a result any service delivery platform  must include the ability to capture complex service events for service level management, audit and metering and billing.  Without such functions service providers will be unable to scalably serve their consumers and ensure that they are invoiced for the functionality that they use.  Current enterprise IT infrastructures (and most middleware products) do not support any notion of service delivery at this level of maturity and thus the likely platforms for such service enablement will be SOA-aware SaaS platforms – like the kind described frequently by Phil Wainewright (for example see his discussion of OpSource here) – delivered either centrally by specialised utility computing providers or within the enterprise data centre by such providers as a special service.

Summary

Service-orientation represents a new way to describe the way in which an enterprise functions. If pursued successfully a service-oriented business design can open the way for increased transparency of costs, greater competition and new business opportunities. Any vendor who wishes to help companies with this transition will need to ensure that they have adequately catered for the needs of service delivery within their SOA platform, however.  Of particular concern are a coherent monetisation strategy along with underlying charging and invoicing capabilities, as I believe that ensuring the provision of monetisable services is the only sustainable way of creating and maintaining a portfolio of business services that are exposed to market drivers and hence forced to be competitive. In addition such a market-led approach introduces more transparent governance, focusing on business capabilities and forcing capability owners to deliver clear and competitive services against which they are judged, hiding the complexity of implementation – where most people try to address governance today - and governing more appropriately on the outputs required.

I think I’ll return to the areas of both governance and sustainability in the near future as I believe that they are areas of significant weakness in most current SOA proposals and thus worthy of further discussion.

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

Capabilities vs ERP

Just picked up on a post by Clive Keyte (here) that discusses the selling of SAP as a set of services.  The post was in response to one by Jeff Kaplan, where Jeff argues that SAP needs to learn some lessons about service enablement and the fostering of an ecosystem from more agile companies – more specifically Salesforce.com (here).

There were two points that I found interesting in the ensuing discussion – 1) that Jeff believes that the value lies in services that can be leveraged to build better end propositions rather than in monolithic applications with outdated licensing models (my emphasis given my biases ) and 2) (and perhaps more interesting) Clive’s response about TDS building a set of services that ‘enwrap’ SAP.  I was initially quite excited about this as I thought that this scenario might mirror some of my comments a couple of weeks ago (here) where I was considering how the ability to buy services from specialised providers impacts companies like SAP who attempt to sell applications that are a) tightly integrated (and thus do not promote process agility) and b) representative of the commodity processes that people don’t focus on.  I thought that TDS had taken SAP and were selling commodity services (i.e. complete propositions) whilst using SAP as the backend to enable them to deliver.  Turns out, however, that TDS are essentially selling an ASP proposition into the mid-market based on a set of applications that they have created that use SAP as the backend.  Nothing wrong with that but it isn’t the big deal I initially thought.

On idly looking at the SAP website for BPO propositions, however, I did discover a list of providers who use SAP within their offerings rather than sell SAP into end organisations.  This is much more like the shift I had in mind and effectively changes the whole consumption model from many-installation to single-installation.  Essentially SAP disappears behind people who provide commodity services and is no longer needed in the end enterprise.  To me this makes much more sense than attempting to sell applications into end organisations (whether on a SaaS or on-premise basis) since as I’ve argued before such applications represent commoditised capability that I may as well buy from someone else if it’s not an area of concern for me.  Currently these services are mostly based around the usual BPO suspects like Human Resources – which have a broad horizontal appeal – but I believe that we’re rapidly going to see a shift towards the outsourcing of much more specialised (and potentially differentiating) capabilities, with complex value chains spanning multiple providers.

If this model proliferates – as I believe it will – then how long will it be before specialised providers decide that they too need more flexibility in how they deliver?  Which other modules – beyond HR – are good candidates as a starting point for the creation of specialised services?  Are ERP packages – given the breadth of their function and the difficulty of breaking them up – too expensive and inflexible to play within a specialised service provider market?  How will a shift towards service provision affect the revenue streams of ERP providers given a consolidation of the supporting applications into fewer end organisations?  All interesting stuff I guess – any ideas would be gratefully received

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