Practical Model-Driven Enterprise Architecture E-Book

Mudar Bahri

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 454

Veröffentlichungsjahr: 2022

Beschreibung

Most organizations face challenges in defining and achieving evolved enterprise architecture practices, which can be a very lengthy process even if implemented correctly. Developers, for example, can build better solutions only if they receive the necessary design information from architects, and decision-makers can make appropriate changes within the organization only if they know the implications of doing so.
The book starts by addressing the problems faced by enterprise architecture practitioners and provides solutions based on an agile approach to enterprise architecture, using ArchiMate® 3.1 as an industry standard and Sparx EA as the modeling tool. You'll learn with the help of a fictional organization that has three business units, each expecting something different from you as the enterprise architect. You'll build the practice, satisfy the different requirements of each business unit, and share the knowledge with others so they can follow your steps. Toward the end, you'll learn how to put the diagrams and the content that you have developed into documents, presentations, and web pages that can be published and shared with any stakeholder.
By the end of this book, you'll be able to build a functional enterprise architecture practice that supports every part of your organization. You'll also have developed the necessary skills to populate your enterprise architecture repository with references and artifacts.

Leseprobe

Practical Model-Driven Enterprise Architecture

Design a mature enterprise architecture repository using Sparx Systems Enterprise Architect and ArchiMate® 3.1

Mudar Bahri

Joe Williams

BIRMINGHAM—MUMBAI

Practical Model-Driven Enterprise Architecture

Copyright © 2022 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Associate Group Product Manager: Richa Tripathi

Publishing Product Manager: Shweta Bairoliya

Senior Editor: Nisha Cleetus

Content Development Editor: Rosal Colaco

Technical Editor: Pradeep Sahu

Copy Editor: Safis Editing

Project Coordinator: Manisha Singh

Proofreader: Safis Editing

Indexer: Pratik Shirodkar

Production Designer: Prashant Ghare

Marketing Coordinator: Deepak Kumar

First published: April 2022

Production reference: 1250422

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80107-616-6

www.packt.com

To my mother – thank you for your prayers. To my children, Samer, Lina, and Lara – believe in yourselves!

– Mudar Bahri

To my wife, Robin – you are the love of my life. To my son, Ryan, and daughter, Kayla, because I'm so proud of you both. To my grandson, Ethan, because I adore you.

– Joe Williams

Contributors

About the authors

Mudar Bahri is an enterprise architect with long, progressive experience in implementing TOGAF® in large and midsized organizations. He is an independent Enterprise Architecture (EA) mentor and consultant and helps architects to build and develop practical EA skills that can provide decision-makers with useful artifacts. He is a certified TOGAF® 9.1 Enterprise Architect with experience in other EA frameworks and project management methodologies. He has used TOGAF® to develop digital transformation strategies, cloud migration plans, solution architectures, and proposals. He believes that EA is meant to bridge gaps, not create new ones, so it has to be simple, practical, and serve everyone.

I want to thank the people who have been close to me and supported me, especially my brother, Tameem Bahri, who inspired me to start writing.

Joe Williams has over 40 years of experience in software engineering and architecture on many platforms and spanning several business domains, including retail, banking, health insurance, telecommunications, environment monitoring, and government systems. He holds a BS degree in information systems from the University of San Francisco and is a TOGAF® 9.1 certified practitioner. Joe preaches the practice of modeling every chance he gets. He is an expert in the Unified Modeling Language (UML) and has helped establish architecture practices at several organizations. He has been modeling solutions using Sparx Systems Enterprise Architect since 2007 and other modeling tools since 1995. He is currently retired and living in northern California.

I want to thank my co-author, Mudar, for asking me to help write this book, and my wife, Robin, for encouraging me to do so.

About the reviewer

Kris Marshall is a results-driven chief enterprise architect with over 20 years of accomplishments in information technology leadership, enterprise architecture, learning technologies (artificial intelligence and machine learning), and organizational transformation. Kris has extensive experience with business strategy development (for over 35 public and private organizations) and defines business and solution architectures in support of those strategies, aligning organizational goals and the IT infrastructure that support them.

As a doctoral graduate of Pepperdine University, Kris' research focuses on enterprise architecture theory and the intersectionality of learning technologies. Kris presently supports numerous university research labs and participates in research groups at Pepperdine University, MIT, and Singularity University.

Table of Contents

Preface

Section 1: Enterprise Architecture with Sparx Enterprise Architect

Chapter 1: Enterprise Architecture and Its Practicality

Understanding TOGAF®

TOGAF® implementation benefits

TOGAF® implementation drawbacks

Introducing agile EA

Understanding agile EA?

Comparing agile EA with EA

Embedding agile EA into TOGAF®

Introducing ArchiMate®

ArchiMate®'s role in EA artifacts

Understanding ArchiMate® modeling specification

Metamodels

Introducing our focused metamodels

Introducing Sparx Systems Enterprise Architect

Why Sparx?

The Sparx UI

Summary

Chapter 2: Introducing the Practice Scenarios

Structuring the book around the scenarios

A brief on ABC Trading

The structure of the book

First scenario – application architecture

Scenario description

Artifacts backlog

Second scenario – technology architecture

Scenario description

Artifacts backlog

Third scenario – business architecture

Scenario description

Artifacts backlog

Summary

Section 2: Building the Enterprise Architecture Repository

Chapter 3: Kick-Starting Your Enterprise Architecture Repository

