A question that I am often asked by colleagues and friends alike is "What is an Enterprise Architect, anyway?" This article is the first in a series of articles that will explain the term "Enterprise Architecture," why it is important, and how each of the disciplines that constitute Enterprise Architecture relate to each other. Most importantly, this article is going to talk about how Enterprise Architecture needs to govern the processes around software development.

My recent posts about integration with Microsoft Exchange have reminded me how important it is to keep the pragmatism of the application of technology to solve business problems very sharply in focus. During the process of building the Microsoft Exchange integration components, I have also been involved in a couple of projects that are very enterprise-focused during my day job. The combination of these projects made me step back and think about how we build software, and I realized that during the 20-some years that I have been in this industry, there are some things that I have learned and applied that have become the cornerstones of how I approach software. Later in this article, I am going to come back to this because it is key to the importance of Enterprise Architecture. 

Enterprise Architecture

As the term "Enterprise" suggests, enterprise architects are responsible for architecture that is enterprise-wide. That is, they are responsible for looking at the entire organization and understanding how it is structured to do business, identifying the areas where the process can be improved – often by the introduction of a technology solution – and then introducing the business process improvements and technology solutions that streamline the business.

Mature enterprise architecture actually goes even further than that. In a mature organization, enterprise architects work with the business leaders to define and enhance future business strategies, define processes to meet the strategies, and then implement those processes, using technology where appropriate.

What this means is that enterprise architecture is as much about understanding business as it is about technology.

Enterprise Architecture Disciplines

As with any discipline, enterprise architecture has numerous facets. The diagram at left shows all of the disciplines that are associated with enterprise architecture and provides a visual queue for how they relate to each other.

Disciplines in blue are all predominantly business-focused, whereas those in brown are more technology-focused. The lower down the stack you go, the more technology-focused the discipline is, whereas the higher up the stack you go, the more business-focused it is.

The oddball in the stack is Research and Innovation. This is a discipline that needs to span technology and business.

There are a few important things to bear in mind about these disciplines.

First, none of them lives in isolation. They all need each other to successfully deliver value to the enterprise.

Second, none of them is more important than the other. Just because Business Architecture is at the top of the stack does not mean that business architects are more important than database architects. Rather, the stack is intended to show how these disciplines relate to each other.

Third, a lack of focus on any one of these disciplines creates a gap that makes the stack incomplete. Inevitably, the organization will compensate for the lack of focus on an element in the stack by creating a compromised design. Nowhere is this more evident than in the Data Architecture discipline. If there is no focus on data architecture, an architecture will emerge organically, almost always generated from the schemas of component applications. The result is that integration suffers. 

Lastly, every discipline in the stack is directly dependent on the discipline above it. So information architecture requires a thorough definition of the business architecture in order to produce the business intelligence that is needed. Data architecture needs a clear information architecture to provide the data that is needed for the business intelligence to be derived, and so on.

An argument could be made that enterprise architecture governance is also a part of this stack. I am not opposed to that, but I really view governance as a management function that is embedded in each of the architectural disciplines. In some organizations, that governance does need to be broken out into a separate unit.

Let's take a look now at some details of what each of these disciplines does.

Research and Innovation

Research and innovation is really the oddball in the stack, because it spans the entire enterprise architecture stack, from business architecture all the way down to specialist architectural disciplines. in fact, it goes even lower than that, but that is beyond the scope of this discussion.

Research and innovation is about understanding what is going on in all industries that are related to the enterprise, understanding advancements that are being made that could enhance the business, and finding ways of exploiting those advancements to create competitive advantage. It also includes incubating new ideas that could allow an enterprise to leap-frog its competition.

In a future article, I will spend some time talking about how the research and innovation component of the Microsoft Exchange integration project has provided this kind of competitive advantage.

Business Architecture

