Enterprise Architecture : A Pocket Guide [1 ed.] 9781849280174, 9781849280167

Citation preview

Enterprise architecture cover

13/5/09

08:37

Page 1

A Pocket Guide

Enterprise Architecture

Enterprise Architecture

Enterprise Architecture A Pocket Guide

Tom Graves

Tom Graves

Tom Graves

Enterprise Architecture A Pocket Guide

Enterprise Architecture A Pocket Guide

TOM GRAVES

Every possible effort has been made to ensure that the information contained in this book is accurate at the time of going to press, and the publishers and the author cannot accept responsibility for any errors or omissions, however caused. No responsibility for loss or damage occasioned to any person acting, or refraining from action, as a result of the material in this publication can be accepted by the publisher or the author. Apart from any fair dealing for the purposes of research or private study, or criticism or review, as permitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced, stored or transmitted, in any form, or by any means, with the prior permission in writing of the publisher or, in the case of reprographic reproduction, in accordance with the terms of licences issued by the Copyright Licensing Agency. Enquiries concerning reproduction outside those terms should be sent to the publishers at the following address: IT Governance Publishing IT Governance Limited Unit 3, Clive Court Bartholomew’s Walk Cambridgeshire Business Park Ely Cambridgeshire CB7 4EH United Kingdom www.itgovernance.co.uk © Tom Graves 2009 The author has asserted the rights of the author under the Copyright, Designs and Patents Act, 1988, to be identified as the author of this work. First published in the United Kingdom in 2009 by IT Governance Publishing. 978-1-84928-017-4

PREFACE

Organisations have structure. These structures are usually arrived at through evolution, mostly in response to changing markets, competitive challenges and tightening regulatory environments. This evolutionary – sometimes ad hoc – process for structuring organisations doesn’t always produce an organisational structure that is as competitive or effective as it might be. Enterprise architecture is the discipline that enables organisations to understand and plan, logically, how to structure business capabilities and processes, information resources, business systems and the technical infrastructure within an organisation to most effectively support the longer-term business strategy. While enterprise architecture is often thought of as a component of IT governance, it can be so much more; the effective application of enterprise architecture can contribute to optimisation of the business itself and, consequently, to real improvements in business productivity and performance. In the challenging economic climate faced by all organisations in the first and second decades of the twenty-first century, the use of an enterprise architecture could make all the difference between long-term success and failure. This pocket guide provides a timely and thorough introduction to, and overview of, this business-critical subject.

5

ABOUT THE AUTHOR

Tom Graves has been an independent consultant for almost three decades, in business transformation, enterprise architecture and knowledge management. His clients in Europe, Australia and the US cover a broad range of industries, including banking, utilities, logistics, engineering, media, telecoms, research, defence and government. He has a special interest in architecture for non-IT-centric enterprises, and integration between IT-based and non-IT-based services.

6

CONTENTS

Introduction......................................................... 8 Chapter 1: What is Enterprise Architecture?.. 9 Some definitions ................................................... 9 Why enterprise architecture matters ................... 11 Chapter 2: Business Drivers and Benefits ...... 13 Layers of business benefit................................... 13 Enterprise effectiveness ...................................... 16 Enterprise agility ................................................. 17 Chapter 3: Architecture and Governance ...... 18 Governance and standards .................................. 18 Architecture and IT governance.......................... 20 Architecture and corporate governance .............. 21 Chapter 4: Architecture Maturity................... 23 Ad hoc development of architecture.................... 23 Planned development of architecture.................. 25 Chapter 5: The Architecture Team................. 27 The make-up of the team .................................... 27 The business role of architecture ........................ 29 Chapter 6: Frameworks, Methods and Tools. 32 Architecture frameworks and methods ............... 32 Architecture standards......................................... 36 Architecture toolsets ........................................... 37 Chapter 7: Architecture in Practice ................ 40 Preparing for architecture.................................... 40 The architecture cycle ......................................... 41 Hands-off architecture......................................... 49 Engaging everyone.............................................. 51 ITG Resources ................................................... 54

7

INTRODUCTION

Enterprise architecture is a key competency for most large organisations of the present day. Its roots reach back some twenty years or more, in early efforts to reuse knowledge about software structure and design to assist in managing a rapid growth in the cost and complexity of IT systems in general. Compliance to a formal enterprise architecture framework is now mandatory in many government and defence contexts, and is increasingly common in other larger organisations. For most of its history, enterprise architecture has been regarded as belonging under IT governance. At the present time the discipline is evolving once more, and extending its scope to become a literal architecture of the enterprise. This pocket guide describes the purpose, role and value of architecture in the enterprise, and the make-up and skillsets of the architecture team in different business contexts. It explores the relationship between architecture, project management, change management and governance, and summarises the frameworks, methods, standards and toolsets currently in common use. Finally, it provides a brief outline of the typical activities and processes that are used in the development and realisation of an enterprise architecture.

8

CHAPTER 1: WHAT IS ENTERPRISE ARCHITECTURE?

Some definitions What is enterprise architecture, and why does it matter to business and to the governance1 of business and IT? The Practical Guide for the US Federal Enterprise Architecture Framework defines enterprise as: ‘…an organisation or cross-functional entity supporting a defined business scope or mission. [It] includes interdependent resources – people, organisations and technology – who must coordinate their functions and share information in support of a common mission or set of related missions.’2 Note that, as the same document also emphasises: ‘…in many cases, the enterprise may transcend established organisational boundaries – e.g. trade, grant management, financial management, logistics.’ A shared enterprise that extends beyond the organisation – as in a supply-chain or an industry consortium – may require more complex forms of governance, based on negotiation between partners rather than straightforward executive decisions. The Practical Guide defines architecture as: 1

See Chapter 3 for the specific meanings of ‘governance’ as used here. 2 See http://www.gao.gov/special.pubs/eaguide.pdf 9