Technical requirements

Building the application component context diagram

Establishing your first diagram

Creating the repository file

Creating the diagram

Describing the diagram

Changing the diagram theme

Adding elements to the diagram

Starting with the application component

Introducing application services

Adding Actors

Identifying other dependent elements

Summary

Chapter 4: Maintaining Quality and Consistency in the Repository

Technical requirements

Building the application component focused metamodel

Establishing the metamodel diagram

Interpreting an ArchiMate® metamodel

Adding elements from other architecture layers

Modeling best practices

Keeping your diagram focused

Fitting your diagram onto a single page

Adding only the necessary information

Paying attention to your diagram's appearance

Knowing your audience

Summary

Chapter 5: Advanced Application Architecture Modeling

Technical requirements

Determining what diagrams to produce

Understanding the view

Structural and behavioral views

Getting to know the viewpoint

Describing application behavior

Introducing application services

Introducing application processes

Introducing application functions

Introducing application interactions

Introducing application events

Describing application structure

Revisiting the application component

Introducing application interfaces

Introducing application collaborations

Introducing data objects

Summary

Chapter 6: Modeling in the Technology Layer

Technical requirements

Modeling technology environments

Examples of technology models

Diagram filters and layers

Technology stacks

Interpreting the standard

Using the node element

Using the device element

Using the system software element

Using the technology interface element

Using the technology collaboration element

Using the technology artifact element

Modeling physical environments

Understanding the equipment element

Understanding the facility element

Understanding the distribution network element

Understanding the material element

Understanding the location element

Putting the elements together for ABC Trading

Modeling dependencies in ArchiMate® 3.1

Modeling networks

The communication network element

Communication network-focused metamodel

The path element

Path element-focused metamodel

Summary

Chapter 7: Enterprise-Level Technology Architecture Models

Technical requirements

Using technology behavioral elements

Using the Technology Service element

Using the Technology Function element

Using the technology process

Using the technology interaction element

Using the Technology Event element

ABC Trading's technology background

Building the technology components catalog

Defining the technology components catalog

Collecting the information

Formatting the CSV file

Importing the CSV file into Sparx

Equipment and system software

Modeling technology services

Identifying existing services

Mapping services to technology components

Using the matrix feature

Reporting our findings

The diagram option

The report option

Summary

Chapter 8: Business Architecture Models

Technical requirements

Modeling the business structure

Defining business actors

Defining business roles

Defining business collaboration

Defining business interfaces

Defining business objects

Modeling business behavior

Defining business services

Defining business processes

Defining business functions

Defining business interactions

Defining business events

Summary

Chapter 9: Modeling Strategy and Implementation

Technical requirements

Introducing strategy elements

Defining capabilities

Value streams

Defining resources

Courses of action

Modeling the ABC Trading strategy

Introducing implementation elements

Defining plateaus

Defining gaps

Defining work packages

Defining deliverables

Defining implementation events

Summary

Section 3: Managing the Repository

Chapter 10: Operating the EA Repository

Technical requirements

Sharing repositories

Organizing and reorganizing the repository

Model abstraction

Model replication

Version management

Sandboxes

Element status

Managing the shared repository

Configuration management

Implementing security

Model locks

Deleting and merging elements

Backup and restore

Automation

Repository governance

Architecture governance

Repository governance

Summary

Chapter 11: Publishing Model Content

Technical requirements

Generating document reports

Introducing report templates

Future-proofing your templates

Template fragments

Including diagrams in your report

Document options

Excluding packages and diagrams from a document

Creating more complex documents

Generating HTML content

Using charts

Creating custom SQL queries

The copy-and-paste approach

Summary

Other Books You May Enjoy

Preface

Enterprise Architecture (EA) is a discipline that promises to bridge the gaps between business and IT by defining the components of an enterprise and also the relationships among these components. With the increased dependency of businesses of all domains on technology, many organizations want to adopt EA, and most professionals want to be part of this adoption process. However, following a discipline at the entire enterprise level can be full of obstacles because it requires dealing with many people with different interests. This is where most EA practitioners struggle, and they are perceived as theoretical people who are disconnected from reality; as a result, many organizations lose interest in EA.

In our opinion, the lack of delivering tangible and useful EA artifacts is the main reason for EA implementation struggles. This book introduces sample artifacts on each element in an enterprise so that you are able to address the different needs of different stakeholders. A collection of EA artifacts forms an EA repository, so this book will teach you how to build a repository and maintain its content. It will also teach you how to build a reference library that you and your EA team can use to maintain consistency within the EA repository.

We chose ArchiMate® 3.1 to build these artifacts, but you can use any other modeling notation that works within your workplace. We also chose Sparx Systems' Enterprise Architect software as the tool to build and develop these EA artifacts, but you're also free to use any other tool that you are familiar with. The goal is to deliver value, regardless of the tool that you prefer to use.

Who this book is for

This book is for enterprise architects who are charged with influencing the business, technology, and applications of an organization. The authors are influenced by TOGAF®. Whether you work on the business, applications, data, or technology layer, or all of them, this book covers examples that you'll be able to apply in your work. Experience in EA frameworks, especially TOGAF®, is beneficial, but not required. Although not necessary, familiarity with modeling with Sparx Systems Enterprise Architect using any modeling language will be helpful. No prior knowledge of ArchiMate® is required to get started with this book.

What this book covers

