Enterprise Architecture - the key concepts

One of the main reasons for needing Enterprise Architecture is the huge growth in our dependence on information, and the vast quantities of information that are now available to us. Individuals and enterprises all base their lives around the availability of information.

Enterprise Architecture provides some of the essential techniques that we need to manage this dependence. This lecture explains.

Life is getting more and more complex. Enterprises are getting more entwined and interconnected across the globe. This lecture explains why we need to add additional levels of enterprise architecture techniques as things get more complex.

Organizations are becoming bigger and bigger. And to meet their rapidly changing needs they typically have more and more change programs and projects. Every enterprise change means a change to its underlying architecture.

Not surprisingly, enterprise architecture has a range of techniques to coordinate change at the architectural level. These include stakeholder management; techniques that provide a big picture, holistic overview of the entire enterprise; techniques to balance concerns, examine trade-offs, and determine priorities; and techniques to ensure that change programs and projects contribute to a consistent, overall vector or direction.

This lecture explains the need to coordinate diverse changes through enterprise architecture.

This lecture provides a brief summary of some of the key reasons for needing Enterprise Architecture today.

It's important to understand what the word "enterprise" means, in order to fully understand what Enterprise Architecture is all about.

This lecture explains why it is called "enterprise" architecture.

Here is an Exercise to help you think about what "enterprise" means to you, or to your EA team. In the resources you will find a set of questions that you can download. These can be used as a checklist to think about what is within the scope of an "enterprise" - for a particular project, or for the general use of "enterprise" architecture for the enterprise that you work for.

Enterprise Architectures are divided into a number of domains. On completing this lecture you will understand the concept of domains, and be able to identify the domains that are needed in your EA initiatives. You will also understand the limitations of the TOGAF® domains, and know how to add two additional domains that remove this limitation.

Time is often wasted discussing whether it is necessary to have an enterprise architecture team within an enterprise. This is because the debate is focused on the wrong topic.

In actual fact, enterprise architecture isn't optional! This lecture explains why.

The resources include a link to a blog discussion on this topic, and to a typical list of the reasons given for justifying an EA team within an enterprise.

By changing the nature of the debate about enterprise architecture, we can switch the discussion to things that are more easily measured - to demonstrate the costs and disadvantages to not managing the enterprise architecture, and to distinguishing between a well-managed enterprise architecture and one that is less well managed.

Ultimately the important point is to have the EA management that is right for your enterprise!

This lecture explains in detail the measurements that can be used to check whether you have the right type of EA in place to meet the needs of your enterprise.

This lecture gives an analogy of gardening to show the options for managing an Enterprise Architecture.

This lecture provides the Key Learning Points about Why Enterprise Architecture Isn't Optional.

Architecture frameworks are vital tools for the enterprise architect. But there is a lot of confusion on the subject. At the end of this lecture you will have a clear idea of what an architecture framework is, why frameworks are so useful, and why you need to create and tailor frameworks that meet your exact needs - rather than rely on one that is already published.

Key learning points are that:

• Common definitions of architecture frameworks are dense & fail to emphasize their true value
• Frameworks are one of the most practical EA tools for thinking about & managing architectures

The external resources also give you three links that give you some useful background information about EA frameworks.

• The Zachman Framework was probably the original architecture framework, and its author - John Zachman - is still influential. His framework can be difficult to understand, but you should of its existence.
• The survey of architecture frameworks, on the ISO web site, is a useful summary of other architecture frameworks that exist. Again - you don't need to know all of them in detail, but you do need to know about some of the key ones.
• Finally the ISO 42010 provides the best standard definition of an Architecture Framework

This lecture explains why there are so many EA frameworks.

This lecture describes the simple steps for using an EA metaframework.

In this brief lecture I summarize the key points for the need to use an EA metaframework.

In this lecture I describe the eight fundamental factors that form the basis for all EA frameworks and approaches.

Enterprise Architecture is a unique discipline. Unfortunately, there are some misconceptions about what EA is, and what it is not. This lecture explains the unique qualities that define enterprise architecture.

When you have completed this lecture you will know ten things that make EA a distinct discipline, and you will be able to explain what each of these ten qualities covers. You will also be able to state clearly the things that EA is not!

Download the PDF summary of these ten unique characteristics of Enterprise Architecture.

This section has introduced a new way of thinking about Enterprise Architecture and why it is so necessary and useful in the modern world.

Here are some questions to check your understanding of the topics covered in this section. There are no "right" answers. The questions are simply intended to help you apply your new knowledge in the practical use of Enterprise Architecture.

An important skills in EA is being able to keep track of stakeholder concerns and requirements. In this lecture you will learn how to keep track of everyone's needs. You will understand the concepts of stakeholder, viewpoint and concern, and how they relate to one another. You will also learn how these concepts are based on the ISO 42010 standard. You will also learn about the most effective way to manage a large number of viewpoints.

The resources include a link to the ISO 42010 standard - which is the basis for this lecture.

In this lecture you will learn about the important distinction between concerns and architecture requirements.

You will also understand the architect role in turning concerns into well-documented architecture requirements.

