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®.

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 method
• Tailored architecture content (deliverables and artifacts)
• Architecture principles, including business principles
• Configured 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.

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.

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® if you have not used it or read about it before because all of the information you need for that is already available online. The ArchiMate® 3.1 Specification is easy to navigate, online, and free to all content that is published by The Open Group®, the same publisher of TOGAF®: https://pubs.opengroup.org/architecture/archimate3-doc/.

Architects are free, of course, to use any modeling language they are familiar with to build their artifacts, such as the Unified Modeling Language (UML), System Modeling Language (SysML), Business Process Modeling Notation (BPMN), Data Flow Diagrams (DFDs), and Entity Relationship Diagrams (ERD).

Each of these modeling languages is good for a specific set of artifacts but you will start to struggle when trying to mix elements from different architecture layers within the same view, which is what EA is all about.

Let's see why ArchiMate® is preferable over the other modeling languages for developing EA artifacts.

ArchiMate®'s role in EA artifacts

If you are modeling for the purpose of software development only, then UML and SysML would be ideal, and people have used them for years. However, if you are developing EA artifacts, you may need to model strategy and motivation elements along with the software components, which can be a bit difficult to do without some workarounds. The same thing is true when you chose BPMN for modeling business processes. BPMN is a familiar notation for most business and IT stakeholders, which makes it the default choice for modeling business processes. However, you cannot use it to model software or hardware components, or to model data structures and object relationships.

This is where ArchiMate® comes to the scene and is gradually becoming the choice for many enterprise architects. With ArchiMate®, you can have elements from the Technology Architecture layer (a node, for example) serving an element from the Application Architecture layer (an application component, for example), which serves a component from the Business Architecture layer (a business service, for example), which realizes an element from the Motivation Layer (a goal, for example), all in one diagram. There is no other modeling language than ArchiMate® that can handle this mixture in one place:

Figure 1.2 – An ArchiMate® example showing elements from different layers

To be fair, with UML, you can extend the basic UML elements such as the classes and the components using stereotypes to get any EA element you need. In the preceding example, you could have used a class with the <<goal>> stereotype, a class with a <<business service>> stereotype, a component with the <<application component>> stereotype, and a component with the <<technology component>> stereotype, respectively.

You must, however, limit the list of stereotypes that you will use to the elements that you have defined in your metamodel to avoid having too many stereotypes and losing the meaning of elements' identification and classification. Additionally, you need to make sure that you consistently follow the same spelling for stereotypes. You are free to use <<application component>>, <<ApplicationComponent>>, <<Application Component>>, or any other way you prefer, but you must stick to the same within the entire EA repository or else you will end up having multiple different classes representing the same type of elements. This is where metamodels become very handy because you can always refer to them to check which format you used. The following diagram shows how you can model the same information in the previous ArchiMate® diagram using UML and stereotypes:

Figure 1.3 – An example of EA artifacts modeled using UML

Notice that UML does not have the support relationship, so we must replace it with the dependency relationship and change its direction. The preceding diagram can now be read as the goal is realized by a business service, which depends on an application component, which depends on a node (or a technology component).

Tip

Always keep UML as a possible option in your mind for modeling EA artifacts as many organizations prefer to use it instead of introducing a new modeling language such as ArchiMate®. A new modeling language will require additional change management efforts that will be translated to additional investment in time and money.

The good news is that everything you will learn from this book can be done with UML. I have built more EA repositories using UML than with ArchiMate®, so it is a quite common and acceptable approach.

Understanding ArchiMate® modeling specification

The ArchiMate® specification has been defined in multiple versions by The Open Group® but the latest is version 3.1 and it is the one that we will be following. We will not repeat the information that is available online, but we will use some of the elements in more detail and we will map them to TOGAF®'s artifacts. In this section, we will cover the following:

• ArchiMate® 3.1 element hierarchy
• Elements color theme
• ArchiMate® modeling notation

Let's explore in more detail each one of them.

Exploring ArchiMate® 3.1 element hierarchy

ArchiMate® categorizes elements into two main categories regardless of the layer: structural and behavioral. Structural elements are the elements describing objects and entities; therefore, they are also known as nouns. Structural elements can be subdivided into active and passive. Active structural elements are the ones that perform the actions while passive structural elements are what actions are performed on. This makes application components, for example, active structural elements while data objects are passive structural.

