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.

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

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.

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

SOA vs Efficient & Agile vs Differentiation

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

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

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

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

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

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

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

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

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

Relationships vs Transactions

Background

Got a comment from one of my colleagues – a chap called Martin Abbot – by email a couple of days ago with respect to my last post about institutional innovation.  Whilst I’ve been planning to find some time to write a follow up that links these ideas through to SOA and SaaS I thought it might be worth just posting the question and my email response.  It’s not a ‘proper’ blog post – and so is a bit messy – but the questions and my rushed answer are probably worth sharing.

The Question

“Is the idea of moving away from transactional relationships to ones that are mutually beneficial not a little at odds with SaaS and SOA generally? Both of these seem to support the commoditization of resources and are therefore inherently transactional in nature.”

The Answer

Well I guess that there are a few things:

Lots of stuff tends towards commoditisation and so in many ways the argument Martin makes is understandable.  Even based purely on the use of ‘commodity’ services, however, I guess you could make the following arguments:

• Commodity doesn’t necessarily mean wholly standardised.  In the future we’re going to need to support mass customisation of services to support our customers businesses.  In a SaaS/SOA environment this basically requires us to have many customisation points built into the software that support both multi-tenancy and customisation.  The key here is to build the software for customisation in a few key dimensions from the ground up rather than rely on your ability to bastardise it later.  To be able to understand the 20% key dimensions that need to be customisable, however, you need a pretty deep understanding of your consumers (I realise that this point is only tenuously related but I need to establish it first…)
• The second point is that even if you are only delivering commodity services there is always the opportunity to a) understand your customers needs better and b) deliver services that are more appropriate to them through your improved contextual understanding.  This requires collaborating partners to share information much more freely in order to get the best service.  When you combine this with the ability to mass-customise services you can see that both the provider and consumer get best advantage when they each fully understand the capabilities and aspirations of the other.  This depth of relationship requires a degree of trust that goes above and beyond a traditional zero-sum approach, however.
• From a provider perspective you also need to work closely with your partners to understand the effectiveness (or not of your services) in order to be able to shorten your feedback loop and accelerate the improvement of your capabilities.  Again this is a win-win scenario potentially as both parties get greater value.

All of this is fine from the perspective of thinking of two parties as ‘customer’ and ‘provider’ when the main goal is the consumption of services on a transactional basis.  i.e. there are still some low level advantages to both parties of creating a closer relationship.

Beyond this however is the real value.  If you build trust across organisations that offer some part of the value chain then the more important question becomes how you can leverage your capabilities together in order to improve existing offerings or – perhaps more importantly – create new services or offerings to existing or new markets.  The key here is that each service provider may have a fairly conventional view of what services they offer and who they serve but when each comes together to look at how they collaborate to deliver  value and how each others services could be used to approach their customers then a new perspective opens up.  Once this perspective is opened they can then begin to consider how each would need to optimise their services in order to create these new markets and this in turn can help them to consider how these ideas impact (and potentially improve) their ‘traditional’ offerings.  When you broaden this from two parties into everyone who performs any value adding activity within and across value webs you can see that the opportunities for collaboration and new value creation rise exponentially.

This is also applicable when you think of ‘customers’ in the traditional sense rather than groups of suppliers working together;  customers and their providers exist in a value-web and therefore by forging strong relationships and inviting suppliers to help improve the end product the overall value for everyone is greatly enhanced.  This is also a two-way dialogue since providers can use Web 2.0 techniques to bring their consumers into the service creation process and thereby become co-creators of the products and services that the company offers – an ideal way to balance push and pull models.

Even if we think about products and services that tend towards commoditisation – and many things do – we can see that the reality is that such commoditisation is inevitable and accelerating; sharing information with trusted partners – whilst it may hasten the commoditisation of certain services – more than offsets this by opening up far grander opportunities to utilise these services in new ways.  Furthermore if your services are subject to commoditisation then they are also subject to economies of scale and leveraging partners to find new ways of using these commoditised services to build new markets is a much smarter move than withdrawing into yourself and becoming obsessed with efficiency and cost reduction. 

To paraphrase Bill Joy, there are far more smart people outside your organisation than in it and maximising your ability to innovate by mutually leveraging this smartness is increasingly going to be a necessary capability.  As I stated in my original post, I agree that there are many things to be worked out in order to move people into this new way of working but I believe that those who make the transition will create and reap significantly greater value than those who do not.

Conclusion

My anticipated next post was to actually look at how service delivery platforms and SOA could help to accelerate the types of relationships that I discussed.  I’m still aiming to write that post but decided that there was value in exposing this information in the interim as a) it is related and adds to the discussion and b) given my excessive commitments at the moment it was easier than actually finding the time to write the post I need to at this point in time

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

You work for the man

Interesting quotes from Gartner on the ZDNet website today that I felt like cheering to the rafters – in short people like me (and maybe you) are in business not IT.

“To remain relevant, IT managers need to wake up and admit they work in business, not IT, Gartner’s leading analysts said in the keynote address at the Gartner Symposium in Sydney.

“None of you are in IT; all of you are in business,” said Andy Kyte, vice president and Gartner fellow.

IT has become invisible to end users and should rather be called “OT” or “operational technology”, according to Kyte. At the same time, the way businesses procure technology is changing, for example software as a service is allowing technology to seep into the business beyond the IT department’s control.

“So where does that leave IT professionals?” Kyte asked. “We need to ask what we do, what to achieve, what is expected of us, and how we are perceived by our peers in business,” he said.

IT managers who fail to ask these questions risk becoming irrelevant to the business. In fact, the vertical market an IT manager works in — government, pharmaceuticals, manufacturing, retail — is more important than the person’s department, said Kyte.”

Tragically it reminded me of a meeting I attended a few years ago when I worked at a financial services company.  Essentially a senior manager who was briefing the IT department said “put up your hand if you work in financial services”.  I – and a few others tentatively did.  “Now put up your hand if you work in the IT industry”.  Everyone else raised their hand.  “That’s a big problem”, said the man who paid them ruefully.

And this gets to the nub of one of the issues in the increasing commodisation of technology and IT – essentially you have a whole army of people whose loyalty is to the technology and not to the business.  Things are going to have to change soon, however; as I wrote here the stratification of business types around economic forces will drive us all to admit – finally – that we either do work in IT – and so need to be in an IT company – or we work in financial services – and so IT is just a utility that we are forced to use to achieve our goals.  We increasingly can’t be both, as funding our play habit will become too rich for the majority of organisations being exposed to the increasing chill of global competition. 

So get your ass to the business side of the fence and look for value before it’s too late and try your hardest to get shot of operational management and execution to give you the attention space to prove to your colleagues that you’re really on their side.

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

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.

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

It’s about umm… Services, duh!

<Rant>

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

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

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

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

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

</Rant>

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

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

Killer, Gorilla, Guerilla SOA

The Proposition

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

Guerilla Campaigns Need Direction

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

Executing Your Campaign

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

Enable Guerillas to Improvise in Realising Goals

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

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

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

P.S.

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

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

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.

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

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.

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