1: What is Enterprise Architecture? ‘…the structure of components, their interrelationships, and the principles and guidelines governing their evolution and design.’ In effect, an ‘architecture’ in this context defines the content for a ‘knowledge base’ about structure, components, interrelationships and principles that are relevant to the needs of the enterprise. Note that the Practical Guide definition above does not restrict ‘architecture’ to a predefined scope, such as software or IT. Despite the common assertion – such as in the TOGAF™3 specification – that enterprise architecture is a subset of IT governance, its scope could, and for consistency generally should, extend to the entire enterprise.4 Combining the definitions above, enterprise architecture is thus a discipline through which an enterprise can identify, develop and manage its knowledge of its purpose, its structure and itself. Some of that knowledge will be about IT, but it will also need to include many other concerns: • • • • • • • • •

3

business architecture organisational structure performance management business continuity/resilience planning process architecture security architecture data architecture applications architecture technology–infrastructure architecture.

TOGAF™ Version 9, Van Haren, 2009. Tom Graves, Real Enterprise Architecture, Tetradian, 2008. 10 4

1: What is Enterprise Architecture? As a discipline, enterprise architecture provides a means to link together all of these differing ‘architectures’ and structural concerns. Why enterprise architecture matters The business purpose of the enterprise architecture body of knowledge is to provide decision support for direction and change at any level of the enterprise. Such decisions might include: • •

• •

executive – what the enterprise is and does, where it’s going, the choices in that journey programme and portfolio management – preferred technologies or process models for new developments operations planning – when to decommission an outdated legacy system resilience planning – alternative systems expected to be online by a specific date.

For example, the business questions enterprise architecture could be used to answer include: • • • •

‘What structures would we need to support this strategy?’ ‘What constraints will our existing structures place on our strategic choices?’ ‘What opportunities would be available to us with these innovations in our structures?’ ‘How quickly could we align the systems of this newly-acquired company with our own?’

Within the upper levels of the organisation, decision support from enterprise architecture will simplify the ‘conversation’ between strategy – which sets enterprise direction – and an enterprise11

1: What is Enterprise Architecture? wide programme management office (or equivalent) which implements the changes in capabilities and facilities required for each new strategy. Enterprise architecture will also assist in managing changes imposed on the organisation from outside, by the market, by regulations, or – at an operations level – by system failures, environmental incidents or customer complaints. A more mature enterprise architecture will be able to map interdependencies across almost every aspect of the enterprise. This would aid resilience planning, for example, by identifying the probable impact that a server failure would have on key business-performance metrics; or compliance management, by indicating the manual and automated parts of processes that would be affected by new legislation. A well-defined and well-maintained enterprise architecture is also proven to be a key factor in an organisation’s agility, effectiveness and ability to respond to risk, opportunity and change.5

5

Jeanne Ross, Peter Weill and David Robertson, Enterprise Architecture as Strategy, Harvard Business School Press, 2006. 12

CHAPTER 2: BUSINESS DRIVERS AND BENEFITS

Layers of business benefit The business benefits of enterprise architecture typically arise in layers, linked in part to the maturity of architecture capability,6 and to key business drivers that include: • • • •

Cost management Compliance management Risk management Opportunity management.

Cost management: Even from the earliest stages of enterprise architecture, there will be an urgent need for it to assist in managing and reducing the cost and complexity of the organisation’s systems – particularly its IT systems. The aim here will be to reduce redundancy and duplication, to enhance consistency and common meaning across the enterprise, and to control and constrain the proliferation of unmanaged and undocumented ‘point solutions’. Compliance management: Every enterprise faces an ever-increasing burden of conformity, such as: •

6

compliance to regulations: Sarbanes-Oxley (SOX), Basel II, anti-money-laundering, environment, health & safety, consumer protection, etc.

Tom Graves, Doing Enterprise Architecture, Tetradian, 2009. 13

2: Business Drivers and Benefits • • •

conformity to international standards: ISO9000, ISO14000, ISO27000, etc. alignment to industry standards: ITIL service management, Six Sigma, COBIT, etc. alignment to technical standards: ebXML financial reporting, RFID item tracking, payby-phone, etc.

Some of these requirements may at first seem to apply only to specific markets, countries or other business contexts. Yet, as a result of increasing globalisation and market or industry integration – for instance, many large organisations engage in global multi-partner supply chains – the conformity impacts increasingly throughout the enterprise, often in unexpected ways. Enterprise architecture provides a means to track impacts and dependencies, identify requirements for compliance, ensure consistency in solution designs, and aid in system-wide design of audit processes and procedures. For enterprise architecture, management of compliance concerns will build upon the previous work on management of cost and complexity. Risk management: Every enterprise also faces ever-increasing complexity and interdependencies of risks, such as: • • •

security risks: hacking, break-in, inadvertent data loss, etc. financial risks: theft, waste, excess inventory, loss in transit, etc. human risks: accident, personal injury, health risks, environmental risks, etc. 14

2: Business Drivers and Benefits •

operational risks: system failure, communications failure, fire, flood, etc.

•

reputation risks: damage to brand, damage to trust, ethics issues, fraud, etc.

.

Enterprise architecture assists in risk management by mapping trails of dependencies and potential points of failure. Linked with appropriate changegovernance, these will also identify the people responsible for resolving each potential or actual risk. When linked with appropriate techniques and tools, such as automated ‘discovery systems’ that track system status and performance, the trails of dependencies also aid in real-time impact analysis and prioritisation of response. One category of risk is failure to meet compliance requirements, hence for enterprise architecture, its decision support on risk management will build on the previous work on management of compliance. Opportunity management: To best achieve its goals, every type of enterprise will need to optimise its ability to create and respond to opportunities, such as: •

innovation opportunities: new products, new services, new technologies, etc.

•

market opportunities: new markets or market segments, new partnerships, etc.

•

structural opportunities: new structural models, such as service orientation, etc.

