I typically try to avoid “buzz” terms like Enterprise Architecture, but sometimes you just need a term. This is one such case. It is either use a term, or paragraphs of explanations. This is intended to be the paragraphs to define the term, Enterprise Architecture.
The term Enterprise Architecture (EA) is not well defined. A quick look at Wikipedia makes this fact more than evident. There are several competing interpretations of EA. But all of these interpretations have a common element – The structure of components to address the needs of a larger system. Typically in these definitions the larger system is the business goals or processes. However, for the IT staff, business goals are not really the system they consider. And if they say that it is, look for their ITIL coffee cup and it will probably be full of ITIL Kool-Aid. No, for the IT folks, Enterprise Architecture is all about services and systems.
Before I give you my definition of EA, I need to clarify a couple of things. A service is work that is offered by a system to other systems. And a system is a collection of services. Clear as mud, right? No. How about an example?
To make this easy, I am going to use a single server running a web-server. The service in this example is a web site. But the web-server application cannot functions without an operating system (OS) and a network connection. In this example, the OS and network are examples of services. The system that is composed of those services is the website. The example can also extend to the web-browser that uses the website, which is also dependent on an OS and network. It is interesting to note that the web-browser is dependent on web-server as well and can be viewed as a system, but that is going just a bit too far.
So, what is EA? – Enterprise Architecture is the view of the enterprise from the perspective of services and how those services are used as building-blocks for systems. In other words, the system-level view of the Enterprise from the perspective of the services, with a focus on how those services are structured into systems.
Back to the web site example, but with a bit more complexity. The web site is actually running on several servers with a MySQL cluster for data storage. The network is composed of load-balancers and multiple switches. In this example the system is the collection of a database service, web service, and network service. Looking at the database service, it is also a compilation of services; networking, OS, etc. So, systems are made up of services, and services are typically systems. Simple.
So what is the advantage of Enterprise Architecture?
When we start viewing the Enterprise in terms of services there are some distinct advantages. The first is sharing of services occurs naturally. As new systems are implemented, connecting them to existing services simply happens. This results in better structure in our solutions and a reduction in costs due to the sharing of resources. Another element is that management of systems can be focused at the service level. Instead of managing a web site, we manage the network, databases, and OS; we manage the services that comprise the web site. The significance of this is that when problems arise, we are not trying to fix the website; we are fixing the service that is broken. This results in faster restoration of services. There are also advantages in terms of reliability, repeatability, and maintainability. Once we shift focus from the systems to the services, the management of the Enterprise improves.
The goal of Enterprise Architecture is to improve IT operations. Fuzzy term, but a positive goal.
-Carl