JP Morgenthal published an interesting post on his blog recently relating to the futility of trying to map out every facet of an enterprise architecture. I wholeheartedly agree with his sentiments and have spoken on this issue in the past – albeit in a slightly different context (and also in discussing evolution and IT, actually). I also feel strongly that EA practitioners should be focused far more on enabling a deeper understanding of the purpose and capabilities of the enterprises they work in – to facilitate greater clarity of reasoning about strategic options and appropriate action – rather than taking on an often obstructive and disconnected IT strategy and governance role (something that was covered nicely by Neil Ward-Dutton last week). For all of these reasons I totally agreed with JP’s assertion that we should only pursue absolute detail in those areas that we are currently focused on. This is certainly the route we took in my previous role in putting together an integration architecture for two financial services companies.
The one area where I think we can add to JP’s thoughtful consideration of the issues is that of developing useful abstractions of the business architecture as pivotal reasoning assets. In pursuing the work I allude to we developed a business capability map of the enterprise that allowed us to divide it up into a portfolio of ‘business components’. These capabilities allowed us to reason at a higher level and make an initial loose allocation of the underlying implementation assets and people to each (and given that both I and EA were new to the organisation when we started I even had to ‘crowdsource’ a view of the assets and their allocation to capabilities from across the organisation to kick start the process). In this sense there was no need at the outset to understand the details of how everything linked together (either across the organisation or within individual capabilities) but rather just the purpose and broad outcomes of each capability. This is an important consideration as it allowed us to focus clearly on understanding which capabilities needed to be addressed to respond to particular issues and also to reason about and action these changes at a more abstract level (i.e. without becoming distracted by – and lost in – the details of the required implementation). In this sense we could concentrate not on understanding the detail of every ‘horizontal’ area as a discrete thing – so everything about every process, infrastructure, data or reward systems along with the connections across them all – but rather on building a single critical horizontal asset (i.e. the business capability view) that allowed us to reason about outcomes at an enterprise level whilst only loosely aligning implementation information to these capabilities until such a time as we wanted to make some changes. At that stage specific programmes could work with the EA team to look much more specifically at actual relationships along with the implementation resources, roles and assets required to deliver the outcomes. Furthermore the loosely bounded nature of the capabilities meant that we could gradually increase the degree of federation from a design and implementation perspective without losing overall context.
Overall this approach meant that we did not try to maintain a constant and consistent view of the entire enterprise within and across the traditional horizontal views – along with the way in which they all linked together from top to bottom – but only a loose view of the overall portfolio of each with specific contextualisation provided by an organising asset (i.e. the capability model). In this context we needed to confirm the detailed as-is and to-be state of each capability whenever we wanted to action changes to its outcomes – as we expended little effort to create and maintain detailed central views – but this could be largely undertaken by the staff embedded within the capability with support and loose oversight from the central EA team. In reality we kept an approximate portfolio view of the assets in the organisation (so for example processes, number of people, roles, applications, infrastructures and data) as horizontal assets along with the fact that there was some kind of relationship but these were only sufficient to allow reasoning about individual capabilities, broad systemic issues or the scale of impact of potential changes and were not particularly detailed (I even insisted on keeping them in spreadsheets and Sharepoint – eek – to limit sophistication rather than get sucked into a heavy EA tool with its voracious appetite for models, links and dependencies).
I guess the point I wanted to make is that my own epiphany a few years ago related to the fact that most people don’t need to know how most things work most of the time (if ever) and that trying to enable them to do so is a waste of time and a source of confusion and inaction. It is essentially impossible to create and then manage a fixed and central model of how an entire enterprise works works top to bottom, particularly by looking at horizontal implementation facets like processes, people or technology which change rapidly, independently and for different reasons in different capabilities. In addition the business models of capabilities are going to be very diverse and ‘horizontal’ views often encourage overly simplistic policies and standards for the sake of ‘standardisation’ that negatively impact large areas of the business. Throw in an increasing move towards the cloud and the consumption of specialised external services and this only becomes more of an issue. In this context it is far more critical to have a set of business architecture assets at different levels of abstraction that allow reasoning about the purpose, direction and execution strategy of the business, its capabilities and their implementation assets (this latter only for those capabilities you retain yourself in future). These assets need to be explicitly targeted at different levels of abstraction, produced in a contextually appropriate way and – importantly – facilitate far greater federation in decision making and implementation to improve outcomes. Effectively a framework for understanding and actionable insight is far more valuable than a mass of – mostly out of date – data that causes information overload, confusion and inaction. An old picture from a few years ago that I put together to illustrate some of these ideas is included below (although in reality I’m not sure that I see an “IT department” continuing to exist as a separate entity in the long term but rather a migration of appropriate staff into the enterprise and capability spaces with platforms and non-core business capabilities moving to the cloud).
In terms of relinquishing central control in this way it is possible that for transitional business architectures – where capabilities remain largely within the control of a single enterprise as today – greater federation coupled with a refined form of internal crowd sourcing could enable each independent model to be internally consistent and for each independent model to be consistent with the broader picture of enterprise value creation. I decided to do something else before getting to the point of testing this as a long term proposition, however, lol (although perhaps my former (business) partner in crime @pcgoodie who’s just started blogging will talk more about this given that he has more staying power than me and continues the work we started together, lol). Stepping back, however, part of the value in moving to this way of thinking is letting go and viewing things from a systems perspective and so the value of having access to all the detail from the centre will diminish over time.
In the broader sense, though, whilst I first had a low grade ‘business services as organisation’ epiphany whilst working at a financial services company in 2001 most of this thinking and these ways of working were inspired not by being inside an enterprise but rather subsequently spending time outside of one. Spending time researching and reflecting on the architectures, patterns, technologies and – more importantly – business models related to the cloud made me think more seriously about the place of an enterprise in its wider ecosystem of value creation and the need to concentrate completely on those aspects of the ecosystem that really deliver its value. In the longer term whilst there are many pressures forcing an internal realignment to become more customer-centric, valuable or cost effective, the real pressure is going to start building from the outside; once you realise that the enterprise works within a broader system you also start to see how the enterprise itself is a system, with most of its components being pretty poor or misaligned to the needs of the wider ecosystem and its consumers. At this point you begin to realise that you have to separate the different capabilities in your organisation and use greater design thinking, abstraction and federation, giving up control of the detail outside of very specific (and different) contexts depending on your purview. At that stage you can really question your need to be executing many capabilities yourself at all, since the real promise of the cloud is not merely to provide computing power externally but rather to enable businesses to realise their specialised capabilities in a way that is open, collaborative and net native and to connect these specialisations across boundaries to form new kinds of loose but powerful value webs. Such an end game will be totally impossible for organisations who continue to run centralised, detail-oriented EA programmes and thus do not learn to let go, federate and use abstraction to reason, plan and execute at different levels simultaneously.