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.

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

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.

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

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.

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

Elements of the Future Business Ecosystem (Part II)

Introduction

In part one I started to discuss some of the changes occurring in the business environment that will have an impact on IT organisations and service providers.  In particular I considered the need for greater modularity in business architecture - to support greater adaptability - and our trajectory towards the emergence of increasingly specialised service providers driven by the Internet and rapidly consolidating standards.  In this post I’ll look at how these trends will drive a change in the value proposition for technology.

The Shift From Products to Services 

If we consider the implications of the changes that I discussed in part one we can see two major, parallel shifts:

• Increased understanding within enterprises of the modular business capabilities needed to deliver value to stakeholders along with clear metrics about their performance; and
• The emergence of specialised service providers who can be used to provide those capabilities that we do not wish to focus on.

As increasingly powerful abstractions allow us to modularise our capabilities, we can consider our operations from a service viewpoint without worrying about implementation.  This will give organisations greater clarity in terms of what they do and help them to raise their horizon from the complexities of non-metricised implementation issues - whether organisational or technological - within which they find themselves mired today.  As a result of this shift companies will increasingly want to talk about the business services that they need rather than procure base technology or products - they will no longer want to buy the products that they would need to deliver non-core value themselves (as they do today) but would rather place expectations on partners for the delivery of the desired results with no concern for the way in which the value was delivered (Figure 1 - Commoditisation of Technology). 

  

 

Such capabilities may be small and wholly automated  - such as access to valuable data or specialised algorithms and calculations - or as complex as whole BPO propositions.  They are going to be services rather than applications, however, since they are firstly going to represent the delivery of discrete value to the consuming organisation rather than just the tools that they would need to use to generate value for themselves and secondly they will need to be supportive of composition into more complex value chains.

The Easy 80%

One of the interesting implications of such a shift is that such specialised partners may end up delivering the 80% of non-core capabilities that an enterprise requires, leaving them to implement and execute the remaining 20%.  Such a shift would represent a large flight away from the purchase of the technology and products needed to support the implementation of this 80% towards the procurement of the actual capabilities themselves. 

As a result I believe that these changes will ultimately move the focus of a large chunk of enterprise procurement away from technologies and products and onto service provision from partners.  Such a move would reflect the changing nature of organisations, since - as discussed in the previous post - their role would be to source and orchestrate specialised capabilities rather than minimise transaction costs by running them internally.

The Other 20%

Whilst organisations will increasingly look to leverage partners for 80% of their needs in place of buying products - along with implementation and maintenance services - there still remains the 20% of services that represent their core differentiation (given that this is primarily an IT skewed blog I’m going to concentrate on that aspect).  The question is how these organisations will choose to implement the systems that underpin the services that they offer to other people - both their own discrete capabilities and those that pull together value chains across internal and external capabilities - especially as they will now have a taste for buying ‘outputs’.  I feel that there are three major points to consider:

• The increased understanding of the business capabilities required by the organisation to deliver value means that the enterprise can state what services they need to be realised.  Rather than source products and technology to realise them, however, organisations are going to increasingly look to external IT service providers to deliver these realisations more quickly, more cheaply and more reliably through leveraging architectures, patterns and infrastructures across customers in order to deliver the economies of scale that are beyond the reach of the common enterprise IT department - essentially they are going to procure the desired outputs (i.e. services) delivered with service level guarantees rather than the vague potential of implementation using some inert product(s).  I strongly believe, therefore, that IT service organisations need to invest in Industrialisation - bullet proof platforms (preferably shared SaaS style platforms) with strong service realisation factories that facilitate the rapid construction or composition of services with outstanding quality of service attributes targeted specifically at the chosen platform.  Essentially as providers are judged on outputs so the characteristics of delivered services come to dominate the procurement process in place of the technologies used in their implementation - i.e. cost, timeliness, payment models, reliability, reporting etc.;
• The need for lower costs and greater repeatability/reliability will drive the consolidation of platform providers to a small number of commoditised technologies wrapped into service platforms that support the realisation needs of many organisations - essentially IT platforms will become commoditised utilities in the same way that electricity generation was unbundled from individual companies and focused in large, infrastructural providers.  Such a shift leaves IT service providers with greater repeatability through industrialised and consistent target platforms around which they can innovate in terms of service realisation and composition factories whilst simultaneously giving end-user enterprises the benefits of choice in service provision (because of interoperability), reliability,  and economies of scale.  Essentially such platforms enable end organisations to be specialised in terms of the services that they offer whilst eliminating the need to expend the time, attention or money needed to design service and technology architectures or run a scalable, always-on platform with strong billing, service management, reporting etc. as a way of delivering and monetising the services that they execute.  This consolidation also becomes critical given that such platforms will provide discoverability for service providers as well as visibility and tracking of capability performance; and
• Enterprise IT breaks down in the face of this disaggregation of the technical environment; essentially each capability owner is free to choose an IT service provider who best meets their needs in terms of service characteristics, from basic service platforms all the way up to Internet scale platforms.  No longer does a drive by IT to limit technology costs force homogeneity across business units irrespective of fit; rather each external IT service provider competes on their ability to deliver services for the capability owner at the cost and service levels appropriate to the requirements and absorbs a large part of the costs of doing so by sharing resources and solutions across customers.  This is much easier where external providers concentrate on providing infrastructural capabilities in this way - the issue for internal IT departments is that they can only afford to support one set of technical capabilities whilst remaining cost effective; where external providers have to compete for service realisation business, however, a marketplace of people providing different levels of service and cost will naturally grow out to cater for the needs of many different kinds of service providers, thereby supporting the different needs of different capability owners within the organisation.

