Enterprise Architecture by Example

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.

This quiz will test your knowledge of the basics of Enterprise Architecture.

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 take just a few questions to freshen our recollection of the content we've covered so far.

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.