In-Depth

Provide a Common Frame of Reference

The job of technology architecture is to help people better organize, visualize, and communicate about technology.

In a previous EA Realist column I discussed the importance of modeling to establish and communicate technology architecture. However, not everyone agreed with my views. Here's how one reader with the job title of PhD Enterprise Architect reacted to that column:

Jeff's article is condescending and completely misses the point of IT and strategic "alignment." The concept of modeling the "technology architecture" in isolation is outdated. IT is but one aspect of an overall architecture, and we're much more interested in modeling techniques that cover the business aspect of technology. Technology modeling is easy; business and strategy are hard. It's unfortunate that people like Jeff are out there giving enterprise architecture such a bad name.

My view regarding how to define enterprise architecture conforms to The Open Group Architecture Framework (TOGAF), an industry standard architecture framework that describes enterprise architecture as consisting of four components:

  • Business architecture
  • Data architecture
  • Applications architecture
  • Technology architecture

First and foremost, the term architecture implies documentation. The different types of architecture listed above each document a different aspect of the enterprise. Business architects model business processes, including business events and business rules. Data architects model representations of real-world entities and relationships. Applications architects map portions of processes and data into instances of specific business solutions (i.e., applications).

But what do technology architects model? What exactly is technology architecture? Most organizations struggle to figure out how to model their technology architecture. In fact, few enterprises today claim they have successfully modeled their technology architecture. The challenge for many is that the breadth and scope seems so daunting that they don't know where or how to begin.

Just as with business architecture, data architecture, and applications architecture, the biggest challenge for technology architecture is figuring out what exactly to model. The most important goal is to make it so that technical and nontechnical people alike can both understand and be understood when talking about, or even thinking about, technology.

The job of technology architecture is to provide a shared frame of reference by helping people better organize, visualize, and communicate about technology. The basic objective is to facilitate the exchange of ideas. A nice byproduct is the cost savings that result from product consolidation and standardization.

Management Leverage
Every management decision involves leveraging one or more of the following factors: money, people, property, or technology.

Every business tracks its financial assets. Every business oversees its human resources. Every business manages its tangible assets (i.e., plant and equipment). But how is technology measured and tracked?

Technology needs to be described in terms of what an enterprise owns, not how many or how much. People need a framework for thinking and communicating about technology.

My advice on how to get started modeling technology is to follow the money. Look at technology investments. Focus on where money has been spent. All of the technology investments collectively constitute an enterprise's technology portfolio (see "Architect Your IT Portfolio").

Enterprises spend a lot of money buying technology. What they get back in exchange for their cash are products supplied by vendors. It's too bad, though, that simple alphabetical lists broken down by product or vendor aren't very helpful. Otherwise, you could easily model technology architecture using simple spreadsheets or databases. Instead, products must be organized and classified into hierarchical category trees. Suddenly, rectangular spreadsheets or relational databases are no longer so simple. As soon as you introduce hierarchies, everything becomes more difficult and complex.

Each category tree represents a taxonomy. Taxonomies make it so that different products that offer similar functionality cluster together. Category trees also provide context. Classifying and organizing products into category trees helps people—both technical and nontechnical—better understand and be better understood when discussing technology. They also help prevent meaningless apples-to-oranges comparisons.

Products, vendors, and category trees are the basic ingredients that go into modeling technology architecture. Additionally, I recommend you view technology architecture as three separate layers.

The bottom layer represents infrastructure. It's often enormously complex and expensive. Yet, by itself, infrastructure doesn't do much of anything. Value is derived only after applications have been layered on top of the infrastructure. Applications, the middle layer, can either be custom-developed or purchased. Regardless of whether they're built or bought, applications generate data, which corresponds to the top layer. Most enterprises want to mine their data to improve business intelligence.

My net uptake here is that the reader who responded to my previous column does not fully understand the magnitude and importance of the documentation process, as well as its deep and lasting tentacles into the very business processes he or she seeks to underscore. The consolidation and standards made possible by technology architecture can cut technology portfolio costs by at least 10 percent, and when technology architecture is combined in equal measures with the other three supporting pillars—business, data, and applications architecture—enterprise architecture yields a powerful and long-lasting alignment of IT and business strategies.

Most   Popular