Active structural elements can be further subdivided into internal and external elements based on how exposed they are to the surrounding environment. An application component can be accessed only through an application interface, for example. Whether the interface is a User Interface (UI) or an Application Programming Interface (API), actors must use interfaces to communicate with components.

Behavioral elements describe the actions that structural elements can perform, so you can think of them as the verbs that nouns can perform on other nouns. Behavioral elements can also be subdivided into internal and external elements. Internal behaviors, such as processes, describe how the structural elements get the job done. External behaviors, such as services, describe to the external environment what the structural elements provide to them.

Confused? Do not worry because this part was meant to help you in reading the official ArchiMate® metamodels, which we will replace with a much easier-to-read metamodel, so please be patient. Just explore the following diagram, which summarizes the hierarchy of ArchiMate® 3.1 elements, but you do not have to remember any of it for now:

Figure 1.4 – The hierarchy of ArchiMate® 3.1 core elements

The layers and the elements in the preceding diagram are known as the core elements. There are additional layers and elements, but our focus will be on the core elements, which we will use most of the time. We will explore other non-core elements as we need them.

Exploring elements color theme

There is no strict color theme that ArchiMate® forces architects to follow, so you are free to follow any coloring theme or simply make everything in black and white as long you consistently follow the same practice in all your diagrams. If you chose blue, for example, for application layer elements, then it's a good idea to stick to the exact same shade of blue in all the diagrams throughout the entire repository. Using the same color for elements that belong to different architecture layers can be confusing. You can also use black and white for everything to avoid complicating the rules for you and/or your team.

Also keep in mind that some regulations may require using specific color codes and some regulations restrict the usage of colors to differentiate between objects, so make sure that you comply with the regulations of the region you live in.

As a result, it is better to use the named ready-made colors instead of creating custom colors that require remembering their RGB codes every time you use them. Your metamodels can also tell the colors of the elements that need to be followed across the repository.

Note

If you are reading a printed copy of this book, then some diagrams will be in grayscale. For full-color versions of these diagrams, please refer to the graphic bundle available here: https://static.packt-cdn.com/downloads/9781801076166_ColorImages.pdf.

ArchiMate®'s online documentation consistently uses yellow for business, blue for application, and green for technology layer elements. The entire shapes are filled with the proper colors surrounded by black borders:

Figure 1.5 – The color theme of ArchiMate®'s online content

We will follow a similar coloring theme in this book, but we will fill the elements with white and apply the colors to the borders. We will also use orange for business elements instead of yellow for better visibility:

Figure 1.6 – The color theme of this book

The color names of the preceding are defined in Sparx as follows:

• Orange (RBG 255, 165, 0); will be used for all Business Architecture elements
• Royal Blue (RBG 65, 105, 225); will be used for all Application Architecture elements
• Dark Green (RGB 0, 100, 0); will be used for all Technology Architecture elements

As mentioned earlier, it is up to you to decide what colors to use as long as you and other EA team members remain consistent with your choice.

Introducing ArchiMate®'s modeling notations

ArchiMate® provides two notations to represent each type of element. As you can see in Figure 1.7, one uses rectangular shapes with small icons in the top-right corner of the rectangle (Rectangular Notation), and the other uses large versions of the icons without the rectangular borders (Borderless Notation). ArchiMate® uses shapes rather than textual stereotypes to visually differentiate elements, which can be confusing at the beginning until you get used to all the different shapes.

Have a look at the following diagram and notice the differences between the two notation styles. The top row uses the rectangular notation to model an application interface, an application component, and an application function, respectively. The small icons in the top-right corner of each rectangle represent the type of element. The bottom row uses the borderless notation to model the same three elements we mentioned previously in the same order.

Figure 1.7 – ArchiMate®'s two notations

There is no difference at all between the two notations; it is just a matter of preference. You can switch between the two styles in Sparx by simply right-clicking on the shape and checking or unchecking Advanced > Use Rectangle Notation from the context menu. The captions will always be inside the rectangular shapes, while they may get placed outside the borderless shapes for some elements. If you are modeling a composition relationship, you can do this by placing one element inside the other, and the container element will be the whole or the parent and the contained element will be the part or the child. In the composition scenario, I recommend using the rectangular notation for the container to have more space inside.

In general, avoid using the two notation styles in the same diagram for the same element type as this will confuse your audience. For example, do not use the rectangular notation to represent some application interfaces and use the borderless notation to represent some other application interfaces on the same diagram because this will indicate that there is a difference between the two. We will explore the two different notations as we go, and we will use one style in some diagrams and use the other style in some other diagrams but will never mix the two in a single diagram.

