Automating Enterprise Architecture

Delivering faster. Saving money. Building new business capabilities. These are value points that make enterprise architecture more relevant than ever. Yet delivering EA at today’s breakneck pace of business requires automation. Here are two ways to do just that.

EA’s Slow Pace

For many organizations, enterprise architecture is still viewed as a governance process or center of excellence which major projects must be “run through.” This puts enterprise architecture on a project’s critical path, and as a result, enterprise architects must scramble to complete solution architecture, standards reviews, and documentation on time. It is these processes that must be automated in order to deliver EA faster.

Antiquated EA Processes

Let’s start the conversation with process, as that’s where things are inefficient to begin with. If we take a statistical examination of common EA work, it doesn’t take long to see that there’s an awful lot of tasks that are repetitive. Diagramming, business process documentation, alternative analysis, and so forth. Of course many of these outputs can live as reusable artifacts (“architecture building blocks” to use TOGAF parlance) but the million dollar question is: where do these things live, and how do common business people leverage them?

The EA process itself becomes repetitive when architects must routinely explain, over and over, where artifacts reside and how the overall architecture process works. Put simply, the entire process must be systematic and operationalized. Moverover, the architecture process is overly-centralized in most organizations, which causes obvious bottlenecks and EA hot spots which ultimately slow projects to a crawl. Such conditions also breed a culture of “working around” EA which never ends well, either.

The enterprise architecture process must be more collaborative so that EAs aren’t doing all the tactical legwork themselves. A prime example of work that is both tactical and repetitive is assimilating business processes for a given area of the enterprise. EAs must often “get up to speed” on how the business works before process or technology artifacts are delivered. This requires interviews, documentation, and lots of Q&A with team members who are often in different timezones and have calendar free/busy views that look like swiss cheese. It’s a mess!

Old School Tooling

If process is one side of the equation, then tooling is the other. Some enterprises have no standardized architecture repository at all; or what I refer to as junk drawer architectures. Fortunately for most companies, there’s some semblance of an architecture repository, but it’s typically built manually. These repositories are usually built on a content management system (CMS) such as Google Drive or Microsoft OneDrive that serves as the hosting facility for diagrams, business requirements documents, and any other architectural artifacts. A web interface like Sharepoint or Google Sites is then overlaid on the CMS to make the content repository web-friendly and relatively accessible.

The problem is that this type of repository isn’t “smart.” Rather it’s static, and has no EA intelligence. In other words, it isn’t aware of the EA process, artifacts which do or not conform to enterprise standards, nor does it know who is responsible for what and by when. We need to turn this dumb website into a thinking machine that can literally start doing some of the work for us.

Modern EA

“Modern” is a subjective term, but for all intents and purposes, the EA tooling of today should automate anything that is repetitive or simple. Additionally, modern EA processes must involve more stakeholders in the EA process so that EAs themselves aren’t the ones actually doing each and every task. The combination of smart tooling and collaborative process is really the key to success in automating your enterprise architecture practice.

1. EA Automation Tooling

Typically I start most conversations around process, but here, I’ll commence with tooling because this is “smart” technology which provides a process foundation right out of the box.

Modern EA tooling does a few things differently from its antiquated predecessors. First, it centralizes everything in a database that is web-accessible to most devices. That includes Windows, Mac, Linux, and mobile clients with no software installation required. By centralizing all architectural artifacts, you simultaneously kill the junk drawer architectures while enabling the system to impose rules and workflows on objects. These smart EA tools have been in service for several years now, and there are many to choose from. So many in fact that both Gartner and Forrester now produce EA tool selection matrices on a regular basis.

Let’s zoom in on an example: the enterprise business application portfolio. In the “old days,” the application portfolio was likely a spreadsheet, and if you were lucky, it boasted a few nifty visuals to show how apps were categorized, what functions they served, and their associated costs. The spreadsheet probably had a hundred or more rows, and many of the columns; many of which would be constantly out of date. To keep this spreadsheet relevant, EAs had to do the lowly administrative work asking for system owners, when particular applications would be sunet, and so on. It’s a highly inefficiency cycle that truly detracts from strategic EA work.

With an EA automation tool other hand, one can enter an application into the system once, and assign multiple owners. On a schedule, the system will email the system owner(s) a survey with questions around whether the application will continue on its current lifecycle, or be replaced by something else. As business owners enter their responses, the application roadmap is automatically updated behind the scenes, and up-to-date reports become available on demand. This is but one of many examples of how EA automation tooling can ruthlessly squash unnecessary tactical tasks, thus freeing up EAs to work on more strategic areas of the business.

2. Crowdsourced Collaboration

As alluded to in the previous section, EA’s can free up time by involving additional business stakeholders in the EA process. But don’t think for a moment that this is merely EA’s pushing tactical work back onto the business. Involving the business in EA is beneficial for architects and business stakeholders alike. That’s because the artifacts being created by the tooling are what business people need in order to make well-informed decisions. I’m not implying that tooling can replace enterprise architects altogether, but getting your hands on the application portfolio for a board review, or generating a proposed business capability map for a new business venture are standard artifacts executives and decision makers alike are using more and more of in our data-driven management culture of today. Enterprise architects themselves should be leveraged for high-level consultation, and of course for building and maintaining this automation framework itself. Not building each and every artifact by hand.


From data centers to project management, the world is moving towards automation. In order to achieve greater results at a faster pace, enterprise architecture must follow a similar trajectory. By systematically operationalizing EA tooling and processes, the enterprise architecture practice itself can move faster and yield potentially greater benefits to the organization as a whole.