•

system opportunities: process improvements, technical improvements, etc.

As with risk management, enterprise architecture assists in opportunity management by mapping 15

2: Business Drivers and Benefits trails of dependencies, and highlighting gaps which could indicate potential opportunities. Linked with appropriate governance, and with knowledge-sharing tools and techniques – such as communities of practice and social network maps – these can also identify people who may assist with developing and realising each potential or actual opportunity. Opportunity and risk are closely related, hence for enterprise architecture, the work to support management of opportunity will draw extensively upon the architecture capabilities previously used to manage risk. Enterprise effectiveness The continual quest for improved efficiency is a common focus of concern for many organisations. However, efficiency is only one aspect of the real requirement, namely enhanced effectiveness.7 A broader view of effectiveness would include: • • • • •

7

efficient: makes the best use of available resources reliable: can be relied on to deliver the required results elegant: supports the human factors in the context appropriate: supports and sustains the overall purpose integrated: linked to and supports integration of the whole as a whole.

See ‘Dimensions of effectiveness’ chapter in Tom Graves, SEMPER and SCORE: enhancing enterprise effectiveness, Tetradian, 2008. 16

2: Business Drivers and Benefits Enterprise architecture supports enhanced effectiveness by identifying the interdependencies between these distinct themes. By maintaining an holistic overview of the enterprise, yet providing many different perspectives into that single view, the architecture supports improved integration across the whole, and enables trade-off analysis across all the differing domains and priorities of the enterprise. Enterprise agility Every commercial organisation is likely to seek out new means to assure and enhance its competitiveness. Likewise, every government department is likely to seek continual improvement in delivering its services to citizens. These needs are reflected in common business objectives, such as: • • • •

agility: reduced time to market, reduced service-cycle times, etc. adaptability: mass customisation, service mix and match, etc. responsiveness: adapt to needs of different markets, different regulations, etc. resilience: ride with and ride out the peaks and troughs of business change, etc.

For enterprise architecture, support for all of those outcomes would arise directly from its previous work for those other business drivers above: management of costs, complexity, compliance, risk, opportunity and overall effectiveness.

17

CHAPTER 3: ARCHITECTURE AND GOVERNANCE

Governance and standards Governance is a key component of any enterprise architecture – not least because the architecture itself provides compliance rules to constrain design decisions within the enterprise. In the US, one of the key governance drivers for enterprise architecture is the Information Technology Management Reform Act 1996,8 more often referred to as the Clinger-Cohen Act. This mandates the use of a defined enterprise architecture – at least, for information technology – in all US federal government departments. It places an explicit emphasis on: • • • •

capital planning and investment control performance-based and results-based management responsibilities of the CIO (Chief Information Officer) accountability.

A key requirement arising from the Act is compliance to FEAF9 (US Federal Enterprise Architecture Framework). Similar principles have been adopted at the state level of US government by NASCIO10 (National 8

http://govinfo.library.unt.edu/npr/library/misc/itref.html 9 www.gao.gov/special.pubs/eaguide.pdf 10 www.nascio.org 18

3: Architecture and Governance Association of State CIOs), and by many other governments and authorities worldwide, using localised variants of FEAF or other related frameworks. In the commercial sector, there is at present no equivalent law that mandates use of a specified architecture. In practice, however, some form of enterprise architecture is all but essential to achieve compliance to key laws and industryspecific directives, such as the (US) SarbanesOxley Act11 (SOX) on financial and accounting disclosure information, or the Basel II Accord12 on banking regulation. Much the same applies for compliance to many key international standards, such as ISO20000 on IT service management, ISO270010 on security management, or ISO14000 on environmental management. For all of those examples, the enterprise architecture will need a scope that extends beyond the conventional boundaries of information technology management. Within the enterprise itself, governance rules and processes will need to be required to manage all aspects of the enterprise architecture.13 This will include not only the development and use of the architecture, and the related responsibilities, reporting relationships and performance metrics, but also the identification and management of the governing principles and compliance rules, and of

11

www.soxlaw.com www.bis.org/publ/bcbsca.htm 13 See ‘Architecture Governance’ chapter in Open Group, TOGAF™ Version 9, Van Haren, 2009. 19 12

3: Architecture and Governance core knowledge assets, such as a shared glossary and thesaurus. Architecture and IT governance Enterprise architecture is often portrayed as an aspect of IT governance. Although architecture does need to cover a broader scope than IT alone, it does assist IT governance in several key ways: •

• •

•

•

supports consistency and cohesion across the technology infrastructure and application portfolio assists in defining and assuring compliance to standard terminology and meaning for business information identifies patterns, structures and frameworks to support implementation and monitoring of compliance to the applicable laws, regulations, technical (and other) standards assists in interpretation and implementation of requirements for business change, and in the processes for business change assists in identifying and assessing the impact of potential and actual business risks, and in design of antidotes for those risks.

There are also strong cross-links between enterprise architecture and key IT standards, such as the IT Infrastructure Library14 (ITIL) framework for IT service management – originally developed by the UK Office of Government Commerce, and associated with the ISO/IEC20000 standard – and the Control Objectives for 14

www.itil-officialsite.com 20

3: Architecture and Governance Information and related Technology15 (COBIT) framework for IT governance, developed by the IT Governance Institute. The Open Group, for example, has published a mapping between COBIT controls for IT governance and activities in their enterprise architecture framework TOGAF.16 Architecture and corporate governance At the corporate level, the board are responsible for governance concerns, such as reviewing and guiding corporate strategy, effective monitoring of management performance, and accountability to shareholders and other stakeholders. Other core themes in corporate governance include:17 • • • • • •

15

discipline: commitment to adhere to established procedures, standards, etc. transparency: actions taken and the processes by which decisions will be identifiable and auditable independence: mechanisms exist to avoid or minimise potential conflicts of interest accountability: groups and individuals within the organisation are authorised and accountable for their actions and decisions responsibility: each party acts responsibly in relation to the organisation and its stakeholders fairness: decisions and actions do not create unfair advantage for any party.

