Enterprise Architecture as an Approach to Anything

Feb 1

Introduction

As I learned more deeply about the ways and means of Enterprise Architecture, I found that there are some concepts and methods that are very transferrable to other scenarios. In fact, I find that use them quite often even in very non-technical circumstances.

Very early on in my research years ago, I felt I could investigate the application of Enterprise Architecture as a framework and an approach to, well as this click bait title implies, anything. This article is basically the start of that journey, or at least, putting the thoughts down to share with others.

Enterprise Architecture — Quick Overview

First, a quick overview to set some context. The Federation of Enterprise Architecture Professional Organizations defines EA as: “a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a comprehensive approach at all times…” This is typical and often how it is perceived from a strategic level. My own description is:

Enterprise Architecture connects people, process, and technology to demonstrate how technology enhances business capabilities and drives value.

There are many frameworks that exist today, TOGAF, DODAF, Zachman, and more. While they differ in many ways formally, what they tend to posses commonly, are two things: 1) They focus on capturing and modeling the concepts of an enterprise in a given context 2) They analyze the intersection of those concepts.

I personally find the Zachman framework to be the most malleable and useful, albeit a bit abstract (I intend to put some concreteness to it). This framework positions itself in a matrix which has perspectives as the rows and interrogatives as the columns. The interrogatives are What, How, Who, When, Where, and Why which represent Data, Processes, People, Events, Locations and Motivation, respectively. The perspectives start at a high level at the top of the matrix and as the rows descend, the perspectives get more detailed. It is at the intersection of these perspectives and interrogatives where we do our analysis.

Modeling is another key aspect of EA. Modeling is creating a representation of the real world using named objects and named relationships, typically in diagrammatic fashion. In this space, I like the TOGAF modeling language ArchiMate. Modeling goes beyond just diagramming in that there are specific iconography and relationships between elements that are constrained by rules. For example, if we are denoting an Application Component, there is a color and icon for this object. If we are denoting a Business Actor, this object has a different icon and color. We aren’t just drawing boxes and arrows anyway we want. In this case we may sacrifice some artistic creativity for the sake of consistency, for better or worse.

An entire synopsis of Enterprise Architecture frameworks and concepts is well beyond the scope of this article, I invite you to do your own research if you are not familiar. I will attempt to make this approach clear regardless. Hopefully, even without an EA background, you’ll find this helpful.

Modeling and the Zachman Grid

The two main focal points will be the 1) Zachman grid and 2) modeling. Let’s look at how we can apply these two tools to do, eh-em, anything. Typically, the matrix and modeling were intended for capturing and representing enterprise objects for addressing enterprise business and technological strategic plans.

The reason I like the Zachman grid is its comprehensiveness. Often, when gathering requirements its easy to overlook certain aspects. The interrogatives provide a pretty good approach to minimize missing important aspects of a problem and its solution. Let’s investigate them a bit deeper.

Let’s start with the What interrogative. The What represents the data. Here we will collect the high level Business Objects related to our area of interest. The How represents the Business Processes; these are the procedures that are executed to get things done. The Who represents the people, the Business Actors involved. The Where are the locations, these can be relative, virtual, or physical/geographic. The When are the Events, the cyclic or periodic happenings that trigger, impact, or occur as a result of something in our area of interest. Finally, the Why, these are the motivational elements; the drivers, the goals, the problems, the improvements, the results we want to see by all of the other elements interacting with each other.

Example: Ride Sharing App

Now let’s use a real example. How about an exercise in system design? We can use this framework to start the design of a system, in this case, we can do a ride sharing App.

Let’s start with the Why. Why do we want to have a ride sharing app? We want to connect drivers with riders so that people who have cars can make money and people who need rides can access them easily. And, we want to make some money by providing this service. So our goals are to 1) Provide a supply of drivers to the demand of riders 2) Make revenue from this platform.

Motivational Elements

We can do the Who next, we already identified two actors, “Riders” and “Drivers”. We’re probably also going to need “Engineers” and “Support Staff”. There are more, but let’s start with that.

Business Actors

What about How, the processes? We’ll need at the least, a process for rider to connect with a driver. But how do we get riders and drivers onto our platform to begin with? We’ll need a process for onboarding riders and drivers. We’ll need processes to collect money from riders and to pay drivers. There are more, for brevity let’s move on.

Processes

Where, the locations, could be dynamic ones, like the location of the rider and the location of the driver. Their location is hugely important when trying to connect them. We’ll need to know the location the rider wants to arrive at. If our riders and drivers could be anywhere, where would our platform be hosted? How will they access it? There will need to be a mobile client with co-located geo-redundant services. Well that got technical fast.

Locations

The What, the data, the business objects: riders, drivers, accounts, locations, payment methods, etc.

