Doing Enterprise-Architecture A Maturity-Model Guide to Architecture Development (Tom Graves, Slade Beard) (z-library.sk, 1lib.sk, z-lib.sk)
,
Software
Enterprise architecture is a set of business practices that connect an organization’s strategy with its management of change. It is concerned with the structure and story of the enterprise, and ensuring that everything across the whole enterprise will work together in the most effective way. Yet when doing enterprise architecture, what should we do, in what sequence, and for what business purpose? What skills and leadership do we need? What results should we expect? And how can we prove the business value of what we do? This book sets out to answer those questions and show how, with the right architecture support, every change in the organization can be a change for the better. The book explains that to achieve this, we will need a literal ‘architecture of the enterprise’ that can start anywhere and can address every aspect of the enterprise, including people, machines, IT and more. We will need architecture development methods that can work consistently and in the same way everywhere, for every type of content or context, at every scope and scale, with every timescale, and throughout every stage of the change process. We will need those methods to support not just planned change, but provide continuity over longer periods, These methods must also respond fast to unexpected opportunities, risks and large-scale challenges arising within the organization and its market, and from the real-world beyond the enterprise itself. The book describes how to satisfy all of those needs, using a formal dependency-driven maturity-model to guide systematic step-by-step development of the organization’s capabilities for enterprise architecture. The sequence of steps ensures that, at each stage of development, the architecture can be relied upon to achieve desired, effective business outcomes. This book is for : Enterprise Architects.
Registered users can read the full content for free
Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.
Page
1
Doing Enterprise- Architecture A Maturity-Model Guide to Architecture Development — Tom Graves Slade Beard
Page
2
Doing Enterprise-Architecture A Maturity-Model Guide to Architecture Development Tom Graves Slade Beard
Page
3
Doing Enterprise-Architecture: A Maturity-Model Guide to Architecture Development ISBN-13 (pbk): 979-8-8688-1756-4 ISBN-13 (electronic): 979-8-8688-1757-1 https://doi.org/10.1007/979-8-8688-1757-1 Copyright © 2025 by Tom Graves and Slade Beard This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Trademarked names, logos, and images may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, logo, or image we use the names, logos, and images only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. While the advice and information in this book are believed to be true and accurate at the date of publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made. The publisher makes no warranty, express or implied, with respect to the material contained herein. Managing Director, Apress Media LLC: Welmoed Spahr Acquisitions Editor: Aditee Mirashi Development Editor: James Markham Coordinating Editor: Jacob Shmulewitz Cover designed by eStudioCalamar Cover image designed by Ghinzo@Pixabay.com Distributed to the book trade worldwide by Springer Science+Business Media New York, 1 New York Plaza, New York, NY 10004. Phone 1-800-SPRINGER, fax (201) 348-4505, e-mail orders-ny@springer-sbm.com, or visit www.springeronline.com. Apress Media, LLC is a Delaware LLC and the sole member (owner) is Springer Science + Business Media Finance Inc (SSBM Finance Inc). SSBM Finance Inc is a Delaware corporation. For information on translations, please e-mail booktranslations@springernature.com; for reprint, paperback, or audio rights, please e-mail bookpermissions@springernature.com. Apress titles may be purchased in bulk for academic, corporate, or promotional use. eBook versions and licenses are also available for most titles. For more information, reference our Print and eBook Bulk Sales web page at http://www.apress.com/bulk-sales. Any source code or other supplementary material referenced by the author in this book is available to readers on GitHub (https://github.com/Apress). For more detailed information, please visit https://www. apress.com/gp/services/source-code. If disposing of this product, please recycle the paper Tom Graves Tetradian Consulting, Eaglehawk, VIC, Australia Slade Beard Ecothought Pty Ltd, Victoria, 3453, Harcourt, Australia
Page
4
(This page has no text content)
Page
5
(This page has no text content)
Page
6
(This page has no text content)
Page
7
(This page has no text content)
Page
8
(This page has no text content)
Page
9
(This page has no text content)
Page
10
ix About the Authors Tom Graves has been an independent consultant for more than four decades, in business transformation, enterprise-architecture, and knowledge management. His clients in Europe, Australasia, and the Americas cover a broad range of industries including small-business, banking, utilities, manufacturing, logistics, engineering, media, telecoms, research, defense, and government. He has a special interest in whole-enterprise architectures for non-profit, social, government, and commercial enterprises. Slade Beard is an ICT architect and program manager with extensive experience in the design and implementation of ICT infrastructure environments, including integration with large construction projects. He has knowledge and experience in major IT infrastructure rollouts in the defense, national security, emergency services, health, and secure systems environments. He has proven experience in supporting the effective design, implementation, and commissioning of complex ICT systems in high-risk environments where considerations such as avoiding disruption of existing operations are crucial to project success. In addition, as a result of his extensive construction design and build experience, he can frame and articulate the integration of complex ICT systems within the services elements of facility build considerations and act as an effective advocate for ICT requirements within construction teams. You will find him actively blogging on LinkedIn. You can also contact Slade via LinkedIn.
Page
11
xi Introduction Enterprise-architecture is a professional discipline that is becoming ever more important in business and elsewhere. But what do enterprise-architects actually do? And what kind of business value arises from that work? The role of enterprise-architecture is to help each organization to be more effective in achieving its aims, by ensuring that everything in the enterprise can work better, together, and on-purpose, in an often fast-changing world. To do this, enterprise- architects create and manage a body of knowledge about enterprise structure, story, and purpose that is used to guide all types of change within the enterprise. It is a strategic skill to support organizations of every type, whether commercial, government, or not-for-profit, and of every size from a vast multinational alliance all the way down to a small one-person business. Although an enterprise-architecture may start out with an emphasis on IT, it must eventually encompass every aspect of the entire enterprise, regardless of its size, type, industry, or context. This book provides a focus on enterprise-architecture as a business capability to support the quality and effectiveness of change in the enterprise, much like other whole-of-organization quality-capabilities that support health and safety, sustainability, security, and suchlike. We show how to create and use enterprise-architecture to address the needs of any type of change, and how to extend the capability, competence, and maturity of architecture practice in a step-by-step way. We focus on what needs to be done, and the skills to be added, in what order, and why it needs to be done in that way, to support the real business concerns to be addressed at each level of architecture maturity. This revised edition of the book provides a new emphasis on effectiveness, and on context-neutral methods that work the same way everywhere, for every scope and scale, with every type of content and context, at every stage of the change-process, and for every type of lifecycle and timescale. We show how to use these methods to work with specific needs for particular industries, frameworks, technologies, and governance. We’ve added many new graphics and illustrations, and now use an airport as our consistent worked-example throughout the book, to show how architecture works in real-world practice. For the Maturity-Model that underpins the whole book, we’ve
Page
12
xii updated the model’s structure to highlight the underlying dependencies that drive its development of architecture-capability, and expanded our description of architecture- method into a standalone “Foundations” section, as a “Step Zero” that needs to be addressed before tackling the architecture itself. Whatever your enterprise, this book will show you what to do for its architecture, when and how and why, to make it all work in practice. Who Should Read This Book? This book is for enterprise-architects, strategists, change-managers, and others tasked with guiding change that can affect the enterprise as a whole. In particular, this book is for you if you now know that you must expand the role of your enterprise- architecture, from architectures for enterprise-IT to a whole-of-enterprise scope – a literal “the architecture of the enterprise.” This book will provide you with guidance on essential “missing pieces” in current enterprise-architecture practice, and help you break free from the arbitrary assumptions about enterprise-architecture that constrain the role, scope, and business-value of your architecture-work. Previous experience in enterprise-architecture or solution-architecture will be useful, but not essential. Readers with practical experience at an intermediate to advanced level are likely to gain the most value, but the book does also provide broader general guidance that will be relevant for newcomers to the discipline. The book would also be useful for business architects, process architects, security architects, solution architects, software architects, and others working in architecture- related roles, and also as an introduction to what enterprise-architects do, and why they do it. How to Use This Book This book deals with one specific practical concern: what you need to do when doing enterprise-architecture, to deliver real value to the enterprise as a whole. Our aim has been to provide you with a compact and easy-to-use reference that you would keep at your desk, to revisit often and to guide you in your architecture development and practice over the years. To support that aim, there are four main parts to this book. InTroduCTIon
Page
13
xiii The first chapter provides an overview of the business role of enterprise- architecture as a discipline to support effectiveness across the enterprise as a whole. We explore where enterprise-architecture fits within the organization, and the key types of architecture practice. We also introduce the airport worked-example, and the Maturity-Model that we’ll use to guide the step-by-step development of capability and competence in the practice of enterprise-architecture. In the next six chapters, for the new Foundations step in the Maturity-Model, we show you how to develop the skills and practices needed to guide any type of change, for any level of complexity, in any type of organization. This includes advice on methods for architecture governance, how to establish repositories for documents and more, and how to embed industry-specific frameworks and standards into the practice. We then take you through five distinct steps, each described in its own self- contained chapter, to enable your architecture to tackle increasing scope, scale, and levels of complexity in your own organization. Each step in development of maturity adds new capabilities to the architecture: • Step 1: How to identify the core business-context and to set up the architecture practice • Step 2: How to establish the key infrastructure and internal services • Step 3: How to bring the organization’s services to its market • Step 4: How to address real-world complexities and challenges • Step 5: How to tackle unexpected disruption and large-scale change In the final main chapter of the book, we show you how to engage others in the work, because ultimately architecture is not just for experts, but is everyone’s responsibility. Each of these chapters includes practical questions and checklists, and an “Into Practice” section and summary at the end of that chapter. Use these to help you develop your skills in your own work-context, and to guide you and others in the work. The book ends with a summary of the themes covered in the text, and an option for you to review what you have learned from applying the “Into Practice” sections at the end of each chapter. Throughout the book, we provide worked-examples and real-life experiences to illustrate each theme and provide real-world context. There is also a glossary at the end of the book, together with pointers to books and other resources that can provide you with any further detail you might need. InTroduCTIon
Page
14
1 © Tom Graves and Slade Beard 2025 T. Graves and S. Beard, Doing Enterprise-Architecture, https://doi.org/10.1007/979-8-8688-1757-1_1 CHAPTER 1 The Quest for Effectiveness How do we make our organizations more effective? How do we help our organizations get better at achieving their desired outcomes in a fast-changing world? And before that, how do we get better at identifying what “effective” and “better” and “desired-outcomes” will mean in our own business-context? Finding the right answers to those questions could well make the difference between business failure and business success. This is where enterprise-architecture comes into the picture. Working alongside strategy and change-management, it provides a consistent means to link structure, story, and purpose together across every aspect of the enterprise as a whole. All of this can be summarized in a single motto: Things work better when they work together, on purpose. If we think of effectiveness as a quality-concern, much like safety, security, and sustainability, then enterprise-architecture provides tools, disciplines, and professional practices to ensure that every change in the enterprise is “a change for the better,” always
Page
15
2 guiding the enterprise toward greater effectiveness, no matter how much the world may change around it. The aim of this book is to support you, as an enterprise-architect, in building the disciplines and capabilities that you will need in improving effectiveness across your enterprise, in a world with ever-increasing levels of complexity, uncertainty, and speed of change. Note as you’ll see in a moment, what we’ll explore with you in this book is enterprise-architecture, as a literal “the architecture of the enterprise.” If you’re a newcomer to enterprise-architecture, or looking at it from elsewhere in the organization, the idea of enterprise-architecture as “the architecture of the enterprise” should seem straightforward enough. We’ve aimed to keep technical jargon to a minimum, so that you can use these disciplines in whatever aspects of your organization you may need to address. but if you’ve been working in the discipline for a while, you may be more used to the idea that it’s primarily about the architecture of the enterprise-IT, with everything else as secondary to that focus. If that’s the case for you, the fact that we don’t focus so much as usual on the IT may seem a bit strange at first, maybe even challenging or “wrong.” If so, please don’t worry about that. Instead, for you, think of this as a “conversion-course” to fill in the gaps and expand the scope of your work onward into business-architecture and beyond, all the way out to the enterprise as a whole, connecting everything together all the way. There’s a lot to explore here: maybe challenging, at times, yes; but it’ll also make your work in enterprise-architecture a lot more exciting and worthwhile too. The Architecture of the Enterprise Throughout this book, we’ll use the enterprise of an airport as our worked-example. As can be seen in the header-graphic at the start of this chapter, there’s a lot going on out there. Some of the things we’d see would include ChapTer 1 The QuesT for effeCTIveness
Page
16
3 • Passenger-terminal • Freight terminal • Runways and taxiways • Aircraft and other vehicles of many different types • Connections to road and rail Down at the detail-level, there’s much, much more. And there are flows of people, things, information, and more, too, changes of so many different kinds, all of it happening in many different ways, at different scales, in different places, and over different periods of time. As enterprise-architects, it’s our task to help people make sense of all of that complexity, and make the choices needed to keep everything working together, better, on-purpose. To do that, though, we must first consider the scope that we’ll need for our enterprise-architecture. As shown in Figure 1-1, most current enterprise-architecture methods and frameworks are set up to focus mainly on IT: • “Business-architecture,” the business-context for IT • “Information-systems architecture,” including IT-based processes, applications, and data • “Infrastructure-architecture,” including computers, networks, and other physical IT-hardware Figure 1-1. Scope of classic enterprise-architecture ChapTer 1 The QuesT for effeCTIveness
Page
17
4 That emphasis on enterprise-IT will deliver real value: no doubt about that. Yet for the enterprise of the airport, we’re going to need an architecture of the enterprise itself, as a unified whole. If we focus only on one single theme in that enterprise, such as its IT, and then all but ignore everything else, we risk fragmenting the overall architecture, leading to point-solutions that break up the unity of the enterprise as a whole, and destroy overall effectiveness. To avert that kind of risk, we need a whole- of- enterprise architecture that is able to cover a much broader scope, as shown in Figure 1-2. Figure 1-2. Scope of whole-enterprise-architecture For example, the airport’s architecture will need to include • Its IT and other internal services to address each type of transaction, direct-interaction, and indirect-interaction • Its transactions such as passenger check-in, security-screening, departure, arrival, baggage-handling, passenger-information, and waiting-areas on landside and airside, and all of the equivalents on the freight-handling side of the airport ChapTer 1 The QuesT for effeCTIveness
Page
18
5 • Its direct-interactions with recruiters, equipment-manufacturers, service-providers, regulators, and more • Its indirect-interactions with other stakeholders in the overall enterprise, such as employees’ families, local communities, and government as a whole In short, in a whole-enterprise-architecture, we develop an architecture for an organization such as our airport, about everything within the shared-enterprise that provides its broader context. An Architecture for Enterprise-Architecture What kind of architecture would we need for that whole-enterprise-architecture itself? How would it work? What kind of structure would it need: its principles, frameworks, methods, and so on? To answer that, let’s look at the airport in a bit more detail. From a business-architecture perspective, the airport has a very complex multi-way business-model. For example: • Its customer-types include passengers, non-traveling visitors, freight- handlers, airlines, and more. • Its other partner-types include fuel-providers, maintenance- providers, and retailers on both landside and airside who provide food and other services to passengers and visitors, and also pay rent to the airport. From a regulatory-architecture perspective, the airport has a very complex regulatory-environment. For example: • On the boundaries between landside and airside, the airport must verify safe-and-legal-to-send and safe-and-legal-to-receive for each passenger and flight-crew member, each item of baggage, and each item of freight. • The airport must ensure health-and-safety throughout the entire airport, with varying regulations applying to different places. ChapTer 1 The QuesT for effeCTIveness
Page
19
6 From a security-architecture perspective, the airport has a complex security environment. For example: • The airport must ensure human-security, such as access-control, policing, and on-the-spot health-services. • The airport must ensure physical-security, such as preventing items of baggage and freight from being lost, stolen, or sent to or received from the wrong flight. • The airport must ensure its information-security, such as verifying that passengers receive the correct information about flights, locations, schedules, and delays, and also preventing data-loss, data- disruption, data-misrouting, and data-breach. • The airport must ensure biosecurity, such as verifying that passengers do not enter or leave airside with potentially-hazardous plants, fruit, animals, food, and other biosecurity-risks. From a complexity-architecture perspective, the airport is subject to a wide variety of sources for potential disruption. For example: • Passengers, visitors, flight-crew, and/or staff may fall ill or be injured, either in-flight or within the airport itself. • Security-incidents may require closure of part or all of the airport, for any length of time. • Flights may be moved to a different gate, be delayed either on arrival or departure, be canceled, arrive at the wrong airport, or never arrive at all. • Weather may cause delays, cancellations, or other disruptions. In reality, each of those lists goes on and on, seemingly to infinity at times. There are plenty of other perspectives through which we could view the airport, each with their own near-infinite list of issues. Each of those issues can combine with any of the other issues, sometimes cascading onward throughout the enterprise in unexpected ways. And all of this is changing, all of the time, in different ways, in different places, at different timescales and more. ChapTer 1 The QuesT for effeCTIveness
Page
20
7 As enterprise-architects, it’s our job to help others make sense of all of this complexity, and help them make decisions and take actions that will guide the whole enterprise toward ever-greater effectiveness. How do we do that? Classic IT-oriented enterprise-architecture gives us a good start for this. It shows us how to think architecturally, and how to use architecture frameworks, methods, tools, and checklists. It shows us how to guide architecture-driven change, from simple change-projects to large-scale business-transformations. Yet at the whole-enterprise level, there’s much more that we’ll need to address: • It’s about more than just IT: We must be able to address every type of content that may be present within the overall enterprise. • It’s about more than just a predictable world: We must be able to address both planned and unplanned change. • It’s about more than just project-delivery: An architecture-task is fully complete only when we have finished the after-action review, and documented its benefits-realized, lessons-learned, and future actions-for-change. • It’s about more than just the “happy-path”: We must be able to address all types of events in the context, including exceptions, uniqueness-issues, failure-conditions, business-continuity and disaster recovery, load-balancing, and more. • It’s about more than just a single change: We must be able to address interdependencies, interoperability issues, gaps and overlaps between contexts, cross-context synergies, whole-of-context interactions, systems-of-systems or enterprise-of-enterprises issues, across each change, and across the enterprise as a whole. • It’s about more than just a single project or business-transformation: We must be able to address complete lifecycles for each type of content in the enterprise, and use our longer-term sustain- architectures to connect the work of change-projects across all of those timescales. ChapTer 1 The QuesT for effeCTIveness
The above is a preview of the first 20 pages. Register to read the complete e-book.
AI Reading Assistant
Whole-book reading guide from stratified index samples; jump to passages in the text
AI guide
【One-Line Pitch】
A practical field guide for enterprise architects who need to turn architecture from a diagramming exercise into a repeatable, dependency-driven capability that delivers provable business value—read this if you want a step-by-step maturity model rather than another framework catalogue.
【Book Arc】
- **Opening (~0%–10%)**: Frames the core problem—what enterprise architecture should actually do, in what sequence, and for what business purpose—and introduces the dependency-driven maturity model as the organizing spine of the whole book.
- **Early (~10%–30%)**: Builds the foundations of change: how to make sense of any kind of change (planned or unplanned), the "art and science" of working with complexity and uncertainty, and the CSPAR pattern (Context, Scope, Plan, Action, Review) as a context-neutral change pattern.
- **Middle (~30%–55%)**: Deepens the Change-Layers model into practical sub-layers—from abstract interaction models through logical, physical, deployment, and action models—and introduces the Change-Cycle and fractal "same-and-different" thinking needed to connect across domains.
- **Late (~55%–85%)**: (Excerpts do not cover this range in detail.) Presumably develops the maturity-model stages and the skills/leadership needed to progress through them.
- **Ending (~85%–100%)**: (Excerpts do not cover this range.) Likely addresses proving business value and sustaining architecture practice over time.
【Key Takeaways】
- **Architecture must start anywhere and cover everything** (Opening): The book insists on a literal "architecture of the enterprise" spanning people, machines, IT, and more—methods must work at every scope, scale, timescale, and stage of change, not just for IT projects.
- **Dependencies drive the maturity roadmap** (Opening): Rather than adopting a maturity model wholesale, you derive your own sequence from dependencies—starting with a consistent capability for change, then building incrementally so each step is a genuine step-change in maturity.
- **CSPAR is the universal change pattern** (Early): Context, Scope, Plan, Action, Review works as both a vertical completeness checklist (Change-Layers) and a cyclical process (Change-Cycle), applicable from a multi-year transformation down to checking a boarding pass.
- **Different modes suit different phases of work** (Early): The Analyst mode (facts, measurement, logic, time-to-think) is for planning and verification, not real-time action; the book warns against blurring modes—e.g., emotional attachment to "facts" signals a discipline breakdown.
- **Fractal "same-and-different" frameworks are non-negotiable** (Middle): Context-neutral sameness connects everything; context-specific difference handles industry needs; without fractal thinking, whole-enterprise architecture collapses into fragmented mini-frameworks.
- **Plan work progresses through layered models** (Middle): From abstract Interaction-Model (P.1) to implementation-neutral logical model (P.2), physical/development model (P.3), deployment model (P.4), and action model (P.5)—each layer adding detail while staying aligned with Context and Scope.
- **Shortcuts in stakeholder work cost more later** (Early): Rushing interviews, ignoring conflicts, or limiting stakeholders to "important people" misses information that returns to bite you—allow the work the time it needs.
- **Real-world urgency validates the method** (Early): The COVID travel-agency example—a new CRM designed, built, and running in ten days—shows the approach is meant for fast response to emergencies, not just planned change.
【Reading Tips】
- **Deep-read the foundations (Chapters 1–4)**: The CSPAR pattern and the modes of change are the conceptual load-bearing walls; everything later builds on them.
- **Use CSPAR as a working checklist immediately**: Pick a live project task and run it through Context/Scope/Plan/Action/Review—the book explicitly invites this practice.
- **Skim the layered-model detail (P.1–P.5) on first pass**: Return to it when you actually need to produce interaction, logical, or deployment models; it is reference material as much as narrative.
- **Watch for the fractal-thinking sections**: They are the hardest conceptual shift and the most commonly skipped—budget extra time there.
- **Keep it at your desk**: The authors designed it as a compact reference to revisit over years, not a one-time read.
【Coverage Limits】
The excerpts cover the opening through roughly the middle of the book (foundations, CSPAR, Change-Layers, Change-Cycle, fractals); the later maturity-model stages, skills/leadership content, and business-value proof are not represented, so this guide cannot assess them.
Passage locations
Excerpt 1
ied upon to achieve desired, effective business outcomes. This book is for : Enterprise Architects. Doing Enterprise- Architecture A Maturity-Model Guide to...
View in text
Excerpt 2
ed through connections of cause and effect. It responds to the context through a sense of outer truth, measuring, monitoring, and assessing the factors that...
View in text
Excerpt 3
ked at different types of relationships between tasks, and how to connect content- and context-specific methods and tools into that context- neutral core. We...
View in text
Excerpt 4
f mini-frameworks for small specific issues such as event- logging and issue-tracking that have to be addressed in isolation even though they recur in many d...
View in text
Recommended for You
{{#thumbnailUrl}}
{{/thumbnailUrl}}
{{^thumbnailUrl}}
{{/thumbnailUrl}}
Loading recommended books...
Failed to load, please try again later
Tip the Site
Scan the WeChat Pay or Alipay code to tip. No login required.
WeChat Pay
Alipay