To be clear here I don’t believe that SaaS alone is the answer, rather that there need to be commoditised platforms with similar characteristics (e.g. multi-tenancy, billing, scalability etc.) that support the controlled delivery, hosting and execution of differentiated services and compositions for individual capabilities within enterprises.  The big problem with SaaS from my perspective is that it - by definition - provides economies of scale in the provision of software that supports the enactment of some part of a business capability (or capabilities).  As companies increasingly specialise, however, there is a major issue with this; SaaS by definition provides commoditised software support for standard business capabilities - if the capability itself is so standardised as to support commoditised software then why would I be interested in enacting that capability?  Surely such business capabilities would be provided as a service to me?  As an example if I decide that customer relationship management is not a core capability (e.g. I want to concentrate on product development) would I be more likely to outsource the software that would be needed by a capability to manage customers (but still execute the capability in the same way as every one else by using such software and thereby distract myself from my core mission for little or no differentiation) or would I just partner with a specialised provider who can offer economies of scale and scope in the provision of customer management on my behalf?  At the end of the day if the business processes that support a particular capability can be codified to the extent that they can be sold to multiple businesses then surely those processes are ripe for consolidation into a specialised service provider who concentrates on such infrastructural capabilities.  This is one of the major shifts that is emerging in the provision of repeatable, infrastructural capabilities - where we previously had to replicate commoditised capabilities within each organisation in order to minimise transaction costs we will increasingly be able to centralise these capabilities within specialised providers who deliver better service and lower cost through economies of scale and/or scope.  This is in opposition to the current model where repeatable capability is codified within application software that supports the execution of such commoditised processes many times within end organisations.

The upshot of all of these issues is that IT service providers - whether internal or external - need to increasingly understand the capabilities that an organisation needs to deliver and to use this information to be able to engage on a results basis.  They need to be able to compete on their ability to implement, deliver, compose and manage the required services using commoditised platforms rather than on selling the benefits or otherwise of individual technologies; in short they must sell meaningful business value.  It is up to the IT service provider to ensure that they have standards-based technology that enables them to realise and orchestrate services with competitive characteristics and guarantees, rather than placing the onus on the consuming organisation to understand, select, implement and manage technology - something that is unlikely to be core to their business.  Service orientation supports this push by delivering a set of abstractions that allow us to discuss the capabilities to be delivered along with the service levels and costs that they need to support, giving us the framework against which to compete on required outputs instead of implementation technologies.

The Changing Landscape

As a result of these changes I believe that enterprises will increasingly be uninterested in the technical details of implementation, since greater clarity on how value is delivered will enable them to procure or deliver the services that they need to underpin their mission rather than the base technology needed to implement such services themselves.  Procured services will thus be delivered using any processes and technology platforms that the IT service provider sees fit to use, since competition will move from how services deliver value to what value they actually deliver.  In this environment I believe that competition will move from technology and technology features to the quality and cost attributes that implemented services support (Figure 2 - Competition on Service Attributes).

 

 

These cross cutting concerns or quality attributes (such as modifiability, performance, security, etc) will determine whether the service provider can deliver competitive SLAs to meet customers’ demands.  One of the implications of this shift is the fact that service providers will need to deliver services on a strong base, with a standardised and well understood set of technologies, patterns and service management practices that are well factored and well integrated, since this is what will allow them to deliver consistent and superior service characteristics.  A related example may be that of automotive design, where people buy a car for its ability to get them from A to B but choose the actual implementation (i.e. vehicle) based on its characteristics (e.g. speed, handling, economy).  Such characteristics are largely determined by the quality of the technology with which it is constructed, however, (e.g. engine, gearbox etc) along with the design which brings them all together. In this context very few people buy a car because of a particular technical component or insist that one part of an engine is replaced with another; essentially people buy the experience provided by the car and not the individual pieces which comprise it.  As a result, I believe that technology in this new model becomes an enabler for differentiation in service provision rather than the main focus of procurement.