In particular you will understand the need to explicitly show

• constraints or limitations
• how concerns can be resolved
• risks, costs, benefits, and future options

In this lecture you will learn how nearly everything in EA is a view, perceived from a viewpoint - it is therefore a very important concept to understand. You will also learn about the criteria for managing views, and how to manage a large number of views.

In the resources there is a link to the ArchiMate description of Architecture Viewpoints which is useful background reading on this subject.

This lecture provides a demonstration showing one way to manage viewpoints and views using a hierarchy. From it you can see a practical example of how to manage and use views in EA.

The phrase “Enterprise Architecture” has several meanings - in this lecture you will learn how to distinguish between Enterprise Architecture as a Thing, a Description, a Process, and a Discipline.

You will learn about Enterprise architecture as:

• A thing: the architecture of an enterprise
• A description: of the architecture and its components
• A process: how to go about architecting an enterprise
• And a discipline: the skills, expertise and experience needed to be an architect

In this lecture you will learn what we need to consider in order to create good architectural descriptions.

You will understand how describing components in an architecture requires a content framework to keep track of what has been described, how well it has been described, or how it is used and reused, and a metamodel to show how components relate to each other.

You will also be able to explain why a domain hierarchy is another useful tool.

At the end of the lecture you will see how we can create many architecture frameworks that refer to and reuse descriptions of architecture components.

It is very important that we present information about EA in the best possible ways. The right presentation makes a difference between successful EA, and failure.

In this lecture you will learn how you can improve the way you present architecture information. You will understand why a simple classification of artifacts is inadequate.You will see how a sophisticated list of presentation types improves communication with stakeholders.

The resources includes a useful download of some of the most useful presentation types found in successful EA practice.

In this lecture you will learn how EA Process is much more than simply Developing an Architecture.

You will learn how it also covers

• all aspects of EA governance
• integration with all other relevance enterprise processes
• and ongoing engagement with all stakeholders of the architecture in use

You will also understand how it covers the processes of applying relevant techniques.

You will also be able to explain how EA adds value to each process – throughout the strategy / execution life cycle.

In this lecture you will learn what skills the EA discipline needs. You will also learn how architects need to relate their skills to delivering value or handling organizational behaviors.

There is a link to a typical on-line Skills Framework in the resources.

Here are some questions to check that your understanding of the topics covered in this section. There are no "right" answers. The questions are designed to help you apply your knowledge in the practical use of enterprise architecture.

In the next few lectures you will learn about architecture domains and sub-domains and how are they used in domain analysis.

Although many of the common EA frameworks and approaches only describe four high-level domains, you will learn here that there are many other high-level and sub-domains. You will see how it is useful to manage domains & sub-domains as a hierarchy. You will also learn how architects need to position domains and sub-domains as layers or pillars within the enterprise architecture. Finally you will learn about the use of domains in the separation of concerns.

In this lecture I describe some of the common domains used in EA.

In this unit I will describe two different ways in which we present domains to show important architectural information.

This lecture explains how domains and sub-domains are configured into layers or pillars to form an enterprise architecture.

In this lecture I explain why we need to separate concerns in EA.

This unit provides a brief summary of the key points covered in the previous few lectures about Architecture Domains and domain analysis.

In this lecture you will learn why we separate concerns, and how we combine them again.

You will understand three main reasons why we need to separate concerns. You will also learn how architects use the Levels of Understanding to combine separated concerns to accommodate the needs of that level.

You will also learn the important distinction between:

• How to combine separated concerns using Architectural Composition
• How to use the lower levels of understanding using Architectural Deconstruction

In this lecture you will understand why the process of enterprise architecture is sometimes described as a ping pong process!

You will learn how:

• Flow through the architecture development is rarely straightforward, and never sequential
• Keeping track of artifacts produced, dependencies between projects, and sustaining a consistent architectural evolution is difficult
• A project to artifact framework keeps track of this ping-pong development process

In this lecture you will learn what a metamodel is, and how it is used in EA.

You will learn how:

• The building blocks of an enterprise architecture are described as components or constructs in an EA metamodel
• It is useful to divide the metamodel into distinct areas – these typically coincide with different domains

The metamodel is a really useful, highly practical, indispensable, EA tool, and this lecture will give you the basis for using it in your day-to-day EA work.

In the resources you will find links to publicly available metamodels that can be easily adapted to your EA needs.

In this lecture, and the following few lectures, you will learn about meta levels. You will understand the various meta levels that are used in EA, and the purpose of each level.

You will also learn how to apply the meta levels:

• To manage the complexity of the typical enterprise
• To integrate a diverse range of models
• To support modelling with tools and techniques
• To manage multiple viewpoints and views

In this lecture I give an example of how the meta levels are used in Enterprise Architecture.

This lecture explains how each meta layer models the layer below it.

This lecture explains the four main reasons why we need meta levels in Enterprise Architecture.

This lecture summarizes the key learning points from the previous lectures about the meta levels.

In this lecture you will learn how the EA metamodel allows us to accommodate multiple viewpoints and views.

