Migrating from edge to backbone

What should we move between ‘edge’ and ‘backbone’ in our enterprise-architecture? How do we do so? And what governance do we need for this?

The core theme behind this here is the notion that ‘agility needs a backbone’ – that we need a solid support for organisational agility, yet must not take the balance too far such that everything becomes too rigid. The resultant contrast between ‘backbone’ and ‘edge’, and the ‘governance of governance’ that we need in order to manage it, is something I’ve explored quite often on this blog, such as in the posts ‘Architecting the enterprise backbone‘, ‘Backbone and business-rules‘ and ‘Same and different‘.

The context in this case is that a couple of days ago I posted to Slideshare the slidedeck for my IASA UK Summit presentation ‘Backbone and edge – architecting the balance between continuity and change‘. This elicited a tweet from Nick Gall, who asked:

Would love more re slide 72-How do u manage migration into/out of the backbone? Key to evolution & my life’s work!

The respective “slide-72” was the end-point of a section called ‘Architecting for change’, which was, I’ll admit, a bit too short (courtesy of time-constraints and suchlike). The section consisted of just two slides: this graphic, with the caption ‘Everything changes…’:

…and then this ‘call to action’:

Practice-questions
How does each service change over time, and why?
How do you manage migration into and out of the backbone?
Identify governance needed to manage this, and governance of governance itself.

The theme is that ‘backbone’services provide stability, whilst ‘edge’-services allow the maximum possible freedom for action. They form the end-points of a spectrum of governance and predictability, with various intermediate ‘domain’-specific services kind of scattered around somewhere between the two extremes. The challenge, as another slide put it, revolves around interdependency and reliability:

Choices:
everything we place in the backbone is a constraint on agility;
anything we omit from the backbone may not be dependable.
It’s not an easy trade-off…

Yet the point there was not just about the ‘backbone and edge’ contrast, but how items or services change, over time, and therefore might need to migrate across the spectrum from ‘edge’ to ‘domain’ to ‘backbone’; and, over time, former ‘backbone’-services become less important or less relevant, and kind of migrate the other way, or into a quiet oblivion.

(Note that this isn’t solely about data, but about anything that might be considered as a key shared-service for the enterprise. Hence the backbone also includes core processes, core capabilities, core facilities, core decisions and regulations, even core ideas and aims: for example, as another slide put it, “Vision and values are always part of the backbone: values as ‘shared-services’.”)

This process of migration-over-time means that we’ll need clarity as to what services we move, why we move them, how we move them, and what governance we’ll need for each of those decisions and actions.

Reality is that there isn’t a simple answer to any of this. Sorry…

But what we can do is at least get clear on the questions that apply here, and some of the factors that impact on the answers for those questions. For example:

• interdependency: who depends on this? in what way do they depend on this?
• reliability: who relies on this – the quality or accuracy of this?
• stability: how much or how fast does this change over time?
• centrality: how much does this relate to the core mission and aims of the enterprise?

As each service changes – or service-content type changes – we’ll need to review the resultant changes to its implicit position on that spectrum between backbone and edge. As a simple guideline: the more dependency there is on this (more stakeholders there are for this), and/or the more reliable or quality-assured it needs to be, and/or the more stable it is, and/or the more central it is, the more likely it’ll need to be in the core-backbone.

Which, in turn, means changes to governance – whether people like it or not.

It’s perhaps ironic that one of the measures of ‘success’ out in the agile space is that it becomes kind-of less agile – yet that is how things need to work. If we don’t become more disciplined and more formal in the way we manage things as they move towards the core, it becomes steadily more likely that things that really matter to the business will break – which is not a good idea. Part of the transition from edge to backbone is that we need to shift from ‘safe-fail’, or ‘graceful failure’, to something much more like ‘fail-safe’ – because people now depend on it to not fail.

To give a concrete example, consider geographic-information services. Perhaps a decade ago, these were still very much in their infancy – especially in the mobile space. Back then, GIS was pretty much the preserve of specialist concerns such as oil-exploration or emergency-services. In the general market or the consumer-space, almost the only evidence of GIS was in purpose-built hardware such as the then-new sat-nav systems and suchlike – and the GIS information itself wasn’t accessible or reusable in other forms such as mash-ups and the like. The notion of SoLoMo – social, local, mobile – was barely in its infancy, very much experimental, very much ‘out on the edge’. Yet over the years, GIS data has steadily moved from its initial ‘edgy’ status, to important but still somewhat experimental for specific domains or interest-groups within the enterprise, to a vital component of the way a very wide range of organisations do their business: it’s migrated from edge to domain to backbone.

And in migrating from edge to backbone – becoming more central – it also needs to be more reliable, more quality-assured, more stable (in terms of structure, if not of content), and with much stronger and more explicit stakeholder-relations. If we don’t do this, we’re likely to find ourselves facing some very angry stakeholders – some of whom we may not even have known beforehand were stakeholders…

So again, apologies, but there really isn’t any clear, simple, one-size-fits-all answer to this: the exact definitions and identifiers for what works and what doesn’t, and what types of services need to be where and under what governance, really do depend on the specific industry, the specific enterprise, the specific context. But I hope the above gives a bit more detail to play with, perhaps?