Conclusions

In this post I have considered how the shift to service provision impacts the way in which organisations will procure capability in future.  In particular we have considered two main aspects:

• As we move towards a market of specialised service providers and unbundling so organisations will be able to procure the 80% of non-differentiating services that they need rather than the technology and people they would need to use to realise such services for themselves.  I’ve already discussed the benefits of unbundling in a previous post; and
• For those 20% of services that remain within the organisation we will need a way to realise the supporting IT.  In this context we will see increasing consolidation of utility computing (nee SaaS) infrastructures externally to the enterprise and a shift from selling products and technology into organisations towards competition on realising the services most efficiently and cost effectively on such industrialised, utility platforms.

These issues have two different implications for IT departments and for IT service providers.

• CIOs and their staff need to help their business colleagues to understand the benefits of unbundling and prepare the ground for the leverage of external service providers.  At the same time - for core capabilities - they need to keep an eye on the emergence of utility computing platforms and take every possible opportunity to offload the delivery, support and management of services onto specialised IT service providers who can deliver new and changed services more quickly, reliably and repeatably and with much greater economies of scale.  Such a change will leave IT staff to execute the much more appropriate job of understanding shifts in technology and helping business colleagues take advantage of such shifts by reworking business models appropriately.  Although I won’t get into this until the next post I believe that CIOs and their staff will increasingly become ‘consultative’, understanding the enterprise, the services available in the marketplace and how to bring both together for the benefit of the organisation within which they work; and
• IT service providers need to recognise that the shift to service-orientation will change the nature of procurement.  As organisations increasingly understand the capabilities they need IT service providers will need to position themselves as more competitive realisers of these services rather than just push technology at the consuming organisation - such behaviour will merely demonstrate an inability to understand the needs of the organisation by surfacing complexity rather than making the procurement of the desired value as painless as possible.  Proactive providers will begin to deliver the Industrialised platforms and methods needed to compete in such a market and begin to work with both business and IT people within end organisations in order to educate them and enable them to focus more completely on their core mission. 

In my next post on this subject I’ll talk more about the types of companies that I see emerging from these shifts and the shape of the ‘future business ecosystem’.

 

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

SOA as Internal SaaS

There have been a few articles bouncing about recently on the subject of whether SOA represents an enterprise internal view of SaaS.  I picked up the thread initially on Joe McKendrick’s blog and followed it for a while across other sites.  The central question was ”Is SOA Software as a Service, delivered internally?“.  To be honest before reading through this article I was in a similar camp to Harry Pierson, whose reply suggested that SaaS and SOA are different things with the only common element being use of the word service.  My only disagreement with Harry’s assertions initially came from the fact that he concentrated on describing service-orientation as a software concept whereas I believe that there are powerful applications for the concepts of service-orientation in business architecture as well.  (And if you’re in Europe, Harry, we also have the ITIL/ISO 15000 definitions of service to further confuse the issue!).

Now overall I admit to having been slightly dismissive of SaaS on occasions as I feel that we’re heading towards a market where we will increasingly be able to subscribe to BaaS (sorry - Business as a Service :-)) propositions.  I believe that in the future organisations will be able to leverage specialised external capabilities in order to construct an overall  value chain rather than just buy software that enables them to continue executing non-differentiating capabilities themselves (for more information see previous post here).  I’ve never been in any doubt that SaaS would be a constituent element of such services but I’ve doubted the value of software delivered in isolation - I’ve seen such things very much as a stepping stone to much more complete business services delivered by increasingly specialised providers (some good examples of the kinds of capabilities that I see emerging are discussed here and here).

So, in this context I read through Joe’s article and immediately thought “No, SOA is not SaaS”.  I could see that some software propositions could be offered as services but to me the wider shift that’s occurring sees organisations looking to purchase results rather than the tools they would need to struggle to gain results for themselves.  In this context, therefore, the idea of different parts of an organisation becoming internal SaaS providers was kind of anathema to me as that was too application centric and placed too much of the business onus on the consuming organisation. 

The idea continued to bug me for a few weeks, though, and I eventually came to some accommodation with the concept based on a number of perspectives:

• As an elevator pitch the whole idea has some merit as many people now get SaaS - ”I’m buying something that I can get more quickly and more cheaply and which makes my life easier” - whereas SOA is still a pretty ephemeral concept for most.  SaaS pushes the right buttons in terms of reuse, economies of scale, standardisation and cost transparency that I feel are absolute imperatives for the organisation of the future and gives us a frame of reference to start moving the conversation up the value chain to business services;
• Interestingly, as an organisation modularises - and then begins to unbundle -each business capability will offer a number of services back into the enterprise.  Such services will no doubt have several interaction models to support their service provision, from simple document based interfaces through to service portals that would look pretty much like SaaS from the outside but which represent access to a complete service rather than just the software needed to support the delivery of one - think Amazon for example.  As a result if we can get people used to the idea that they offer interfaces for other parts of the organisation to use by leveraging the current buzz around SaaS then that’s probably a good thing;
• Finally there’s the whole conversation about how such services get realised - I mean there has to be software and infrastructure somewhere in the equation.  Interestingly I feel that as organisations increasingly grasp the concepts of service provision - driven by SOA, ITIL and SaaS - they will need to grapple with the idea that as a service provider they will need to deliver services quickly, cheaply and reliably with inclusive service management, reporting, billing etc. in order to be competitive.  As a result organisations will unlikely be able to sustain expensive, bespoke  and plodding enterprise infrastructures and will start to look at external utility computing platforms to take advantage of the economies of scale and repeatability that such platforms provide.  At the end of the day a traditional IT department can only provide computing resources to a business capability for a certain level of amortised cost - since the resources are hardly shared at all - and they don’t have the capability to support comprehensive service support infrastructures.  In addition, once an enterprise starts to consist of smaller, more specialised providers with complete control over their execution the previously high but shared costs of IT will become more apparent to capability owners and make them realise that either a) their IT support costs are unsustainable given their likely level of revenue or b) they have been subsidising the rest of the organisation and can actually gain access to IT at a far lower cost via utility platforms and providers.  When this realisation is coupled with the ability for capability owners to choose alternatives I believe that this will result in a flight to utility platforms for the delivery of the software services needed to underpin the capability.  Differentiation for such utility computing platforms will be based on cost, reliability, support for rapid delivery and customisation of services and comprehensive support for ’service enablement’ i.e. reporting, auditing, billing etc.  As a result a third perspective on the question of SOA as SaaS is to turn the issue on its head and say that although internal SOA is not SaaS we will increasingly need to offer businesses the ability to deliver their enabling SOA on a utility SaaS platform based on commoditised and cheap technology - the whole thrust of the industrialisation initiative that I’m working on.  As a result there is a value proposition into business capabilities based on migrating away from  their existing IT and delivering their services on a 3rd party utility infrastructure - much like the move away from company specific electricity generators in the last century and into the hands of infrastructure providers (I don’t really want to get into the ‘IT doesn’t matter’ argument here but I will say that such enabling platforms fall into that camp, taking care of commodity technology so that service providers can concentrate on how technology is used to support innovative business models instead). Interestingly interoperability also means that each business capability - even those contained within a single ‘enterprise’ - could potentially leverage different utility providers if each offers a proposition most suited to the needs of each capability (and thus the idea that we can - or would want to - enforce a ‘common’ enterprise technical architecture becomes defunct beyond the level of interoperability standards).

So - returning to the original question - is SOA SaaS delivered internally? The answer is no.  Does a story built around SaaS concepts give us some leverage to sell the concepts of SOA?  I would say yes.

So where does that leave us?  Well as a CIO I would be looking for opportunities to lead the shift to utility computing by using the SaaS analogy and helping my business colleagues to understand the advantages of a shift to more modular organisational styles.  If we apply SOA at the business capability level then it provides the first sustainable approach to reuse that we’ve seen - if businesses can understand reuse at the level of services that they actually need - rather than have low level object designs waved in their faces as examples - then they will much more quickly understand the benefits on offer.  If we couple this with monetisation at this service level and use understandable concepts like SaaS to sell the idea then we have the potential to lead our colleagues into a more sustainable model rather than just be reactive to ever louder demands for less cost or more adaptability.  Most importantly, however, such changes open the door for the significant shift - increasing and aggressive partnering to drive innovation in business models.  All of these issues represent the new and changing role of the CIO - no longer just someone to manage the IT resources of an organisation but rather the leader who interprets the opportunities that technology presents to change business models and gain competitive advantage for the organisation. 

From an IT provider perspective the challenge is both to evangelise the opportunities created by the current seismic shifts brought on by technology change whilst building out the utility computing - nee SaaS - infrastructures that will deliver increased repeatability in service development and delivery.  Such platforms will need to be much more than just computing power - they will need to be complete, industrialised solutions to the delivery of computing services.  They will require strong service discovery and development factories, bullet proof, virtualised and maximally shared hardware, comprehensive service enablement and provisioning capabilities and finally they will need to be highly automated and support self provisioning of services, billing strategies and rates, service level monitoring and access rights.  In short they will need to encapsulate all of the commodity elements of the technology - both runtime and design/development time - and make it simple for service providers to create and deliver the services they need using a production line approach.

To summarise I guess that SOA isn’t SaaS delivered internally but SaaS might increasingly be the way in which organisations - whether ISVs or enterprise customers - deliver their SOAs, helping them to concentrate on their differentiation whilst delivering to an industrialised, utility computing infrastructure using strong service development factories.

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