You will also learn how a metametamodel is used to handle:

• Different uses of language
• Different ways to combine components
• Different ways to present architectural concepts and thinking

In this module I will explain how every EA model or architecture description conforms to its own conventions or protocols.

In this lecture I explain all of the things that a good metamodel has to cover.

This module summarizes the key learning points about integrating views and viewpoints:

• That metamodels are a vital part of EA
• That using metamodels effectively requires an appropriate and resilient metametamodel which can handle:
  • Different ways to combine components (e.g. current, transition or target configurations)
  • Different ways to present architectural concepts and thinking
  • Different uses of language (e.g. different words for the same or similar constructs)

In this module you can hear how I answered some tricky questions from a client about the pitfalls that EA faces!

The resources include a set of 10 audio files - each one the response to a client question. Each question is listed in the lecture, and you can then download the corresponding answer.

All of the questions were asked in a single client session - so the answers flow from the first answer through to the last one.

This lecture describes the top two pitfalls for EA

1. not having a clear idea of the outcome or difference that the EA team will provide, and
2. lacking a true focus on architecture.

It provides advice on how to avoid these pitfalls.

This lecture explains what we mean by "architectural" advice.

It explains the difference between an architectural level of understanding, and the understanding at solution, development and operational levels. It then goes on to give examples of the advice you can expect from a good enterprise architect.

This lecture explains how EA works for a smaller organization - that doesn't have the same resources as one with a large EA department.

It explains that:

• There are limitations in a smaller company
  
  • But you may not need the same level of support
  • You can use people with a reasonable architectural background
• And support this by using coaching or mentoring
  
  • Explore broader context
  • Look at different options
  • Effective decisions making

In this lecture I explain how a good EA team makes the transition from architectural thinking through to implementation.

EA is sometimes seen as a being in an Ivory Tower and too theoretical. Architectural thinking needs to be integrated with solution design, development, and operation, and the EA team need to follow through so that their ideas can be realized.

The transition from architecture through design to implementation isn’t always done well. This lecture provides advice on how to avoid losing valuable architectural thinking.

This lecture explains how architects balance future needs against the demand for immediate solutions.

It explains how there are different levels of understanding: at the architectural, solution design, dvelopment, and à operations levels.

Different criteria determine how good your thinking is at each of these levels. These criteria can be used to ensure that at each stage you make the right decisions.

There is a danger that we only get "beautiful pictures" from the EA team, instead of something more practical. This lecture explains how we get useful artifacts from the EA team.

It explains that “beautiful pictures” are not enough. That having the right diagrams is very important. It then explains that examples in some common EA approaches and frameworks are too technical and are often outdated.

The lecture explains how diagrams must meet contemporary, architectural needs.

A common pitfall is that EA is introduced at the wrong stage. This lecture explains why it is important to have a strong focus and purpose for the EA team, based on the organizational needs and the business model.

It explains how to ensure that the EA team really do make a difference, by matching expectations and performance.

This lecture covers some considerations on when an organization should introduce an EA framework. It explains why - in the contemporary world - EA is nearly always beneficial.

In particular, it explains why “enterprise” architecture is almost the wrong word – increasingly EA components are in a broader environment.

Unless we measure the performance of an EA team we have no way of knowing whether they are achieving what is expected from them. But how do we put the right measurements in place?

This lecture explains how to avoid this pitfall, and gives two detailed examples of specific measures - standardization and adaptability.

This lecture provides a summary based on the points made in the other lectures in this section.

It describes the need to:

• Have a clear focus, purpose for the EA team
• Make sure they are thinking at the architectural level
  
  • More than solution designs
  • Broader context
  • Wider range of options
• Be able to make a seamless transition from architecture to solution design to development to operations by making sure that decision criteria from each level is carried through to lower levels.
• Finally it provides a reminder that architects must customize any reference materials or architecture frameworks to meet their exact needs.

Use this Exercise to help you think about the topics covered in this section.

There is a short scenario to read: as you read it, look out for any of the common EA pitfalls described in this section.

When you've read the scenario, write down which pitfalls the EA team have fallen into, and any tips that you would give them to help them avoid these problems in the future.There is no perfect or right answer.

The next lecture highlights what is going wrong, and gives some suggestions on how it could be improved.

This lecture looks at the pitfalls that are relevant to the company in the Exercise at the Exercise on EA Pitfalls.

There is no "correct" answer - in the end it is important to reflect on what is happening in your enterprise to see what can be done to improve the chance of success by the EA team.

The next two lectures take this discussion further by looking at the specific changes made by the EA team in the exercise case study.

In this lecture you can watch as I examine the key pitfall faced by the EA team in the exercise.

Again it is important to stress that there isn't a "perfect" or "correct" answer. This example simply shows the pitfall perceived by this particular team.

The next lecture continues with a discussion of how the EA team re-arranged their architectural roles to address this pitfall.

This lecture continues from the previous two lectures, based on the Exercise about EA Pitfalls.

There isn't a "perfect" or "correct" answer: this whiteboard example shows how the EA team re-arranged their architectural roles to address this pitfall.