www.isaca.org/cobit/ www.opengroup.org/bookstore/catalog/w072.htm 17 Adapted from Ramani Naidoo, Corporate Governance, Double Storey, 2002. 21 16

3: Architecture and Governance Enterprise architecture can play an important role in this, by describing and ensuring compliance to structures to support each of these themes. These structures devolve from the defined vision, values and principles of the organisation, and help to keep the enterprise ‘on purpose’. One approach which has proved valuable for this is the notion of the ‘service-oriented enterprise’, in which the architecture of the enterprise is described in terms of layered interrelationships between business services, from strategy to detail-level operations.18 In addition to support for governance for other business drivers, such as cost management and opportunity management, there are also strong cross-links between enterprise architecture and other broader governance standards. These include compliance standards, such as SOX and Basel II, as mentioned above, and also established standards for project, programme and risk management, such as the UK Government’s PRINCE219 (Projects In Controlled Environments), MSP20 (Management of Successful Programmes) and M_O_R21 (Management of Risk).

18

Tom Graves, The Service Oriented Enterprise, Tetradian, 2009. 19 www.prince2.com 20 www.msp-officialsite.com 21 www.mor-officialsite.com 22

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 enterprisewide 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. 23

4: Architecture Maturity 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 IToriented ‘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 databaseserver 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 24

4: Architecture Maturity 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 overemphasis 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. 25

4: Architecture Maturity 1

2

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?’. 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. 26

CHAPTER 5: THE ARCHITECTURE TEAM

The make-up of the team The size, structure, skills and skillsets of the enterprise architecture team will change – often radically so – at different levels of architecture maturity. In the more usual ad hoc development sequence, the typical team make-up at each phase would be as follows: •

•

‘IT project architecture’ phase - Size and structure: no formal team – typically a responsibility taken on personally by a project manager or team leader, from necessity, and often without formal authority. - Skills and skillsets: extensive history and experience in many different aspects of IT, and ability to see relationships between them. ‘Enterprise-wide IT architecture’ phase -

-

Size and structure: explicit architecture team, initially perhaps half a dozen members, though later may number into dozens (or in some large enterprises maybe even one or two hundred analysts and architects) requires formal governance (as described in the previous chapter), and often viewed as an IT-specific capability Skills and skillsets: IT generalists, often with formal qualifications in one or more IT architecture themes, such as TOGAF 27

5: The Architecture Team

•

Certified Architect, Microsoft® Certified Architect, Cisco Certified Architect, etc.; overall skillset will include technology infrastructure architecture, application architecture and data architecture. ‘IT architecture with business architecture’ phase -

-

•

Size and structure: team will typically reduce in size as specialist sub-teams split off into domain-architecture; governance much as in the previous phase, though complicated by an explicit requirement to act as a bridge between business and IT. Skills and skillsets: extends the previous skillsets to include some aspects of business analysis and business architecture, though usually still with a firm emphasis on IT strategy and implementation.

‘Whole-of-enterprise architecture’ phase -

-

Size and structure: the architecture team continues to split off specialist sub-teams for domain architectures and segment architectures, until eventually only a small central team of cross-enterprise generalists remain; governance for architecture takes on more of a federal form, with the core team acting as a central co-ordinating body between all the specialist sub-teams. Skills and skillsets: the additional skills required will depend on the nature of the enterprise; the core team will need to be multi-skilled generalists, with extensive experience in both business in general and 28

5: The Architecture Team in the specific business context, and also with a broad (yet not necessarily in-depth) understanding of IT, knowledge management, process management, service management security and many other operational areas. Chapter 52 ‘Architecture Skills Framework’ of the TOGAF 9 specification25 provides a useful overview of the skills needed for earlier-maturity enterprise architecture, though not the full range of skills required for whole-of-enterprise architecture. In the planned development sequence a small, core team would be engaged throughout, of the same size and with the same generalist skillsets as for the ‘whole-of-enterprise architecture’ above. Team management structures and governance need to be in place so that other specialists can be coopted onto the team as required, dependent on the specific business questions in scope at the time. The effective size and skillsets of the architecture team would thus change dynamically over time in accordance with the business need. The business role of architecture The team will also require different reporting relationships at differing stages of architectural maturity. In the ad hoc development sequence, the typical reporting relationships in each phase would be as follows:

25

TOGAF™ Version 9, Van Haren, 2009, pp. 691–704, also online at www.opengroup.org/architecture/togaf9-doc/arch/ 29

5: The Architecture Team •

‘IT project architecture’ phase: reports to project manager.

‘Enterprise-wide IT architecture’ phase: reports to programme/portfolio manager, or preferably to senior IT executive, such as CIO or CTO. • ‘IT architecture with business architecture’ phase: usually reports to CIO, or CFO in some organisations, though ideally either direct or indirect to the CEO or full executive. • ‘Whole-of-enterprise architecture’ phase: core team typically attached to a strategy group reporting direct to CEO; sub-teams report to the lead for the respective domain (e.g. CFO, CIO, COO, HR) or segment (e.g. VP, business-unit MD). Many enterprise architecture units may experience significant structural and governance problems when their reporting relationships need to change at the boundaries between maturity levels. The move upward from a ‘traditional’ IT-centric scope to take on a broader-based role seems to be the most difficult transition, but failure to make the change can cause the eventual collapse of the entire architecture capability. The usual solution is to split the team, such that the IT architecture specialists can remain under IT governance, whilst the more business-oriented generalists continue on to develop the broader enterprise scope. •

In the planned development sequence, the core team should report to the CEO or executive board, though initially this will often be indirect via an enterprise-wide strategy or change management unit. During each architecture cycle, the core team 30

