A brief introduction to enterprise architecture (EA)

“Building a large, complex, enterprise-wide information system without an enterprise architect is like trying to build a city without a city planner. Can you build a city without a city planner? Probably. Would you want to live in such a city? Probably not.”
-Roger Sessions, in “A Comparison of the Top-Four Enterprise Architecture Methodologies

I talk less about Enterprise Architecture (EA) because I have less hands-on experience to-date with implementing it. But I want to introduce the topic, because EA is an important IT capability that greatly supports IT service management, IT project management, and IT governance while generally making IT more effective.

Enterprise architecture helps you “rationalize”/standardize things: any new project just needs to choose which patterns to use, and then everyone knows what to do! The chosen patterns will work with everything else. Project teams don’t need to hand-select the server types, number of CPUs, &c.; that’s part of the pattern! Enterprise architecture enables change, by giving you patterns that can be used over and over–simplifying the process of changing your organization.

Below I’ll go into the components of Enterprise Architecture and introduce a bit of how organization might go about building their EA.

Enterprise architecture components

Fundamentally, enterprise architecture is about building the patterns your organization should use to enable change. As examples:

  • Enterprise Architecture might identify the high-level business architecture and who’s responsible for the business processes, and it might also define some building blocks for processes. (“Business Process Management,” a separate capability, might then delve into those processes and tune them.)
  • Enterprise Architecture might identify the high-level types of information and how that information supports the business processes. (“Information Management,” a separate capability, might then develop the detailed documentation about the information.)
  • Enterprise Architecture might identify the high-level technical architecture or patterns used to build tools. For example, they may build patterns like:
    • Application with 3 servers: 1 for Microsoft SQL Server, 1 for the application server, and 1 for the front-end IIS web server
    • Application with 3 servers: 1 for Oracle, 1 for the application, and 1 for Apache/Tomcat web server

Building and improving your enterprise architecture

Enterprise Architecture can be built and maintained by an EA team or office. Because its perspective is very long-term, and organization-wide, it needs to be able to talk with high-level administrators and you will typically pay these people a lot of money. The position maps a little bit to a Business Intelligence-type architect position. The idea is these people are overall saving the organization a lot of time and money by enabling change, reducing the costs of those changes, and increasing the quality of everything they touch.

To build an enterprise architecture, it’s helpful to have governance structures in place. The current enterprise architecture should ideally be controlled by governance groups. Lacking those, someone in authority needs to sign off on the current-state EA. The purpose of this review/approval is high-level backing for saying that something’s not part of the current EA.

When someone wants to do something that’s not part of your current architectural standards, many people see that as a Bad Thing. It’s not: instead, it’s an opportunity to discuss with the requester what they want to do, then see whether an existing EA pattern might work, and if none work well then it’s time to improve your EA! In other words, any potential “violation” of the EA is an opportunity to see how to improve the standards.

Connections between EA and other processes

Enterprise Architecture supports project management, by defining work packages that can be plugged into a project management plan. Project teams browse a catalog of patterns to identify what work is needed. These patterns can also help with resource management: less expert staff can implement what’s in the patterns, freeing up the most senior staff for unusually challenging work, and patterns can have rough time estimates that can be plugged into high-level resource planning.

Enterprise Architecture supports service management, by informing Service Design. EA patterns can be designed to ensure high levels of warranty. (You may recall that architecture is one of ITIL’s “5 aspects of Service Design.”)

Enterprise Architecture supports IT governance, by creating a mechanism for reviewing and controlling IT asset purchases. IT assets should only be purchased if they fit within the EA standard. EA also helps enable IT governance decisions, by making it easier for IT to change in the way IT governance wants.

Enterprise Architecture supports IT process improvement, by creating a place for process improvement knowledge to be stored and used again. For example, if a process improvement identifies that a service crashes every two weeks because Apache 2 crashes using mod_python, the EA standards can be updated to deprecate Apache 2+mod_python and instead use, say, Apache 2+wsgi (a different mechanism that can also run python code). That way the problem is solved not just for the current service but for all future services.

EA can also support Business Process Management and Business Intelligence/Information Management/Data Management by providing a framework within which to work.

All that said, Enterprise Architecture is much less understood than IT project management, IT service management, or even IT process improvement. If you want to know more I recommend reading the EA article I quoted above.