
Let's get started! What this course is about, and basic definition of terms.
Enterprise doesn't mean what you think it means, and the baggage we bring to the term "architecture" may be something we need to leave behind.
Let's look at what Enterprise Architecture IS by what it's trying to DO.
The most important thing we can do in EA - talk to people about requirements.
We'll look at the basics of TOGAF and introducing the idea of an architecture development method (ADM), the cycle of enterprise architecture.
We'll take a long look at the raison d'etre for enterprise architecture, the management of requirements.
We'll begin at the beginning with establishing a strong architectural vision for the mission.
We'll continue by describing what we have as it is, defining a vision for what could be, and defining the gap between them.
We'll dig into the processes that make our enterprise what it is, and how it gets done what it does.
We'll move onto the practice of identifying where we can go, what we need to avoid, and how to get there.
All of this work will be for nothing if we don't have a plan to make sure that it gets implemented properly and stays implemented properly.
Change is life - if we don't have a plan for change, then we'll simply drift out of sync with the plan and into chaos.
Remember, above all, that these are intended to be a set of tools to work with and not a line-by-line description of how to do your work.
We'll recap the lessons learned in this section.
Let's get our feet wet with one of the most important segments of an EA ADM, Business Architecture.
The most important aspect of an enterprise architecture is that it reflects reality and that it does so over time.
We'll talk about how to select tools, and how NOT to allow our tool selection to define our reality.
We'll dive into the basics of the lingua franca of enterprise architecture, UML.
We'll apply what we've learned to class and activity diagrams.
Moving ahead, we'll tackle one more document type, sequence diagrams, and demonstrate how to document communication and process over time.
Analysis means identifying gaps between the baseline and target architecture, and using the tools we have to communicate that to the audience we have.
We're going to look at how to map your organization and move beyond the limitations of traditional org charts.
Sometimes gap analysis means creating a gap in the target architecture to remove redundant capacity.
We'll recap the lessons learned in this section.
We'll look at another tool for asking and answering questions about how the enterprise functions.
We'll map a non-software application functionally and talk about what that means.
We'll discuss how to validate that our artifacts are legitimate and executable, and not merely abstract, ivory tower documents.
We'll discuss the limits of software documentation, particularly with respect to automatically generated content.
We'll automatically generate some software documentation and look at the problems with it.
Having looked at the wrong way to do it, let's take a look at a more meaningful approach to mapping software applications.
We'll place what we've learned about mapping software applications into action with a demo.
Let's take a look at the value of diagramming your processes in preparation for a demo.
We'll take that process we created before and look at it in light of our entire cycle.
Let's take just a second and look at what we accomplished with so little effort.
We'll look at an application and technology matrix, and what that can tell us about how things work in our enterprise.
We'll look at the TRM graphics that TOGAF recommends, and decide what we think about it.
One of the key aspects in documenting actual applications is defining whether they're business or infrastructure.
We'll perform some analysis on a sample application and arrive at some surprising conclusions.
We'll talk about one of the great virtues of enterprise architecture, interoperability.
We'll recap the lessons learned in this section.
Aspiring EAs often arrive on the scene with the baggage of database design experience, so let's make sure we understand what we're talking about.
Let's design the data architecture for our fitness challenge on several levels to see what each can tell us.
We'll talk about the problem of getting data from one place to another in an EA context.
We'll take a moment to document a possible data migration process in GitMind.
Let's look at the idea of data migration in the stricter terms of migrating from baseline to target.
Schema versioning is critical and allows us to create a truly executable specification, in keeping with the Schrodinger's Cat effect of documentation.
We'll talk about a mistake I made at the logical level of data architecture once, and the trouble it caused.
We'll look at an entirely non-software scenario and perform data architecture for patient identification at a disaster site.
We'll recap the lessons learned in this section.
We'll look at how one company migrated its security and controls processes to fulfill stringent security requirements for a big client.
What would you do if you had to build a house in twenty-four hours?
We'll look at another story from my career and what happens when nobody has their eye on the big picture at a startup.
We'll take an in-depth look at the causes of the fire which damaged Apollo 13.
We'll zoom in on a particular challenge of Apollo 13 - adapting the carbon dioxide scrubbers that didn't work together.
We'll recap the lessons learned in this section.
We'll look at the quadrant of operating models set forth in the book "Enterprise Architecture as Strategy".
I’m an enterprise architect, not an enterprise journalist.
We'll talk about how to implement Enterprise Architecture as a service that people can rely on.
Some significant figures have mounted criticisms of enterprise architecture, and you need to hear them.
One last appear to make your artifacts beautiful, why you should, and a brief introduction to the work of Edward Tufte.
We'll review the course, briefly, and say thanks and good luck.
After this lecture, you'll understand a little about how AI tools are created, what their limits are, and what those limits mean for how you'll interact with the AI to improve your architecture work.
You'll know five solid EA prompts to use in your work to get good ideas out of the tools with respect to your EA.
You'll be able to prompt LLMs to get EA analysis and to generate EA artifacts.
Large organizations often have dozens of systems, processes, and teams all moving in different directions.
The result? Confusion, wasted effort, and failed initiatives.
Enterprise Architecture (EA) is how you fix that. It shows you where you are, where you need to go, and how to build a roadmap to get there.
What You’ll Learn
TOGAF Mastery
Learn The Open Group’s leading framework and use it to align technology with your organization’s mission.
Baseline to Target Transition
Document your current architecture, define the future state, and use gap analysis to create a practical plan for change.
Business Architecture
Model processes and structures to identify inefficiencies and design improvements that streamline operations.
Data Architecture
Design, migrate, and manage data to improve performance, interoperability, and decision-making.
Real-World Case Studies
Learn from the U.S. Marine Corps recruiting system and the Apollo 13 disaster and see how EA principles make the difference between failure and success.
Enterprise Artifacts
Create clear, actionable deliverables that influence stakeholders and lead to meaningful decisions.
Strategic Alignment
Connect every technology investment to business goals and build support for the changes that matter most.
Implementation Planning
Turn architecture into measurable results with a step-by-step framework that ensures progress.
Why Enterprise Architecture Matters
Companies rarely fail because of bad ideas. They fail because of poor execution and misaligned systems.
EA gives you the framework to execute effectively. It helps you create clarity where there is confusion, reduce waste where there is duplication, and connect technology decisions to business outcomes that matter.
By the End of This Course
You will be able to:
Analyze your organization’s current state
Design its future architecture and plan the transition
Communicate your vision clearly and gain stakeholder support
Guide teams through change with confidence
Enroll today and become the architect who turns enterprise confusion into enterprise success.