5: The Architecture Team and any co-opted specialists would also have a dual reporting relationship, with the respective business sponsor for the specified work.

31

CHAPTER 6: FRAMEWORKS, METHODS AND TOOLS

Architecture frameworks and methods An architecture framework summarises or describes how meaning is determined within the architecture. There are several different types of framework, with different roles and functions in architecture development. Perspective frameworks split the overall scope of the architecture into a simplified set of views, to provide a basic taxonomy for modelling. These views are often arranged in the form of a grid or box matrix: the well-known Zachman framework, for example, uses the interrogatives What, How, Where, Who, When and Why as one axis of a grid, and roles, such as Planner and Owner as the other. Each perspective is represented by a single cell, constraining the respective scope: in Zachman, a data architect, for example, is primarily concerned with data as a kind of ‘What’ and its transformations between the ‘Designer’ (‘logical’) and ‘Builder’ (‘physical’) views. Examples of perspective frameworks include: • •

26 27

Zachman Framework26 Capgemini IAF27 (Integrated Architecture Framework)

www.zifa.com www.capgemini.com/services/soa/ent_architecture/iaf/ 32

6: Frameworks, Methods and Tools

•

Sogeti DyA28 (Dynamic Architecture).

However, most of these frameworks revolve around IT, and it is probably unwise to use them outside of those constraints. For example, none of the above frameworks provide any means to model manual or machine-based components of business processes, rendering many real-world process models either incomplete or misleading. Extended frameworks29 will be needed as architecture maturity expands the scope beyond IT alone and outward to encompass the whole enterprise. Reference frameworks describe structures, items and relationships between them for use in a specific architectural context, together with compliance rules about the respective degree of bindedness – mandatory, recommended, suggested or optional. – for the use of the item in designs or implementations. Some examples of reference frameworks include: •

•

IT: TOGAF TRM (Technical Reference Model) and IIIRM (Integrated Information Infrastructure Reference Model) government: FEAF (US Federal Enterprise Architecture Framework)

http://eng.dya.info, also Martin van den Berg and Marlies van Steenbergen, Building an Enterprise Architecture Practice, Springer, 2006. 29 See ‘Framework’ chapters in Tom Graves, Bridging the Silos, Tetradian, 2008, or summary sheet at http://tetradianbooks.com/ebook/silos_real-ea-frameref.pdf 33 28

6: Frameworks, Methods and Tools defence: DODAF30 (US Department of Defense Architecture Framework), MODAF31 (UK Department of Defence Architecture Framework) • telecom: TeleManagement Forum eTOM32 (Enhanced Telecom Operations Map), and SID33 (Structured Information/Data). Ontology frameworks are different in that they do not provide a fixed pattern of entities or viewpoints, but emphasise relationships between the entities and perspectives, using a formal syntax or notation to describe them. This more versatile and adaptable approach to modelling is commonly used for enterprise architecture in Europe, though still often limited to systems architecture elsewhere. Examples of ontology frameworks include: • xAF34 (extensible Architecture Framework) • ArchiMate35 • Object Management Group MDA36 (Model Driven Architecture). Colloquially, the term ‘framework’ is also often used, or misused, to indicate the overall approach to architecture. In TOGAF and DyA, for example, the ‘framework’ also includes methods, maturity models and other supporting information. •

www.architectureframework.com/dodaf www.modaf.org.uk 32 www.tmforum.org/browse.asp?catID=1647 33 www.tmforum.org/DocumentsInformation/1696/home.ht ml 34 www.naf.nl/nl/werkgroepen/xaf.html and www.demo.nl also Jan Dietz, Architecture: building strategy into design, Academic Services, 2008. 35 www.archimate.org 36 www.omg.org/mda 34

30 31

6: Frameworks, Methods and Tools A methodology describes a structured set of methods to develop an architecture. The TOGAF ADM (Architecture Development Method) is probably the best known of these: an extended version for use at the whole of enterprise scope is summarised in the next chapter. Although generic methods, such as the TOGAF ADM, can be used for most types of enterprise architecture, specific methods will also be needed within each architecture domain – a view or emphasis within the overall scope. These domains or emphases include: • • • • • • • •

business architecture data or information architecture applications architecture technology infrastructure architecture service architecture or service-oriented architecture (SOA) security architecture process architecture capability architecture.

Each compliance requirement also implies its own architecture domain. Note that some frameworks or methods constrain the view of an architecture domain in ways that may be misleading. For example, whilst TOGAF includes a nominal ‘business architecture’ domain, its view is constrained only to those parts of the business that impact on IT, and is not sufficient for use outside of an IT-centric scope. If necessary, adapt the framework or method to match the full domain scope required.

35

6: Frameworks, Methods and Tools Architecture standards Although enterprise architecture may reference many formal and industry-specific standards, as yet there are few standards that apply to architecture itself. Context standards define the ways in which specific aspects of architecture should be described and presented. One example is the Business Rules Group BMM37 (Business Motivation Model), used in several architecture toolsets as the standard for modelling business strategy, requirements and decisions. Notation standards define how entities and their relationships should be modelled and presented. UML38 (Unified Modeling Language) and ArchiMate are two notation standards commonly used for modelling across a wide range of the enterprise architecture scope. The Business Process Management Initiative BPMN39 (Business Process Modeling Notation) and (US) National Institute of Standards and Technology IDEF040 are also widely used as a standard notation for process models. Interchange standards specify how information should be exchanged between architecture toolsets. Unfortunately, no such standard exists at present: the nearest is the Object Management Group XMI41 specification, which is aimed more www.businessrulesgroup.org/bmm.shtml www.uml.org 39 www.bpmn.org 40 www.idef.com/idef0.html 41 www.omg.org/technology/documents/formal/xmi.htm 36 37 38

