CHAPTER 4: ARCHITECTURE MATURITY – Enterprise Architecture: A Pocket Guide

CHAPTER 4:
ARCHITECTURE MATURITY

Ad hoc development of architecture

In many organisations, enterprise architecture will develop in an unstructured fashion, although in four distinct phases. Each phase will demand its own discrete forms of governance to match the requisite level of architecture maturity.

A concern with architecture will typically start within larger IT projects. The usual driver here is often an urgent attempt to rein in the cost and complexity of links between new and existing IT systems. There is usually no formal architecture team as such at this stage, and governance will be provided by standard project management.

There is an increasing awareness of the need for horizontal consistency across IT systems, not just in technology and interfaces, but also in data structures and in the applications portfolio.

This leads to a demand for a defined enterprise-wide IT architecture. A formal architecture team is set up, under its own explicit governance rules, 22 though the architecture development itself is often treated simply as another large-scale project. An ‘architecture blueprint’ is developed to define the required future configuration of all IT systems, together with a ‘roadmap’ to describe transition stages toward that ideal. Architecture also begins to be included within management of change

22 See ‘Architecture Governance’ chapter in TOGAF 9 specification.

programmes, to aid in rationalisation across the IT space and to identify potential synergies between projects.

The focus on compliance to the defined architecture ‘blueprint’ also provides a means to manage an increasing top-down emphasis on compliance to new regulations and standards that impact on the business.

At some point there will be a recognition that the same applies to strategy, and hence a need to link IT architecture with business drivers. An IT-oriented ‘business architecture’ will be developed to help business and IT to understand each other’s strategic needs. However, this version of the architecture will often protect the common perception by IT that they exist parallel to the business, as an autonomous ‘internal service provider’ that the business exists to serve – a delusion that is the source of much antipathy between others and IT.

Business should also be concerned about management of risk – hence a new architectural emphasis on mapping bottom-up trails of dependencies from real-time operations up to business-performance metrics – for example, from disk drive to server hardware to virtual database-server to business application to business process to process performance to sales performance to profit margin – to aid in planning for business continuity and disaster recovery.

Finally, there will be a belated realisation that architecture needs to extend beyond IT, to a true whole-of-enterprise architecture. This realisation will also help to create acknowledgement that IT is, and needs to be, an integral component of the business. Within the architecture, stronger links will be developed horizontally between manual and automated parts of business processes, to enable better trade-off analysis; and vertical links to model ‘pervasive’ themes, such as security, quality, privacy, safety and other compliance concerns.

This supports a new emphasis on opportunity management, and also enables spiral-out analysis of intractable ‘wicked problems’23 in the business, in which each attempt at a solution changes the nature of the problem itself. These can only be resolved at a whole-of-enterprise level, and require a balanced perspective across the entire people, process, and technology aspects of the problems.

Planned development of architecture

Although the ad hoc sequence above is typical, it cannot be recommended, not least because some stages – particularly the development of an enterprise-wide IT architecture – may take a long time before returning any significant business value. Instead, it would be preferable to take a more planned approach, avoiding any over-emphasis on IT, and using defined architecture governance right from the start: 24

23 See http://www.cognexus.org/id42.htm and Wikipedia summary at http://en.wikipedia.org/wiki/Wicked_problem

24 For more detail on this development sequence, see Tom Graves, Doing Enterprise Architecture, Tetradian, 2009.

1 Develop high-level business architecture – business value is that it aids communication across the enterprise, as it defines an agreed model of the formal answer to ‘What business are we in?’.

2 Describe ‘logical’ abstract information systems and inventories of key existing information-related assets, including networks and hardware, information structures, IT applications and people-related processes – business value is a clear roadmap for change from ‘as is’ to the desired ‘to be’.

3 Create top-down links to support implementation and verification of strategy and compliance – business value is derived by linkage to a specified ‘business question’ in each case.

4 Create bottom-up links for business continuity and impact analysis – business value arises from preparedness for and responsiveness to incidents of any kind.

5 Create stronger links with other teams, such as knowledge management and quality management, for integrated analysis across the whole spectrum – business value arises from improved agility, and greater ability to tackle and resolve previously intractable ‘wicked problems’ and other business ‘pain points’.

The last three stages are similar to those in the ad hoc approach, but emphasise whole-of-enterprise integration throughout, supporting far faster return on investment and effort.