Chapter 1, Enterprise Architecture and Its Practicality, starts by highlighting what made TOGAF® the de facto standard for implementing EA and puts the spotlight on the problems that most TOGAF® practitioners face – some (if not all) of which we are quite sure you will have faced. In this chapter, we will talk about the problems, the proposed solutions, and the tool that will be used for this purpose.

Chapter 2, Introducing the Practice Scenarios, introduces the three scenarios that will be used to make this book practical and connected to real-life examples. The company that we will talk about is a fictional company, which we will name ABC Trading, but it can represent any company that you have or will be working for. The purpose of the scenarios is to make up simple and generic stories that can fit within your real-life work environment, even if your organization is working in a different business domain. The scenarios will be detailed enough and as close as possible to problems that you have faced or will face as an EA.

Chapter 3, Kick-Starting Your Enterprise Architecture Repository, helps you create your first diagram instruction by instruction to get you familiar with Sparx. By doing so, you will be introduced to some techniques at different levels of expertise that you may find useful, even if you have used Sparx before.

Chapter 4, Maintaining Quality and Consistency in the Repository, helps you learn how to use the ArchiMate® 3.1 standard as a reference by putting it in a simple and easy-to-understand way. Therefore, architects contributing to the content of the repository will enjoy following the standard, which will be reflected in the quality and consistency of their artifacts.

Chapter 5, Advanced Application Architecture Modeling, helps you learn how to enrich the EA repository with additional artifacts from the application architecture layer. You will learn more advanced skills in Sparx and ArchiMate® to build an EA repository that can be trusted within your organization.

Chapter 6, Modeling in the Technology Layer, introduces you to the structural elements of the technology layer and how they are related to other layers. We will learn how to model technical, physical, and network environments. We will also learn different ways to represent technical constructs and how to move from more abstract to more concrete representations.

Chapter 7, Enterprise-Level Technology Architecture Models, introduces behavioral elements and how to use them. We will learn how to import information from other sources and model and organize technical services in order to answer enterprise-wide questions. We will generate our first report and analyze our findings.

Chapter 8, Business Architecture Models, helps you answer business questions, such as what a business provides to the world, how it achieves it, how an organization is structured, who is responsible for what, and how these business architecture elements are automated and realized by elements from the application and technology layers.

Chapter 9, Modeling Strategy and Implementation, helps you learn how to utilize the power of business capability models to identify the gaps between what we are capable of doing now and what we are targeting to do in the future. Once the gaps are defined, you will need to put a plan for bridging them within a timeline.

Chapter 10, Operating the EA Repository, helps you learn how to add formality and organization to the process of making changes to the enterprise repository. The more content you have and the more architects add and remove content to and from the repository, the more challenging it becomes to keep it organized and up to date.

Chapter 11, Publishing Model Content, helps you learn how to put diagrams and content that you have developed in the previous chapters into documents, presentations, or web pages that can be shared with other stakeholders who do not have experience with Sparx or a license to use it.

To get the most out of this book

Here are the technical requirements for this book:

If you are using the digital version of this book, we advise you to type the code yourself or access the code from the book's GitHub repository (a link is available in the next section). Doing so will help you avoid any potential errors related to the copying and pasting of code.

Portions of this text are reprinted and reproduced in electronic form from The Open Group® ArchiMate® 3.1 Specification with permission granted by The Open Group®, L.L.C. In the event of any discrepancy between text and the official standard, the official standard found at https://www.opengroup.org/library/c197 remains the authoritative version for all purposes. ©The Open Group. All rights reserved.

Download the example repository files

You can download the example EA repository files for this book from GitHub at https://github.com/PacktPublishing/Practical-Model-Driven-Enterprise-Architecture. If there's an update to these files, they will be updated in the GitHub repository.

We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!

Download the color images

We also provide a PDF file that has color images of the screenshots and diagrams used in this book. You can download it here: https://static.packt-cdn.com/downloads/9781801076166_ColorImages.pdf.

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: "Create a new ArchiMate® 3.1 application diagram in the Metamodels package and name it Application Process Focused Metamodel."

Bold: Indicates a new term, an important word, or words that you see onscreen. For instance, words in menus or dialog boxes appear in bold. Here is an example: "Right-click on the Manipulate Device Location Data application process element."

Tips or Important Notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you've read Practical Model-Driven Enterprise Architecture, we'd love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we're delivering excellent quality content.

Section 1: Enterprise Architecture with Sparx Enterprise Architect

This section briefly introduces Enterprise Architecture (EA) and TOGAF®, and explains why this book can be of value to you and how we have structured it to be easy to follow.

This section addresses the problems that are faced by EA practitioners and introduces you to the methodology, the modeling notation, and the modeling tool that will be used as components of a solution. It addresses why some organizations have lost interest in EA, but more importantly, it introduces solutions to regain business trust in it again.

Since this book is mainly concerned with making EA practical, we will introduce three fictional problem scenarios that can guide you to create useful artifacts and show some tangible values of EA in your workplace.

This section comprises the following chapters:

Chapter 1, Enterprise Architecture and Its PracticalityChapter 2, Introducing the Practice Scenarios

Chapter 1: Enterprise Architecture and Its Practicality

Enterprise Architecture (EA) is a discipline that many organizations have adopted or have been motivated to adopt over the last two decades or so due to its promises to bridge the gaps between business and technology. EA is the art of defining and categorizing the elements that compose an enterprise and defining the relationships among these elements to get useful information that supports making strategic and tactical decisions. There are several frameworks that guide EA implementation, but the most popular one is TOGAF®.