Business Objects

Finally, the When or events, such as ride requested event, driver arrived event, rider picked up event, rider dropped off event, driver available event, peak time started event, peak time ended event, etc.

Business Events

Just by covering these questions at a high level, we can immediately start uncovering not just our functional requirements for a system like this, but the non-functional requirements as well. How do we handle peak time events? How do we scale nationally? Globally? Just by naming some of the concepts, formally, we can start understanding what we will need to do to make it happen.

Business Events

Example: Designing a Restaurant

Ok, so I did title this, Enterprise Architecture as an Approach to Anything, so let’s examine a non-technology centered scenario. How about opening a restaurant?

Why (Motivation): To serve people excellent food, provide income I can live on.
Where (Locations): NYC? San Francisco? Paris? Where will I source my food? Local?
When (Events): Kitchen Opened, Delivery Received , Restaurant opened, Customer Arrived, Reservation Place, Food Served , Kitchen Closed, Valentines Day
Who (Actors): Customers, Chefs, Sous Chefs, Servers, Bar tenders, Suppliers, Inspectors
How (Processes): Seat Customer, Take Order, Prepare Food, Open Restaurant, Close Restaurant
What (Data/Assets): Customers, staff, tables, seats, menu, prices, specials, bills, ingredients

Now while this an interesting way to start getting a conceptual understanding of problem space and what you’ll need to solve for, we obviously have a lot to do to design and plan a solution (or a restaurant or an enterprise). If we go back to the Zachman grid, we’ve only been discussing the first row so far.

We’ve just been cataloging the executive level scope of our problem area. Now we need to start descending to the next layer, which is the business model. We will want to start examining where those entities we identified in the first layer start interacting with each other. For ride sharing, how will a driver contact a rider? How will a rider and driver use our platform? What if someone is both a rider and driver? How does a process trigger one of our events: a ride request process triggers the ride requested event, ride completed event triggers the driver gets paid process.

Which one of our motivations has a higher priority than the other? What data will a driver have access to that the rider shouldn’t and vice versa? In our restaurant example, what processes do Chefs do vs Sous Chefs? Do servers seat people or do hosts? Or do customers seat themselves? How much do servers know about what ingredients are in a dish? How do they find this information?

Again, there is a lot to uncover, even just deciding what you might want to uncover is a task in itself. What we’ve started is representing it for the purpose of socializing it and transferring the knowledge to the broader team.

The third layer is where the technical architecture starts to form. Where the actual technology components start satisfying the business requirements.

In our Ride Sharing App example, if a rider wants to be taken to a destination by a driver through a platform, our platform is going to need a client interface that is mobile enabled with GPS and a payment card on file so that they can pay us. Drivers will need to be onboarded onto the platform with their payment information so our platform can pay them. We’ll need a database, a mobile app, and services running in some hosted environment that is geographically local to the users consuming it.

In our restaurant example, our servers will need a way to record an order and give it to our chefs. This could be on paper or could be a mobile app. Now we can start deciding on what our budget can afford, do we go low-tech or invest in tech-rich capabilities from the start?

We begin uncovering more detailed motivations, like experience for our users or customers. Our ride sharing platform won’t do well without a good user experience driven by a great deal of technology — we can start prioritizing motivations which can help prioritize requirements.

Our restaurant could be on the end of pier with benches for tables, a chalk board for a menu, no waiters, with chefs in a shack. This could be the case if one of our motivations was to have a simple seafood shack in the fisherman’s wharf that serves fresh no-frills seafood. But if our motivation is for a sleek technology driven bistro in the financial district of a major city, our requirements are now much different.

Revisiting Technology Architecture

Capturing this information has benefits up and down the development or implementation process:

As an Infrastructure and Cloud Architect you would appreciate knowing the geographic regions you intend to support and/or deploy into.
As a UX designer you would be glad to know you’ve already identified the personas that we will be using your solution and what processes they will execute.
As a Security Architect, you will be happy to see the data that needs to be protected and the different actors that could access it. As an entrepreneur you’d be happy to explain to your investors why or why not you are choosing to have waiters or a shack on the pier.
And as an Enterprise Architect, you will appreciate uncovering and socializing the landscape of the business and tech stack, justifying a strategy that hinges on so many inputs from so many stakeholders.

So next time you have a problem to decompose and solve, even if its not technology related, try this approach; ask these questions of yourself and stakeholders. Catalog the entities. Then start connecting them. Select technology components to create an architecture for your solution. Connect those components to the people, process, and requirements you uncovered in the scope and business model layers.

Please do not feel that you need some special role or title to take this approach. I will guarantee just performing this exercise will make you considerably more aware of your problem space, which is always a good thing.

Bryan Weis