6: Frameworks, Methods and Tools at software architecture rather than enterprise architecture. TOGAF 9 includes a preliminary definition for a standardised architecture metamodel, but still needs extensive work to make it usable as a standard, especially beyond an ITcentric scope. Architecture toolsets Some architecture work will be done on a whiteboard, or even on the back of a napkin; but for most types of architecture assessment, some form of software support will be indispensable. In the early stages of architecture development it is possible to get by with ordinary office tools, such as Microsoft® Word®, Excel® and Visio®. But as architecture maturity develops, a purpose-built architecture toolset will soon become essential, to manage the scope and complexity of the content and interrelationships, and their reuse across different diagrams, views and versions. Because the overall scope of enterprise architecture is so broad, each toolset will emphasise different aspects or functions. Some emphasise business processes, whilst others are geared more toward system or software development. Some focus on visual modelling; others emphasise the formal logic of the underlying meta-model; a few are designed primarily to work with specific notations. Examples of these different types of toolsets include: • 42

process-oriented: IDS-Scheer ARIS42 www.ids-scheer.com 37

6: Frameworks, Methods and Tools • • • •

software-oriented: IBM Telelogic System Architect43, Sparx Enterprise Architect44 model-oriented: Casewise45, Mega46, Provision,47 Orbus iServer48 meta-model-oriented: Promis EVA NetModeler49, Troux Metis50 notation-oriented: BizzDesign51 (for Archimate).

All of the purpose-built toolsets will export diagrams, spreadsheets and text-based reports, and most can also publish to an intranet or website, to enable other staff to view or even interact with the architecture content. Architecture toolsets do vary widely in their functions, capabilities and cost; and to gain the best business value, all of them require a significant investment of effort by the architecture team and others. It is therefore essential to assess each tool carefully against clearly-defined business needs, to identify the best fit for the organisation. The TOGAF 9 specification includes a useful overview52; a more detailed set of evaluation

www.telelogic.com/Products/systemarchitect www.sparxsystems.com.au 45 www.casewise.com 46 www.mega.com 47 www.metastorm.com/products 48 www.orbussoftware.com/enterprise architecture/ 49 www.pro-mis.com 50 www.troux.com 51 www.bizzdesign.nl 52 Chapter 42, ‘Tools for Architecture Development’, in TOGAF™ Version 9, Van Haren, 2009. 38 43 44

6: Frameworks, Methods and Tools criteria can be found on the IFEAD53 (Institute for Enterprise Architecture Development) website.

53

www.enterprise architecture.info/EA_Tools.htm 39

CHAPTER 7: ARCHITECTURE IN PRACTICE

Preparing for architecture The current level of architecture maturity determines the type and scope of work that can be undertaken, and the preparation needed before starting work. Typical items to be assessed include: •

• • •

• •

• •

governance: funding, reporting relationships, organisational authority, primary stakeholders, performance metrics, etc. principles: applicable guidelines, policies, priorities, etc. standards: applicable laws, regulations, external and internal standards, etc. scope: primary focus of work, aligned to maturity level – e.g. technology infrastructure, information systems, business integration – and core business goals and business drivers, etc. frameworks: applicable taxonomies, ontologies, reference models, etc. methods: architecture development, solution development, implementation, project management, change management, administrative procedures, etc. tools: capture, edit, scenario development, presentation, communication, etc. repositories: architecture models and artefacts, documents, requirements, risks, opportunities, 40

7: Architecture in Practice issues, architecture dispensations, glossary and thesaurus, etc. Each of these items will need regular review as the maturity of the practice develops. The TOGAF 9 specification provides a proven detailed description54 of the preparation needed for mid-maturity architecture centred on IT. Some amendments will be required to adapt that description for use in later-maturity architecture, and to broaden its scope beyond IT, but its general principles remain sound at all maturity levels. The architecture cycle Architecture development is iterative, a continual process of assessment, design and implementation. For best return on effort, iterations need to be brief, that resembles an Agile55 softwaredevelopment cycle, each iteration linked to a specific business purpose and demonstrable business value. Despite some amendments in its Version 9, the TOGAF-ADM cycle is still in essence a Waterfall style of development: it is iterative, but iterations tend to last months, if not years. The architecture method summarised here56 extends the ADM to work with any business level or scope and align with Agile governance principles. It can be used Chapter 6 ‘Preliminary Phase’ and Part VII ‘Architecture Capability Framework’ in TOGAF™ Version 9, Van Haren, 2009. 55 www.agilealliance.org 56 For details, see the ‘Methodology’ chapters in Tom Graves, Bridging the Silos, Tetradian, 2008. 41 54

7: Architecture in Practice for assessments of any duration, even as brief as a few hours.

Benefits-realisation validation and review (‘lessons learned’ etc)

Figure 1: Architecture method – governance defines phase boundaries

The method also maps well with PRINCE2 and similar programmes or project management methods and governance. Each phase ends with a formal stakeholder review, and the key governance documents or ‘products’ also mark the boundaries between the architecture cycle phases. Architecture projects and their iterations are managed in accordance with the rules defined in the preparatory Preliminary Phase, whose tasks include: 42

7: Architecture in Practice • • • • • • • • •

Establish the enterprise architecture capability Identify ‘Architecture Principles’ Identify applicable business policy, legislation and regulations Identify applicable Standards Identify core business goals and business drivers Identify enterprise architecture scope Identify constraints Identify stakeholders and concerns, business requirements, and overall architecture Vision Identify content for high-level models.

The final step is a stakeholder review to secure formal approval for the Architecture Charter and other governance definitions. The assessment phases of the cycle deliver architecture models, design requirements and the like. The focus of governance is more on the architecture itself than on programme management, though the latter should be informed and engaged throughout the assessment process. Phase A – establish iteration scope This phase is the starting point of a regular architectural-services cycle to identify the purpose, scope and context for the current iteration. Typical steps include: • • •

Establish the business purpose and scope of the cycle Review applicable Architecture Principles, policies, etc. Identify business goals and strategic drivers 43