This chapter starts by highlighting what made TOGAF® the de facto standard for implementing EA and puts the spotlight on the problems that most TOGAF® practitioners face – some (if not all) of which I am quite sure you will have faced. As I have learned, talking about problems is never helpful without providing solutions, so we will introduce a hands-on approach that has been extracted from years of practical experience in the EA domain to help you in aligning the theory with the practice smoothly and more productively.

Please remember that this book is not about teaching TOGAF®; I expect that you already have some knowledge of and experience with the framework and are looking for solutions to the problems that you may have already faced. It is also not about making comparisons between TOGAF® and other frameworks to show the advantages versus disadvantages of each. This book is based on TOGAF® and ArchiMate® only and will explain how to use them in a way that can help your organization to get quick, tangible outcomes from adopting them.

The following is a list of topics that will be covered in this chapter:

Understanding TOGAF®Introducing agile EA Introducing ArchiMate®Introducing Sparx Systems Enterprise Architect

Let's start by talking about the benefits and drawbacks of TOGAF®.

Understanding TOGAF®

Even though TOGAF® came nearly two decades after the Zachman Framework (https://www.zachman.com/about-the-zachman-framework) was introduced, it dominated the market very quickly and became one of the most important standards in the EA domain. John Zachman was the first to introduce the concept of EA in the mid-eighties and defined an EA framework carrying his name. For many reasons, the Zachman Framework was not adopted by many architects, but the idea remained in many people's minds.

TOGAF® started to gain popularity in late 2002 when The Open Group® introduced version 8.0. From there onward, it continued to gain popularity and started to become the de facto standard in the EA domain especially when The Open Group® released version 9.0 in early 2009, followed by 9.1, and finally 9.2 in 2018. TOGAF® became popular because it provided enterprise architects with rich content that guides their development journeys and makes implementing EA achievable.

Architects chose to follow TOGAF® for many reasons, which we will talk about later in this section. However, implementing TOGAF® was not a straightforward journey for many, and it brought new challenges and difficulties to the architects. As a result, many EA projects ended up with massive scope creep, unneeded outcomes, and useless acronyms. Therefore, many EA projects got terminated due to low return on investment and more people lost faith in EA as a practical approach even with TOGAF®. In this section, we will talk about the following:

The benefits of using TOGAF® as a framework for implementing EA projects The drawbacks that make implementing TOGAF® challenging

While you read this section, I am sure that you will recall similar situations that you or your team have faced in your EA implementation journey.

TOGAF® implementation benefits

The following features are some advantages that made TOGAF® the preferred choice over other frameworks for many architects:

Complete online documentation that is freely available.An easy-to-follow process.It fits architects with different experience.A rich content metamodel.It's loaded with guidelines and techniques.It encourages learning.

We will look at each benefit individually in the following subsections and see why more than 111,000 individuals from over 144 countries have chosen to use TOGAF® and be certified in it (according to https://togaf9-cert.opengroup.org/certified-individuals on the date of writing this paragraph).

Complete online documentation that is freely available

The Open Group® has provided all the TOGAF® versions online and for free with anonymous access. This makes it possible for people at all levels of experience to explore, read, and learn the framework at their own pace without feeling constrained by costly subscriptions or time-limited trials. You do not even need to register on the website to be granted access to the content, which is something that not all frameworks provide. Some frameworks require paid memberships, and some require at least creating a profile, but this is not the case with TOGAF®. EA practitioners also find it very convenient to have the material online and accessible anytime, anywhere, and on any device.

Note

Even after being TOGAF® certified for years and practicing it continuously for about 15 years, I always have the website bookmarked in my browser.

An easy-to-follow process

One of the core TOGAF® components is the Architecture Development Method (ADM), which is a series of phases, each with a defined set of inputs, steps, and outputs. Architects find it easy to follow the ADM, especially architects coming from an IT background. They all know that if you want to build a solution, you need to first envision it, define its requirements, plan it, design it, build it, deploy it, and then operate it, which is very well known as the System Development Life Cycle (SDLC). The ADM has a similar concept to the SDLC, but the objective is to architect the entire enterprise and not a single IT solution.

The following diagram represents the ADM cycle as defined by TOGAF® here: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap04.html, using ArchiMate® 3.1 notation:

Figure 1.1 – An ArchiMate® representation of the ADM cycle (The Open Group®)

As you can see, the ADM cycle starts with the Preliminary Phase, which establishes the EA practice and formalizes the choice of tools and methodology. It is then followed by eight iterative phases that cover one part of the enterprise at a time.

It fits architects with different experience

Architects coming from different backgrounds and with different experience can all find something useful in TOGAF® that they can use in their area of expertise. Solution architects who have TOGAF® experience will have a better understanding of a business and be able to provide it with the right solutions that address its requirements and strategic directions. A second example would be project managers with TOGAF® experience, who will find it easy to upgrade their project management skills to program and portfolio management because understanding TOGAF® helps them understand how the enterprise works and how to have a holistic view of the different moving parts. IT operations managers with TOGAF® experience can use its Technical Reference Model (TRM) to categorize and classify the technology stack in their organizations using an industry-standard method, which helps them make the right decisions.

The list of examples can include every single member within the enterprise, so TOGAF® is an extremely useful and flexible framework that offers something for every practitioner, and each person will benefit from it differently.

A rich content metamodel

The metamodel provides architects with a foundation that tells them what the components of the enterprise are and how they are related to each other.

The TOGAF® metamodel, along with the taxonomy, provides architects with a better understanding so that they can describe the enterprise with consistency even if they look from different perspectives. Classifying and categorizing the elements and relationships of the enterprise is the heart and soul of EA. Here is the full TOGAF® 9.2 content metamodel: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap30.html#tag_30_03.

Additionally, TOGAF® provides a taxonomy and definition for all the keywords that architects use, which helps in unifying the language among different architects and makes their communications and documentation easier. People from different backgrounds can still argue the meanings of these definitions based on their interpretations but having a taxonomy can dramatically reduce these arguments. The Open Group® has even extended the TOGAF® taxonomy through ArchiMate®, which makes the combination of the two a complete and detailed set.

Important Note

This book will use the taxonomy defined by The Open Group® in both the TOGAF® 9.2 and ArchiMate® 3.1 materials as they are and will elaborate more for greater clarity.

It's loaded with guidelines and techniques

TOGAF® has tried to address all the issues that enterprise architects may encounter during their implementation engagements. It provides a set of useful tools, materials, and techniques, such as the following:

A set of principles that enterprise architects can start with and modify as needed.Stakeholder management techniques and a proposed set of artifacts that can be of interest to different stakeholders.Patterns and techniques to segment and control the scope and size of the EA practice.A high-level governance model that can fit any size organization and team.A general structure of the EA content repository that can be scaled up or down as needed.

The complete list of guidelines and techniques is too long to be covered in this book and you may have already experienced some or all of them. Please refer to https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap17.html if you want to learn more about them.

It encourages learning

With more people showing an interest in TOGAF®, The Open Group® wanted to encourage practitioners to be distinguished by becoming certified in the framework. With the increasing demand for experienced enterprise architects, becoming TOGAF® certified is a desire and sometimes a requirement by employers when hiring or contracting.

Just like anything good in life, the benefits of the framework come with a cost, which can outweigh the benefits if not handled with care. After having a quick look at the benefits of using TOGAF®, let's review some of the drawbacks that can be associated with TOGAF® implementations.

TOGAF® implementation drawbacks

Even with all the materials that TOGAF® offers, not every implementation project ends as planned, if it ends at all. Some EA implementations end up delivering something different than what was originally planned, some end up in a massive scope creep that overwhelms the project with infinite tasks and activities, and some remain within the drawers of the EA team until the sponsors decide to pull the plug.

In this section, we will highlight the things that may contribute to these results, and will provide you with some example traps that some architects may have fallen into; you may have witnessed or experienced some of them during your EA journey:

The ADM is a giant waterfall process.The lack of practicality.High cost-to-value ratio. TOGAF® is mostly adopted by IT people.

Let's look at each of these in more detail in the following subsections.

The ADM is a giant waterfall process

As mentioned earlier, the ADM is a major factor in the success of TOGAF®. However, ADM is a sequence of phases, which turns out to be a waterfall method by nature. Therefore, TOGAF® provided a chapter explaining how to use the ADM iteratively (https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap18.html), and another chapter on Architecture Partitioning to help keep the scope of work under control by dividing it into smaller partitions (https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap36.html). Even with these techniques, there is still huge room for making scope mistakes because following a phased approach can end up with one phase requiring completion before starting the next. Attempting to finish a phase with all the details, inputs, steps, and outputs that are defined in the ADM can leave you and your team with an infinite set of tasks to do.

Note

Please keep in mind that I am talking from practical experience and how I have seen things ending up in most cases. The problem is not in TOGAF® itself, but with the wrong interpretation by the practitioners of how many details need to be defined for each ADM phase.

For example, in the ADM, architects start with the Preliminary Phase, which has an objective to define and establish the detailed processes and resources for Architecture Governance (https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap05.html). Having this objective is understandable because, without governance, no project will be completed.

Establishing the Architecture Governance Board (AGB), which is the governance body that approves or rejects changes to the architecture, and defining their roles and responsibilities, their job descriptions, the governance processes, and the key performance indicators can take anywhere between a single day and 6 months, which is what I like to call the Effort Blackhole. This refers to a situation in which all the effort that you and your team put into finishing the phase will never end and there will always be the need for more.

Additionally, having this objective in the Preliminary Phase before the project is officially started makes it difficult for stakeholders and governance board members to understand how to govern something that does not yet exist. They can outline some processes and assign responsibilities, but that must start at a high level, then they'd need to get details as the organization's architecture maturity level increases. They may easily end up spending their time defining and refining these processes because it is not clear yet what to govern. The Effort Blackhole starts to form when the EA lead insists that all tasks in the Preliminary Phase must be completed before moving on to the next phase.

Another example is also in the Preliminary Phase of the ADM, which defines a tailored architecture framework as one of its outputs. A tailored architecture framework includes the following:

A tailored architecture methodTailored architecture content (deliverables and artifacts)Architecture principles, including business principlesConfigured and deployed tools

That is according to section 5.4 in Chapter 5 in the TOGAF® online documentation (https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap05.html). If this statement is not handled properly by the lead enterprise architect, it can result in a massive scope creep that can keep the entire team of architects busy for months in tailoring the architecture framework they plan to use. The EA team can easily end up building a new EA framework instead of following TOGAF® to deliver EA artifacts, that is, being trapped in another Effort Blackhole.

The last example I will mention in this context is in phase B (Business Architecture), which takes Business Principles, Business Goals, and Business Drivers as inputs (https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap07.html). These elements can usually be found in the organization strategy, and if they are not, the architecture team will find themselves busy redefining (or just refining in the best case) the organization strategy, which is a project by itself and can lead to another massive scope creep and distraction to the team from their main EA objectives.

The lack of practicality

Another big problem that enterprise architects deal with when they plan to follow and implement TOGAF® is the lack of practical examples and document templates to use. Most frameworks impart theoretical information only to remain as generic and as neutral as possible. This leaves architects with huge gaps between the theory and the practice and in some cases, they deliver documents and presentations that are very theoretical and disconnected from the real world. This situation makes stakeholders perceive the EA office as the ivory tower office, indicating its disconnect from reality.

TOGAF® is full of terminologies that are either all new to many stakeholders or are defined slightly differently from other standards. For example, the definitions of object and service according to TOGAF® – and ArchiMate® – are a bit different from how Object Management Group (OMG) defines these two keywords. This usually confuses the stakeholders and results in the enterprise architects communicating using a language that no one else understands and delivering presentations that no one gets.

High cost-to-value ratio

Enterprise architects usually charge high rates and EA projects take long periods of time before anyone sees tangible deliverables, especially if done in a waterfall approach. According to the Glassdoor careers website, the average annual salary of an enterprise architect is about $110,000 in the United States (https://www.glassdoor.com/Salaries/enterprise-architect-salary-SRCH_KO0,20.htm). This number is an average and can go up to $220,000 per year for a senior director enterprise architect position according to the same source. If you have a team of four working in your EA office, that will cost your organization nearly $1 million per year if we consider the additional benefits and cost overheads. Additionally, most EA tools are very costly to procure with average license prices of around $10,000 per user (we will talk about EA tools later in this chapter).

Taking into consideration all the aforementioned points, the outcomes of EA projects can be bulky documents that are expensive, theoretical, boring to read, difficult to understand, and do not help in resolving any of the ongoing issues. The decision-makers find it difficult most of the time to justify huge EA investments for the relatively small added value.

TOGAF® is mostly adopted by IT people

Even though EA is an enterprise-level practice and aims to align business and IT within the organization, the reality is that it has mostly been adopted by IT people. This by itself is not an issue because life is full of examples of people who succeeded in different careers and people who quickly gained the required skills and expertise in new domains. IT professionals have always proven that they can lead the trending wave even if it is not just for IT – project management and EA are two examples of that.

The real issue is that IT enterprise architects kept focusing on IT operation and software development, and for them, every deliverable or artifact must serve as an IT solution. You can see this very clearly when browsing the job descriptions of enterprise architect positions on any recruitment website. You will see that most of the offered positions are titled enterprise architect, but the description is mainly looking for deep software development and programming skills or core network operations skills. This usually ends up with EA as a subdivision under the IT unit and the enterprise architect reporting to the IT manager or the Chief Technology Officer (CTO) in the best-case scenario. EA in this case will be limited to IT and will fail to achieve the most important goal it is established for, which is bridging the gaps between business and IT and aligning IT to business strategies.

After having this quick overview of TOGAF®, highlighting its benefits and drawbacks, it is time to introduce a solution that utilizes all of the benefits keeping you away from the drawbacks.

Introducing agile EA

To start with, being agile in practice does not necessarily mean that we will follow any of the agile software development methodologies, such as Scrum or eXtreme Programming (XP). Being agile simply means being adaptive to the continuous changes to the requirements within your enterprise and being responsive with the right amount of information, at the right time, to the right people.

Another important point to keep in mind is we are not introducing a new methodology that is better or worse than TOGAF®, and we are not following the Open Agile Architecture™ either (https://pubs.opengroup.org/architecture/o-aa-standard/index.html). We are still following TOGAF®; it will still guide our progress and we will be reusing more of the framework's components, such as the taxonomy, metamodels, TOGAF®'s techniques and guidelines, and most of the ADM content. The main differences will be in the order of the ADM phases and steps.

This section will explain how EA can provide better value if implemented with agile principles in mind by focusing on delivering tangible and valuable artifacts that can grow as the work progresses. Before we go deeper into the approach, let's start by understanding what agile EA means.

Understanding agile EA?

Part of our proposed solution is to be agile in the EA practice and to focus on delivering products where they are needed the most. These products are called architectural artifacts within the context of EA, and they include all the diagrams, catalogs (dictionaries), and matrices (cross tables) that make the documents that are produced during an EA practice. I highly recommend that you read the 12 agile principles that are defined in the Agile Manifesto for your knowledge if you are not already familiar with them (https://agilemanifesto.org/) but replace every software word you see with artifact to see EA through agile eyes. The agile principles can be applied to any project in life, including personal ones, and not just on software development.

As an enterprise architect, people will expect you to provide them with advice and solutions everywhere in the enterprise. If they feel that you will slow their progress down or enforce things that they do not require, you will end up detaching yourself from the rest of the organization and will end up sitting alone in your ivory tower.

One main reason for EA failure in many organizations is that product owners overlook involving the EA office in their projects to avoid possible delays. Product owners want their products to be up and running as soon as possible. They will not feel comfortable adding tasks to their scope of work that they do not believe are needed just because the framework says so. They will not be happy if you ask them to hold their progress and wait until the EA office finishes tailoring the framework, defining value streams, and defining the governance model.

Defining – or even just refining – all these components can keep you and the rest of the team busy for months, if not years, and the product owner will soon perceive you as an obstacle and a risk to the project. It is a fact that you need to respect if you want to have a successful cooperative relationship with the rest of the enterprise.

Following a methodology is a way to do things right, no doubt about it. However, the product owners will not wait for you to finish tasks that they do not require and are not part of their project's scope of work. This is where you need to balance doing things right and doing the right things.

If the objective is to develop a new web application, for example, as an enterprise architect you must complete the full picture by connecting all the dots and making sure that the application realizes actual business services, and the application has – or will have – the required technology infrastructure that will support it. The key to being more practical than theoretical is setting up the scope and prioritizing your tasks to deliver useful artifacts within the available time.

Continuing with the web application example, it is more useful and more appreciated by the product owners if you start by conceptualizing the application services that they have in mind and help them to plan and design them. Once you have the desired artifacts, you can add more content to them and/or develop other artifacts that are based on them. You will keep using TOGAF® and its material as a reference for the big picture, but you do not have to start from the top, and you do not have to complete each phase before you start the next one. That is the waterfall approach, which was deprecated from software development years ago and must be deprecated from EA development as well.

Comparing agile EA with EA

The idea of agile EA is not new, but in fact, it is as old as EA itself. John Zachman, the father of EA, introduced his framework in the mid-1980s and it is still known today as the Zachman Framework. Every EA practitioner or learner will have heard of it even though the number of Zachman Framework practitioners is far fewer than those of TOGAF®. The Zachman Framework is incredibly famous for its 6x6 matrix, which has What, How, Where, Who, When, and Why as columns, and has enterprise layers such as Scope Contexts, Business Concepts, System Logic, Technology Physics, Tool Components, and Operational Classes as rows (as defined in https://www.zachman.com/about-the-zachman-framework).

Unlike TOGAF®, the Zachman Framework has no specific process to follow, and architects are free to start anywhere they want on the matrix. Once they define the artifacts they need, they can simply go to any other cell on the matrix and build more artifacts. This is an agile approach that was introduced way before agile software development was even thought of. Architects can start with the process definition, for example, followed by responsibility configuration and then the inventory instantiation artifact without constraint. They can decide which artifacts to develop based on stakeholders' demands and requirements and the availability of information, rather than deciding based on a sequential flow of steps.

The big picture will be formed as you build more artifacts here and there and as more details and relationships are revealed, exactly like finding and fitting the pieces of a puzzle. Sometimes you will find that you have made some wrong assumptions based on the information that you had in hand at that time, and the artifact is incomplete or unclear, but this is a very acceptable side effect of agile development, and you need to keep in mind that nothing is written in stone and every artifact is subject to changes.

Sharing your artifacts continuously with the rest of the team and with the product owners as you gradually build them will help in communicating your thoughts in the early stages and will help you make the required corrections and adjustments as needed. Making continuous small changes and updates to the artifacts is better than going through a lengthy waterfall process and getting caught in Effort Blackholes.

Embedding agile EA into TOGAF®

As mentioned earlier, this book is based on TOGAF®, and the reason we talked briefly about Zachman in the previous section was to show that the agile way of EA development is not a strange idea or an extreme thought to be afraid of. In this section, we will show you how you can embed the agile mindset into TOGAF® without compromising the principles of the framework. These are the main elements of the agile EA approach:

The big picture will remain guided by TOGAF®.Start anywhere where EA contribution is required.Focus on delivering artifacts.Use smaller metamodels.Build the architecture governance as the architecture evolves.Use an EA tool for the architecture repository.

The following subsections will explain each of the preceding elements in more detail.

The big picture will remain guided by TOGAF®

Being agile and focusing on artifacts does not mean losing sight of the big picture. Everything that is in TOGAF® will still be used as guidance and this is how:

TOGAF®'s content metamodel will still be the big picture that shows the different elements within the enterprise and the possible relations between them. We will use ArchiMate®'s metamodel because its metamodels provide more details than the ones provided by TOGAF®, but both framework models have the same background.We will still use the taxonomy of TOGAF® and ArchiMate® as the formal definition of the enterprise elements. We may elaborate on some definitions if needed, but we will stick to the standard definitions all the time.We will still use the list of artifacts and the list of proposed inputs and outputs by TOGAF® as guidelines. We will still use TOGAF® for guiding the definition of our governance model but without forcing it. This means that not every role, process, or responsibility must be built upfront, but we take what we need and change as we progress.We will adapt and reuse any of the tools and techniques that are provided by TOGAF® and adjust them to our needs as we progress.

Start anywhere where EA contribution is required

As an enterprise architect, you need to contribute to every development progress for any business unit and at any layer of the enterprise. Whether it is a strategy-crafting initiative, a marketing campaign, a new software procurement, or a plan to retire some legacy mainframe applications, enterprise architects need to be involved in all these initiatives as they progress. They do not have to be the subject matter experts in all these different domains, but they need to add value to all these areas by encouraging the use of standards and connecting and aligning the different components in the different layers. Involving the enterprise architects in multiple projects at different locations of the enterprise can uncover some hidden relationships between these projects that only someone with EA eyes can see.

To demonstrate how enterprise architects can contribute to any layer with great value, let's take the mainframe application retirement as an example:

Retiring an application will affect the other applications that exchange data by taking the forms of inputs, outputs, or both. If not taken into consideration, this integration dependency may get broken and will result in unplanned errors or missing information.It will affect the infrastructure (the technology) that the application uses so either it becomes available for other applications, or it becomes useless and ready to be retired.It will affect the people operating, administrating, and using the application so either they will require training to be able to use the replacement application or they need to be reallocated and play different roles for the best use of resources.It will affect the business services that depend on the application in automating some or all of the processes. If multiple business services depend on the application, there will be a possibility of some of them going down or being interrupted due to the broken dependency.Having a service or services down may affect the organization's ability to achieve its strategic goals, which may by itself have effects on other elements in other layers because everything within the enterprise is connected.

Only enterprise architects can provide these dependency views, and this is one example of where they can add value to any project at any layer. We will talk more about this in detail in Chapter 8, Business Architecture Models.

Focus on delivering artifacts

One benefit of following an EA framework is to make deliverables and artifacts standardized, organized, consistent, and of higher quality. If the delivered artifacts are of no use to the stakeholders, then your efforts and their time will be wasted, something that EA has struggled with for years. Remember that any effort that does not have a deliverable is a wasted effort. There is the concept of delivering the Most Viable Product (MVP) in agile software development, having the minimum essential features delivered first, then the product keeps growing by adding more features to it. That concept must be followed during EA development as well and the product within the EA context is an artifact.

One of the recommendations in agile software development is to break down the tasks into smaller pieces or parts, and we will follow this in agile EA. Having a deliverable such as the Architecture Definition Document (ADD) that contains multiple smaller artifacts, such as the business processes catalog, business services catalog, application components catalog, business processes to application components matrix, application components to technology services matrix, and many other sections, it can take an exceedingly long time with all the different sections that it contains. So, instead of having a single task for developing the ADD, it is better to break it down into smaller artifacts that each can be completed within a few days or 2 weeks at most, or else they must be broken down into smaller parts that fit within the 2-week window.

If you have multiple engagements to participate in, then you need to distribute your time spent on all these engagements without affecting or slowing down the others. You can keep growing your artifacts simultaneously as you go, and you may discover some dependencies between the two that no one considered before.

Use smaller metamodels

Metamodels are the templates that architects use as references when creating EA artifacts to maintain the consistency and the quality of the artifacts across the EA repository. TOGAF® and ArchiMate® have generic metamodels that you can start with, but they do not cover every possible relationship and sometimes they are difficult to read and understand. Customizing the standard metamodels is recommended to fit the exact requirements of your organization; however, trying to tailor the entire TOGAF® and ArchiMate® metamodels can take a very long time. Following the same concept of breaking large artifacts down into smaller ones, you must break the effort of tailoring the metamodel down into smaller parts.

The next section of this chapter will introduce the concept of focused metamodels, which we will be following throughout the rest of the book, but for now, remember that creating metamodels is as important as creating the artifacts themselves. Even if you are the only architect who is building artifacts, having metamodels will help you maintain the required consistency within your own set of deliverables.

Build the architecture governance as the architecture evolves

Defining the architecture governance model is essential to ensure the proper development and maintenance of EA artifacts. With proper governance, every person involved in the architecture development and maintenance knows what to do to keep the artifacts updated. Being agile does not mean being chaotic and without processes or strategy. Building an architecture repository without a governance model around it will result in having most of the artifacts outdated or with broken relationships within a year at most. Outdated or incorrect information will break the trust between stakeholders and the information that the EA repository provides, so it must be avoided. Therefore, we know the importance of having an established architecture governance model but as with everything else, it must be broken down into smaller parts and we start with only the ones that we need for the MVP, then we enhance it by adding more to it.

Chapter 37 of TOGAF® 9.2 (https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap37.html) provides the concept of the EA repository, and Chapter 44 (https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap44.html) provides the concept of architecture governance. Both chapters represent the visionary big pictures that you can aim for. However, that concept can be too big and difficult to implement if you are just starting, so you need to build the governance MVP that can govern only what is being developed and avoid boiling the ocean. Attempting to boil the ocean will result in Effort Blackholes with no doubt. It is important to look at the big picture and know what is behind it, but it is more important to use your resources wisely. Chapter 10, Operating the EA Repository, of this book will provide you with a simple governance framework that can evolve as per the maturity of your organization.

Use an EA tool for the architecture repository

It is very possible to implement TOGAF® or any EA framework using Microsoft Office tools and hosting everything on a shared network drive. However, having an EA tool such as Sparx makes it easier and more practical to do so, especially if you are doing it in an agile way. Since agile is all about accepting changes even at later stages of development, doing that without a tool can be extremely difficult to maintain. The tool will let you know if you are changing an element that is connected to other elements, for example, which may break the established relationship. We will talk more about the EA tool that we will use to build the EA repository in the last section of this chapter. For now, you need to keep in mind that having an EA tool makes modifying the artifacts easier, which will help you do EA in an agile way.

Now you know the agile EA approach and the importance of building artifacts, it is time to introduce the modeling language that will be used for this purpose.

Introducing ArchiMate®

The ArchiMate® is a visual modeling language that is published by The Open Group® especially to be able to model and create EA artifacts. It is a complementary extension to TOGAF®, so it provides architects with an extended metamodel, extended taxonomy, and a visual modeling notation.

Important Note

It is highly advisable to get yourself familiar with ArchiMate®