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.

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

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. 

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

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.

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

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.

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

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

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

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

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

I’ll explore this a little further.

The importance of internal stability

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

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

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

The importance of external stability

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

The futility of transactional behaviour

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

The increasing importance of deepening relationships

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

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

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

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

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

Leveraging stability and deep relationships to realise institutional innovation

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

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

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

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

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

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

Summary

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

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

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

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

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

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

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

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

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

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

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

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

Happy New Year, btw.

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

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.

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

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.

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