A straightforward and common-sense introduction that explains what Enterprise Architecture is, and why we need it.
Learn about the key concepts and techniques in Enterprise Architecture that make it a unique and important discipline.
Master practical tips and examples that make it much easier to understand and explain what enterprise architecture (EA) is all about, and why it is so useful. This tutorial is aimed at all EA practitioners and anyone who wants to understand what Enterprise Architecture is, and why it is necessary.
Powerful and Practical Tips to Build Your Career as an Architect
Enterprise Architecture is increasingly recognized as a vital information-age discipline. And there are many well-established architecture frameworks and methodologies.
But certification and training programs don't always describe EA in a simple and straight-forward way.
This course fills that gap: giving you practical tips and examples that show you how to explain what Enterprise Architecture is, and how it delivers benefits and value. Many of the ideas in this course are missing in EA training courses.
The number of individuals gaining enterprise architecture through standard training programs is increasing by over 12,000 people per year! Training as an Enterprise Architect is therefore a smart career move.
Simply put - there has never been a better time to get trained as an Enterprise Architect. To stand out from the crowd you need to make sure that you know how to apply and use your EA skills.
Learn and master how to explain and justify Enterprise Architecture in this simple and straightforward course.
If you are already in an architecture role, or just starting out on a career as an architect, then this course will show you the most effective ways to talk about Enterprise Architecture with your stakeholders and sponsors.
Contents and Overview
I designed this course for two reasons:
With more than 50 lectures, including over 3 hours of video, this course explains what Enterprise Architecture is all about, and shows in detail exactly how to engage with stakeholders and explain it to them.
It explains the things in Enterprise Architecture that are confusing, and gives you practical and useful materials that you can use in your day-to-day work as an enterprise architect.
Above all, this course explains Enterprise Architecture so that it makes sense, and so that you can become confident in applying your EA knowledge in the real world.
What are the requirements?
What will you get from this course?
What is the target audience?
No prior knowledge of enterprise architecture is assumed, although it will help if you have some background information or experience.
There are no prerequisites for this course, as it is aimed at all levels - from beginners, through intermediate to advanced. But you might find a couple of things useful before you get started on the course itself:
Welcome to the course! This is the Enterprise Architecture - why do we need it? course. Thank you for joining.
This lecture gives a brief overview of some of the topics covered in the course. In particular, it looks at some of the common misconceptions about Enterprise Architecture, and introduces some of the ways in which this course will show you how to respond to these them.
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:
The external resources also give you three links that give you some useful background information about EA frameworks.
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
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:
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
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:
In this lecture you will understand why the process of enterprise architecture is sometimes described as a ping pong process!
You will learn how:
In this lecture you will learn what a metamodel is, and how it is used in EA.
You will learn how:
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:
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:
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:
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
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:
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:
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.
Roger Evernden has been an enterprise architect since 1984, specializing in the highly practical use of EA to manage organizational transformation. He acts as advisor, mentor, and coach on EA initiatives, leads training workshops, and writes regularly about strategy and architecture.
He provides a unique combination of training and tools to help architects and their teams throughout an EA program and at each capability level. His hands-on training workshops provide a thorough grounding of all key techniques, with practical examples, exercises, and demonstrations.
As architect of the Information FrameWork (IFW), Roger pioneered many contemporary EA techniques, including the use of industry reference models, business capability analysis, and component-based building blocks.
His work has been the basis for more than 400 business and IT architecture initiatives worldwide. Roger has written extensively about enterprise architecture and TOGAF®. His articles have appeared in major publications and books, including the seminal article on IFW in IBM's Systems Journal. He is the author of two books about EA: Enterprise Architecture — The Eight Fundamental Factors and 101 Lessons from Enterprise Architecture.
He is a Senior Consultant with Cutter Consortium's Business & Enterprise Architecture practice.