It is hard to understate the importance of business architecture, and I think it is really interesting that in the last 10 years, IT has felt the backlash of driving businesses to make decisions based on technology, rather than sound business principles. Leading into Y2K, two massive technology drivers were forcing businesses to invest exorbitant sums of money in projects that were little more than experiments in technology – the Y2K "bug" and the advent of internet commerce. Much of that investment returned little to no value, and today IT organizations are being forced to focus their attention on business value. Business architecture is the architectural discipline that leads this initiative.

What this means is that business architects are really focused on understanding the business, not the technology. In a mature organization, business architects (and business analysts) work very closely with business units to understand their business processes. They are responsible for analyzing how the business runs, producing the definition of the business processes, defining new processes that align with the strategic goals of the enterprise, and defining the requirements from which all technical decisions are derived. A very important part of a business architect's role is to evaluate the existing processes to reduce redundancy, streamline the process, and automate as much of it as possible. Highly skilled business architects are also able to define the key performance indicators within a line of business so that it is possible to measure the success of the business.  

Information Architecture

Information architecture is the process of understanding what information the business needs, how to go about delivering it, and ensuring that nothing is lost. As with business architects, information architects have a strong business focus. They are normally lateral thinkers who are capable of envisioning ways to transform data into actionable business intelligence. Over and above the general reporting requirements that is part of the responsibility of information architecture, the discipline also involves understanding interactions with external stakeholders such as vendors, partners, and customers and producing an information strategy that monitors and enhances these interactions.

As with the business architecture discipline, information architecture is highly business-focused with its purpose being to provide decision makers the information they need to maximize business profitability.

Data Architecture

Probably the most neglected discipline in most companies is the data architecture discipline. Many people see data architecture as a function of information architecture, and it is probably best kept as part of the information architecture discipline, but it is really the first layer in the architecture disciplines that crystallizes business concepts into technology artifacts. What I mean by that is that data architecture is all about understanding the nature of the data in an organization, what operates on it, and how it is stored.

The data architecture discipline is absolutely crucial to integration because data architecture is the custodian of the enterprise data model that defines entities and their relationships across the enterprise. It therefore affects every other discipline around it, including application architecture, infrastructure architecture, solution architecture and integration.

The data architecture discipline also owns the responsibility of defining and maintaining the canonical model that is used in a service-oriented architecture to govern data transformations between services. 

My next post will include a detailed discussion of this discipline, especially as it relates to the Microsoft Exchange integration project.

Application Architecture

Application architecture is the process of understanding how applications operate on the data that is defined by the data architecture discipline. It is also responsible for understanding integration between applications so that they are able to properly communicate with each other and provide each other any necessary data.

Application architecture is also the custodian of the library of services that are required for a service-oriented architecture and they own the definition and governance of that library.

Infrastructure Architecture

Infrastructure architecture is the process of understanding the "plumbing" that is used to support a technical solution. So, for example, in the Microsoft Exchange integration case, Microsoft Exchange is an application and the OpenEdge CRM application is an application. These two applications need to communicate with each other. One (the OpenEdge CRM application) runs on a Unix server and Microsoft Exchange runs on a separate set of Windows servers. At a lower level, the OpenEdge CRM application has an AppServer associated with it and Microsoft Exchange uses a web server and has several server processes that are associated with it. With the roll out of the Microsoft Exchange integration solution, additional Java-based services such as Apache Tomcat and Apache ActiveMQ will be added to the mix.

Infrastructure architecture is about understanding these technical components, how they relate to and communicate with each other, and where the opportunities are for optimizing these infrastructure components.

As we move closer to cloud computing, this is a discipline that requires increasingly skilled people because virtualization, high-availability, network fabrics and all of those components factor into the decisions that are being made about hosting technology solutions.

The Divide between Business and Technology