Metamodels

ArchiMate® has extended TOGAF®'s metamodel by adding more elements and more relationships. But unlike TOGAF®'s metamodel, where all the elements and relationships are displayed in a single diagram, ArchiMate®'s metamodel is divided down into smaller but closely related metamodels, so there is a metamodel for the motivation layer, a metamodel for the business architecture layer, a metamodel for the application architecture layer, and so on. The reason – I believe – is to avoid having a big, busy diagram that is difficult to understand.

Important Note

Please refer to Figure 30-5 from TOGAF® 9.2 for the core content metamodel, and Figure 30-7 for the full content metamodel (https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap30.html). You need to make yourself familiar with how TOGAF® and ArchiMate®'s metamodels are defined and how can you interpret them as this is an essential step for applying the standards to ensure that the architecture content is in full alignment with the framework.

In this section, we will talk about the following:

• ArchiMate® 3.1 metamodels
• ArchiMate® taxonomy

The following subsections provide more details for each.

ArchiMate® 3.1 metamodels

ArchiMate® metamodels are written in a very abstracted way in order to provide wider coverage of enterprise elements in a smaller space. They contain elements such as the Application Internal Behavior Element to represent all descendant elements, rather than putting each of them on the diagram and complicating it with intersecting relationships. Check this ArchiMate® metamodel online to be able to follow my explanation: https://pubs.opengroup.org/architecture/archimate3-doc/chap09.html#_Toc10045390.

As you can see, the metamodel tells you a lot of things that can help you when you are modeling application layer components, and they have tried to make it as compact as possible. If you want to model an application component, for example, the metamodel will tell you what other elements can connect to or be in a relationship with your component.

As you can see, there is no application component in the diagram but the more generic class, the Application Internal Active Structure Element class, which can be confusing for those who are new to ArchiMate®. It tells us that application components can be assigned to an application internal behavior element, which can be translated to the application component that can execute the application process.

It will take you some time to be able to quickly interpret the ArchiMate® metamodels, but the good news is that we will be presenting metamodels differently and easily throughout this book.

The ArchiMate® taxonomy

Since ArchiMate® and TOGAF® are published by the same organization, you're better off thinking of ArchiMate®'s taxonomy as an extension of TOGAF®'s taxonomy rather than two different ones. The definitions of the two are very similar and in many cases, they are exactly the same. But because TOGAF® is more generic and ArchiMate® is more detailed, you may find that a single definition in TOGAF® has multiple specific definitions based on the architecture layer they belong to. For example, TOGAF® has a single definition for process, while ArchiMate® has three layer-specific definitions for it: business process, application process, and technology process.

We will include both definitions when introducing new elements and will try to add more elaborate descriptions supported with examples to clarify them. Some definitions are written in a difficult-to-understand language, so we will try to simplify that. Definitions will be quoted as is from the sources and will always be in italics to be easily differentiated from the rest of the text. The following is an example of the definition of a business process:

A business process represents a sequence of business behaviors that achieves a specific result such as a defined set of products or business services (ArchiMate® 3.1: https://pubs.opengroup.org/architecture/archimate3-doc/chap08.html#_Toc10045374).

Any additional elaboration and supportive examples will usually come in the paragraph following the definition, like this paragraph.

The next section will introduce Sparx Systems Enterprise Architect as our tool of choice for modeling EA artifacts.

Introducing our focused metamodels

Reading about and understanding the ArchiMate® metamodels can make the difference between a true architectural artifact and any other diagram. But as you saw, it is not a straightforward step to get the information you want. I used to use paper and pen to decipher the metamodels into something that I can use in my models. When it comes to connecting to elements from other layers, you must refer to the metamodels that define the cross-layer relationships to get the bigger picture.

Since this book is all about making things more practical, we are providing you with metamodels that are focused on one element at a time. The following diagram represents the application component-focused metamodel and I bet it looks way easier to read and understand than the standard ArchiMate® metamodel:

Figure 1.8 – Application component-focused metamodel

You can immediately tell that an application component can be assigned to an application function, application process, and application service. It can compose application interfaces and can compose other application components as well. We will cover in more detail all the components that are included in the focused metamodel.

Following a metamodel is essential in unifying the EA artifacts that are developed by different architects. They are the blueprints for developing models, and without them, each diagram will look different and be inconsistent. You do not have to include all the elements that are shown in the focused metamodels in every model you develop. It is a reference that shows every relationship possibility, so you take only the ones you need.

Additionally, do not forget that we are following an agile way of implementing EA, so we do not have to develop all the focused metamodels before we start modeling as this is a waterfall approach. As we start following the example scenarios in Section 2 and Section 3 of this book, we will build only the metamodels that we will need. Even if we do not cover every element in the ArchiMate® specification, you should be able to build the metamodels for the remaining ones and populate your own EA repository in the same way that we will be practicing.

Sparx Systems Enterprise Architect – known as Sparx – is a modeling tool that has evolved over the years from just UML modeling in the early 2000s to a tool that can today model almost everything, including modern AWS and Azure diagrams. Note that this book is not sponsored by Sparx Systems and not affiliated with any of their partners; we have chosen Sparx for multiple reasons that will be explained in the next subsection, and we will have a first look at the components of its UI in the subsection after that.

Why Sparx?

Using an EA tool is not mandatory to establish an EA office or build an architecture repository, but it makes things easier, more efficient, and better governed. If you or your organization are not using an EA tool, I highly advise you to do so unless you are still in the early discovery phases.

If you have not used Sparx before, you can download a trial copy now and get familiar with the different components of the UI, as well as getting used to the way of creating diagrams. Sparx Systems has a huge library of resources that can help you learn their product and become an expert in it. It will be extremely helpful to explore the fundamental materials provided at this location before you proceed with the book (https://sparxsystems.com/resources/user-guides/15.2/index.html).

If you use a different tool other than Sparx, you will still be able to apply all the concepts that will be provided in this book in your tool of choice. The concepts can be applied using any tool, but we will be focusing on Sparx only. The reasons that we have chosen Sparx can be summarized as follows:

• Low cost of ownership
• Direct download and free trial
• Widely known

Let's explore each one of these advantages in more detail.

Low cost of ownership

Sparx is a tool that anyone can purchase without massively hurting their pockets. If you are studying and practicing at your own cost, you can get Sparx up and running for as little as $229. Most other EA tools cost an average of $10,000 per user per license, so you can see how huge the difference is. If you work for an organization that does not want to put a big investment in an EA tool, either due to budget constraints or to lower the risk involved with practicing EA, then Sparx is an excellent tool to start with. Once the architecture maturity of your organization increases, you can choose to migrate to a more sophisticated and more expensive tool if needed.

Please check the Sparx Systems website (https://sparxsystems.com/) for an up-to-date price list and to learn more about the different licenses they offer. For the record, I am using the corporate license for this book, so every diagram you will see in this book – and many more – can be done with it.

Direct download and free trial

If you want to explore Sparx, you do not have to go through a long procurement process where you fill out a form with your information, submit it, and wait for the marketing team to call you back, ask you more questions, schedule a demo, and make a purchase order before putting your hands on their tool. With Sparx, all you need is to register your email address and you will be provided with a link to download a fully functional, 30-day trial copy of the EA tool. If you do not like it, no one will keep bugging you with sales emails and phone calls; just simply uninstall it. If you like it, pay for the license online, enter the provided license key, and your trial version will become a licensed version. Everything that you have practiced so far will still be there for you.

Widely known

Because of the previous reasons, Sparx is a very well-known tool in the market and almost every architect has used it or heard of it. Throughout my career of EA implementation, Sparx has been the tool that more than 40% of my clients have used, about 10% used other tools, and the rest were not using EA tools at all. You can do an internet search for EA tools and see what is currently available on the market.

Having talked about why we're using Sparx, let's explore the main areas of its UI and get ourselves familiar with it.

The Sparx UI

This section will give you a very quick overview of the Sparx UI. The following figure shows you the sections of the Sparx UI followed by a brief description of each. We have used version 15.2 of Sparx in this book, so if you are using a different version, you may see some differences between what is in this book and what is on your screen.

Figure 1.9 – The Sparx UI showing the main sections

As you can see in the figure, there are four main areas of the Sparx UI:

• The Diagram Area
• The Project Browser
• The Ribbon Bar
• The Toolbox

Note that the project browser area has multiple tabs (currently showing the Browser and Inspector tabs), and the Toolbox area has multiple tabs too (currently showing Toolbox and Properties). These tabs can be docked to any side of the screen, so you can drag the Toolbox tab, for example, to fit within the same area that the project browser fits. In fact, you can fit all the tabs on one side of the screen and have more space for diagrams in the middle. It is all up to your preferences.

Let's explore each of these main areas now.

The Diagram Area

The diagram area is where your diagrams get created and designed. There is nothing much to say about this area right now, but this is the area where the actual work is done, so we will learn more about it as we progress. Right-clicking on the diagram background will bring a context pop-up menu. Click Properties and the diagram properties window will be displayed:

Figure 1.10 – The diagram properties window

Please make yourself familiar with the different tabs and options and refer to the online material whenever needed by clicking on the Help command button or pressing F1 on the keyboard. You do not have to remember every screen option now, but just explore what is there.

Project Browser

This area displays your resources in the form of packages and elements. Think of the Windows filesystem, for example; the packages are like folders and elements are like files. In a nutshell, everything in Sparx is either an element or a package. Diagrams are elements, and all the shapes that you place on them are elements too.

Unlike in visual modeling tools such as Microsoft Visio and Lucidchart, in EA modeling tools including Sparx, you create an actual element for every shape you put on the diagram, so the shape is not only a visual item but an actual element that lives inside your repository. Take a second look at Figure 1.9 and you will notice that for every element that we have placed on the diagram, there is a representation of the same element in the project browser, including an element for the diagram itself. This is an essential concept in EA modeling because if you want to show multiple views (that is, diagrams) for the same element, then you have to reuse the element from the project browser, rather than creating a new element from the toolbox. If you find this confusing, do not worry now as we will practice many examples that show you when to create an element from the Toolbox and when to reuse it from the project browser.

Explore the properties window for any elements by highlighting the element and right-clicking it, then choosing Properties from the context menu. You will notice that it is the same window for all elements regardless of their type:

Figure 1.11 – Element properties window

Explore the different tabs and options and make yourself familiar with them. Refer to the online documentation if you need help.

The Ribbon Bar

Sparx has Microsoft Office-like toolbars with large icons and menu options. Some ribbons are for configuring the Sparx environment, some are for alignments and layouts, some are for publishing and exporting, and other options. The following figure shows four sample menus, but you need to refer to the Sparx online user guides for the complete documentation of all the options and actions they provide. We will only talk about the ones that we will use, so not every menu option will be covered:

Figure 1.12 – Four sample toolbars from the Sparx ribbon bar

Notice how some menu items have a small arrow indicating that clicking on them will open a drop-down list of options. Also notice that menu items that perform similar functions are grouped within groups. The Start toolbar, for example, has four groups: Explore, Desktop, Collaborate, and Help. Throughout the book, we will follow this pattern to guide you on which menu item to select: Toolbar Name > Group > Menu Item > Menu Sub-Item, which is the same style that Sparx uses in the online material. For example, if you need to adjust the Z-order of an element and bring it to the top, I will ask you to click Layout > Alignment > Bring to Top, which makes it easier for you to find that option than just saying "Click on the Bring to Top menu item."

Toolbox

The toolbox has dynamic content, and it changes according to the type of the diagram. The toolbox that you see in Figure 1.9 is the one associated with diagrams of the ArchiMate® application diagram type. You can change to different content by clicking on the hamburger menu (the menu that has a stack of three horizontal lines) on the top-right side of the toolbox and changing to different content, as shown in Figure 1.13:

Figure 1.13 – Changing the Toolbox content

As we have advised for other areas on the UI, if you need to explore the Toolbox area, use Help if needed and get yourself familiar with it.

Important Note

Drag items from the toolbox to the diagram area to create new items in the repository. Drag items from the Project Explorer to the diagram area to reuse an existing element.

This was a lot of information to put in one chapter, but more details will come as we practice putting this information into useful artifacts.

In this chapter, we have laid the foundations of the structure of the book and introduced the core concepts that we will address in the remaining chapters. This will have helped you to understand the benefits of implementing an industry-standard framework such as TOGAF® but without forgetting that nothing comes without problems and that things can go wrong as well. You should have realized the importance of bringing the agile mindset to the EA world without losing the big picture. We have also chosen ArchiMate® as the modeling language and Sparx Enterprise Architect as the modeling tool that we will use to build an EA repository.

In the next chapter, we will introduce three fictional scenarios to get hands-on with realistic problems that you as an enterprise architect will face or may have already faced.