7: Architecture in Practice • • •

Establish the architecture-framework scope of the cycle57 Identify additional stakeholders, concerns and requirements Identify additional constraints.

The stakeholders review the results, documenting formal approval to proceed in a Statement of Architecture Work. Phase B – assess current context This phase establishes the current ‘as-is’ architectural context for the scope specified in Phase A. Typical steps include the following: • • • • •

Develop Baseline Architecture for ‘as-is’ context Select reference models, views and viewpoints Create and update ‘as-is’ architecture models Review ‘as-is’ architecture against qualitative criteria Finalise building-blocks for the architectural scope.

The stakeholders review the results of the assessment, and confirm the ‘as-is’ definition. Phase C – assess future context This phase establishes the probable or intended future context for the scope and each future time horizon specified in Phase A. The steps are almost identical to those in the ‘as-is’ assessment: the only difference should be that the architecture developed would apply to the respective time See the ‘Framework’ chapters in Tom Graves, Bridging the Silos, Tetradian, 2008. 44

57

7: Architecture in Practice horizon rather than the ‘as-is’. All steps should be repeated for each time horizon in scope. • • • • •

Develop Baseline Architecture for ‘to-be’ context Select reference models, views and viewpoints Create and update ‘to-be’ architecture models Review ‘to-be’ architecture against qualitative criteria Finalise building-blocks for the architectural scope.

On completion of assessments for all required time horizons, the stakeholders review and compare the results, and confirm the definition of the required ‘to-be’ for each time horizon. Phase D – derive change requirements This phase establishes the gap between the ‘as-is’ and ‘to-be’ for the scope and each time horizon specified in Phase A, and identifies the resultant requirements for change. All steps should be repeated for each time horizon in scope. • • • •

Construct and validate matrix of ‘as-is’ to ‘tobe’ architectures Derive change requirements from validated matrix Review requirements against existing dispensations Review requirements against qualitative criteria.

On completion of gap analyses for all required time horizons, the stakeholders review and compare the results, and confirm the change requirements definitions for each context. 45

7: Architecture in Practice In the solution phases, the focus of governance moves to project and programme management, with enterprise architecture called upon mainly to provide architectural guidance and arbitration between projects,. and maintain high-level consistency as the architecture changes over time. Note that the design and implementation phases (E to G) may not always be required. Not every assessment will lead to requirements for change; and of those that do, many of the requirements may be operational or cultural rather than technical. In particular, it should be understood that architectural assessments do not lead automatically to requirements for IT-based ‘solutions’. Phase E – design solutions During this phase, the architecture unit will provide technical and other support to assist the sponsor in selecting appropriate options to resolve the respective change requirements. In this phase, solution designs will usually be at a high-level only. Note that the key responsibility for decisions on solution designs rests with the sponsor, not the architecture unit. Typical steps include: • • • •

Review gap analysis and requirements from Phase D Identify business drivers and constraints for implementation Brainstorm technical requirements from functional perspective Brainstorm co-existence and interoperability requirements

46

7: Architecture in Practice • • •

Perform architecture reassessment and gap analysis Develop preliminary solution designs Identify major work packages or projects.

At the end of the assessment, stakeholders will review and sign off any solution designs. Phase F – plan migration During this stage, the architecture unit assists the sponsor and programme management in developing detailed solutions and plans to implement the proposed solutions. The key responsibility for decisions rests with the sponsor and the programme-management body, not the architecture unit. Enterprise architecture has more of a ‘watching brief’ than an active role in this phase. Dependent on detail-level governance for project, programme and change management, typical steps would include: • • • • • •

Prioritise projects Estimate resource requirements and availability Perform cost/benefit assessment of the various migration projects Perform risk assessment Generate time-lined implementation roadmap Document the Migration Plan.

On completion, the sponsor and other stakeholders will review and sign off the final solution designs and project or migration plans.

47

7: Architecture in Practice Phase G – guide implementation During this phase, the architecture unit supports designers, developers, programme management and others to sustain architecture compliance during implementation of the solutions and plans from the previous phases. Overall governance belongs to project or programme management. The architecture unit should assess architecture issues arising from each ‘gateway’ in the project plan; typical steps at each gateway would include: • • •

Review Architecture Compliance Statement from developers Assess impact on overall architecture Provide architecture advice in an Architecture Response Statement.

At the end of each project in the migration plan, stakeholders will carry out a review of any architecture issues arising from the implementation. Phase H – review lessons learned During this phase, the architecture unit reviews the results of the iteration in terms of benefits achieved for the business, as well as implications and impact on overall future architecture. This will often result in updates or additions to the set of primitives, models, meta-models, patterns, and other content in the architecture repository; to requirements, standards and other decisions; to the content of the shared glossary and thesaurus; and entries in the issues and risks registers. In a ‘traditional’ Waterfall approach, such as in the TOGAF model, only one architecture cycle is in 48

7: Architecture in Practice process at any time, hence the lessons-learned review takes place at the end of the cycle. However, in an Agile-type context, and as architecture maturity develops, many cycles may be running in parallel, with differing scopes and at different rates, all interleaving with each other. In that method it makes more sense to conduct these reviews on a regular basis – weekly or monthly – rather than at the end of each cycle. In either case, typical review steps include: • • • •

Assess results from the architecture cycle Monitor changes in business and technology environment Assess potential changes to framework, methodology, etc. Assess requirements and options for architecture change.

On completion, architecture stakeholders reevaluate the results of the architecture work, and sign off on any proposed architecture cycles and other changes arising from the review. Hands-off architecture A mature enterprise architecture capability can also take a ‘hands-off’ approach, allowing some aspects of the architecture to emerge in their own way from the complexity of the context.58 Note that use of such a strategy should only be attempted where the implications and trade-offs are fully understood and addressed: it is not suitable solely as a cost-cutting exercise. A key See the ‘Methodology’ chapters in Tom Graves, Bridging the Silos, Tetradian, 2008. 49