Up until this point, all the disciplines that we have discussed have been focused on the business. Most of the questions that are being asked in those disciplines are related to how the architecture can be built to drive increased revenue and reduce operating costs. Many view this point as the division between what they call Enterprise and Technical architecture. In order to ensure maximum business benefit, though, these disciplines all need to work very closely with each other in a tightly cohesive team. I, therefore, view technical architecture as a facet of enterprise architecture and prefer to view technical architects as specialist architects who have extensive knowledge of their particular discipline.

Solution Architecture

Solution architecture is the discipline that most people think of when they talk about a Software Architect. A solution architect is able to take a specific problem, identify the appropriate way to solve the problem, and turn that into a technical solution that spans numerous specialist disciplines. The key point about this discipline, though, is that it is more technically oriented than business oriented. Successful solution architects are often viewed and technical gurus, capable of solving any technical problem.

Specialty Architecture

Specialty architects are extremely valuable resources as they understand their area of specialization inside-out. Generally, specialty architects have been in their field for several years and have solved significant business problems with the technology with which they are proficient. The above diagram references several time of specialty architects.

Integration architects have a thorough understanding of integration technologies like middleware, complex event processing, and business activity monitoring. In a service-oriented architecture, this discipline is responsible for overseeing the implementation of the canonical model and all related services. 

Application-specific specialty architects focus on products like SAP where there is a high level of skill required to understand the application as a whole. The other specialty architects are also highly skilled in their particular avenues and able to advise, mentor and lead significant development efforts based on their particular technology.

While it is likely that specialty architects are exceptional programmers, the discipline itself does not requires them to write code. 

Structured Systems Analysis and Design Methodology (SSADM)

What I find really interesting is that these disciplines have really only become clearly defined in the last few years. The reason is that 20 years ago, computer systems were nowhere near as complicated as they are now. There were far less of them and they were far more monolithic.

Nevertheless, 20 years ago I attended a course on a methodology called Structured Systems Analysis and Design Methodology (SSADM). In those days, systems analysts were expected to perform the business analysis and architecture function. So they would be responsible for documenting the business processes that the business needed.

From those business processes, a systems analyst would derive a set of data entities from the connecting lines between the processes. They would flesh out those entities by reviewing the paper forms or screenshots of existing applications to understand what the data elements were that made up the application. 

Those same analysts would then create a matrix (called an Entity-Event Matrix) that contained each process in the columns across the top of the matrix and each entity in the rows down the left side. They would then mark with a C, R, U, or D any cell that was affected by either a create, read, update or delete of the entity. From this, an entity life-cycle could be produced that demonstrated the life history of an entity. 

This matrix and the life-cycle were then used to build a specification of the processes that had to be built to operate on the data. Next, a set of JAD (Joint Application Design) sessions with the user would define the set of screens that would be built to enable the user to interact with the system and the reports that would be generated from the system.

Once the design is complete, the systems analyst and a group of programmers would go off and build the application.

As I said, this was a methodology that I was taught 20 years ago, and although much of it has been augmented by additional requirements imposed by additional complexity of modern computer systems, at the core, nothing has really changed that significantly. TOGAF and Zachman, two more modern enterprise architecture methodologies, emphasize the same basic principles of enterprise architecture. Of course, it is a much more iterative process now.

Conclusion

In many enterprises, architects are expected to be proficient in more than one of these disciplines. In large enterprises, although there is an expectation that enterprise architects are proficient in more than one discipline, often their focus is narrowed considerably by the amount of work to be done.

Nonetheless, I have found that my experience with SSADM taught me many of the things about enterprise architecture that I never knew I was going to value, and now, 20 years later, I am fortunate that I am able to cover the entire stack of enterprise architecture disciplines and many of the specialty disciplines, thanks to what I learned from SSADM.

Enterprise architecture is a relatively new buzzword that is increasingly being seen to provide significant business benefit and substantial return on investment. Look for these disciplines to grow significantly over the next 5 years as IT systems become increasingly complex. 

In the upcoming weeks, I will be building on this discussion by delving into each of these disciplines in more detail. First on my list is data architecture, as it is a discipline that is very near and dear to my heart.