58

7: Architecture in Practice driver for a hands-off approach is to move the architecture focus from management of compliance to management of opportunity – the flipside of risk. Hands-off architecture relies on the existence of a well understood ‘city plan’ for the architecture of the enterprise. For projects and change programmes, governance depends on two key documents: the Architecture Description Statement, and Architecture Position Statement. The project management cycle should include one or more ‘notify’ gateways at which the architecture unit is notified about the architecture implications of a proposed development. At each Notify gateway, the developers present an Architecture Description Statement to programme management, summarising the architecture of their solution and its usage of, and compliance to, the respective reference frameworks in the ‘city plan’. (This is equivalent to the assessments developed in the ‘assessment’ phases of the main architecture cycle, but prepared by the developers rather than the architects.) The architecture unit has the option to respond via an Architecture Position Statement, outlining any recommended changes. The programme management unit acts as the final arbiter. The architecture unit also maintains a watch on all projects passing through programme management, to identify potential for project synergies, and emerging developments that might suggest revisions to the overall architecture and ‘city plan’. At the end of the project cycle is an ‘As-built’ gateway in which the developers create a 50

7: Architecture in Practice simplified Architecture Description Statement to notify the architecture unit about the architecture of the final ‘as-built’ solution. This again allows the architecture unit to watch for emergent innovations, and also to plan remedial action if required. Engaging everyone No matter how good the architecture development is, it will only have real value for the enterprise if it is applied and put to practical use. The key requirement for this is some form of feedback and engagement of stakeholders, not only in the initial development of architecture, but also its dissemination, review and reuse. For publishing, all of the purpose-built architecture toolsets will autogenerate content for an intranet or website. Some toolsets include facilities to control access to, and visibility of, architecture models and other content; some also include wikis and other mechanisms to permit feedback and discussion via the architecture website. Enterprise architecture is a discipline that enhances enterprise effectiveness by helping people create structures that best support the required business values. It manages a body of knowledge about enterprise structure and purpose, but that information has no inherent value in itself: instead, its value arises from how it is used, across every domain of the enterprise.

51

7: Architecture in Practice It is essential for architects to measure the business value of their work by any means available. These include: • •

• •

• •

Measurable operations – cost savings from reduced redundancy and duplication Measurable development – cost savings from reduced duplication of effort and from identifying synergies between projects Measurable gains in reduced time to market, time to project completion, etc. Measurable or identifiable gains from simplifying system integrations after merger or acquisition Creation of, or direct support for, identifiable business opportunities and innovations Business improvements implied by improved performance against a verifiable architecturematurity metric.59

Maturity models are important because much of the business value gained, especially in latermaturity architecture, arises from interactions across the whole of the enterprise. It cannot be tracked by any single metric: it can only be measured in terms of the performance of the whole. Ultimately, the real business value of enterprise architecture lies not so much in the models and designs and other artefacts, but more in engaging everyone in an enterprise-wide dialogue on architecture – in creating and maintaining an Sogeti Maturity Matrix: http://eng.dya.info/Home/services/architecture_maturity _model.jsp 52 59

7: Architecture in Practice awareness of the advantages to everyone of ‘thinking architecturally’ in every aspect of the enterprise.

53

ITG RESOURCES IT Governance Ltd. sources, creates and delivers products and services to meet the real-world, evolving IT governance needs of today’s organisations, directors, managers and practitioners. The ITG website (www.itgovernance.co.uk) is the international one-stopshop for corporate and IT governance information, advice, guidance, books, tools, training and consultancy.

Other Websites Books and tools published by IT Governance Publishing (ITGP) are available from all business booksellers and are also immediately available from the following websites: www.itgovernance.co.uk/catalog/355 provides information and online purchasing facilities for every currently available book published by ITGP. www.itgovernanceusa.com is a US$-based website that delivers the full range of IT Governance products to North America, and ships from within the continental US. www.itgovernanceasia.com provides a selected range of ITGP products specifically for customers in South Asia. www.27001.com is the IT Governance Ltd. website that deals specifically with information security management, and ships from within the continental US. Pocket Guides For full details of the entire range of pocket guides, simply follow the links at www.itgovernance.co.uk/publishing.aspx.

54

Toolkits ITG’s unique range of toolkits includes the IT Governance Framework Toolkit, which contains all the tools and guidance that you will need in order to develop and implement an appropriate IT governance framework for your organisation. Full details can be found at www.itgovernance.co.uk/ products/519. For a free paper on how to use the proprietary CALDERMOIR IT Governance Framework, and for a free trial version of the toolkit, see www.itgovernance.co.uk/calder_moir.aspx. There is also a wide range of toolkits to simplify implementation of management systems, such as an ISO/IEC 27001 ISMS or a BS25999 BCMS, and these can all be viewed and purchased online at: http://www.itgovernance.co.uk/catalog/1 Best Practice Reports ITG’s range of Best Practice Reports is now at www.itgovernance.co.uk/best-practice-reports.aspx. These offer you essential, pertinent, expertly researched information on an increasing number of key issues including Web 2.0 and Green IT. Training and Consultancy IT Governance also offers training and consultancy services across the entire spectrum of disciplines in the information governance arena. Details of training courses can be accessed at www.itgovernance.co.uk/training.aspx and descriptions of our consultancy services can be found at http://www.itgovernance.co.uk/consulting.aspx. Why not contact us to see how we could help you and your organisation?

55

Newsletter IT governance is one of the hottest topics in business today, not least because it is also the fastest moving, so what better way to keep up than by subscribing to ITG’s free monthly newsletter Sentinel? It provides monthly updates and resources across the whole spectrum of IT governance subject matter, including risk management, information security, ITIL and IT service management, project governance, compliance and so much more. Subscribe for your free copy at: www.itgovernance.co.uk/newsletter.aspx.

56