Exam essay: Enterprise architecture
January 2, 2009
I define enterprise architecture, how one develops one and uses it.
Exam essay: Enterprise architecture
A topic of great interest among CxOs when considering use of IT in the firm is enterprise architecture: what do we mean when we say that, why do we care about enterprise architecture, how do we make one. Include business implications, technical implications.
Firms around the world have become interested in enterprise architecture over the last several years. In this essay, I define enterprise architecture, describe why we care about it, and how a firm goes about forming one. I include the business and technical implications of an enterprise architecture on the functioning and structure of a business.
An enterprise architecture is a high level plan drawn in visual form that relates core business processes, enterprise data sources, key technologies and key customers. Companies make enterprise architectures as a way of formalizing how they expect business and IT to be aligned, and as a way of saying what kind of operating model the firm will have: how much will standardization of processes will be used among business units, and how much will key data be shared among business units. Ross et. al. in their book Enterprise Architecture as Strategy say that companies should represent their enterprise architecture in the form of a high-level, one page diagram, and that they can use that diagram as a basis for making technology and business decisions. The enterprise architecture in can serve as both a reflection of how the company currently is operating (so that we can make decisions that maintain that model) or can represent where the company wants its operating model to be (so that we can use our enterprise architecture to decide what changes need to be made to IT and the business in order to bring the current operating model in line with what we want.). The enterprise architecture is about mindfully deciding in how IT is going to be used, because in many ways how IT is going to be used (process standardization and data sharing) can determine the operations of a company, and vice versa.
To show how enterprise architecture influences the operation of the company, I will describe how Ross et. al. use process standardization and data sharing as two axes on a classification grid to classify companies by operating model. Companies with low standardization and low data sharing are called “diversified” companies. Business units in such companies perform diverse and non-overlapping functions; each business unit caters to a different set of customers and offers unrelated services to them. There is little to be gained by standardizing processes and sharing data in such a firm, and the enterprise architecture of such a business would show several parallel sets of processes, systems, technologies and customers.
Companies with high standardization and low data sharing are called “replicated” companies. Franchises are perfect examples of replicated companies. In such companies, business processes are highly standardized, but the business units are largely independent and don’t share customers and thus don’t have data integration needs. IT systems supporting each business unit will be identical or similar, but there will be little or no data sharing. The enterprise architecture for such a firm would show one set of unified processes
Companies with low standardization and high data sharing are called “coordinated companies.” Banks and brokerage houses are good examples of coordinated companies, because they offer many different kinds of services in different ways to the same customers. The enterprise architecture for such a firm would show many different business processes linking to the same data sources and customers.
Finally, there are the unification companies: those with high standardization and high need for data integration. In such businesses, the many business units all share certain core processes and all need to access the same data. The enterprise architecture for such a firm would show a common set of processes linking to a common set of data sources and to a common set of customers.
The enterprise architecture can be developed in many ways, and it largely depends on the type of IT governance the firm has. Ross et. al. don’t recommend that the IT leaders draw up the document themselves, but rather that the business leaders should draw it up with the help of the IT leaders. The enterprise architecture is a living document, and the framing group should meet periodically to discuss and update it.
The business implications of an enterprise architecture are that it serves as an interface between the IT organization and the business units, and as such is a way to explicitly maintain business/IT alignment. Since it (hopefully) was created through consensus between the IT organization and the business units, it serves the similar purposes to Broadbent’s business maxims and IT maxims (maxims are statements of strategy that serve to drive initiatives and projects). Being high level, the enterprise architecture document should allow business leaders to both make decisions about new business opportunities and how to integrate them into the operating model, and to evaluate IT initiatives and projects. From the IT side, the enterprise architecture serves as a planning tool to evaluate potential IT projects both for how they should integrate into the existing systems, and for how they should relate to customers and business processes.
My self-critique:
Now that I’ve written this, I can see that this will not be more than a sub-part of a question. I would probably condense Ross et. al.’s four types of operating models into a few sentences to save time, or eliminate it.
What is current research in enterprise architecture? That’s the only thing I think I would add to this. I don’t see how software development fits into this, and networking and databases would be at too low a level to include.
The Ross et. al. single page enterprise architecture scheme is but one of many frameworks. Some are extremely complicated and incorporate more data and more detail. Turns out that people have been talking about enterprise architecture since at least the late 1980’s. So, me saying “firms have been increasingly interested over the last several years” is way off.
Ongoing research in this area seems to be oriented around evaluating extant frameworks and creating new frameworks; firms all seem to understand that EA is important. The question that researchers have is: how do you make one, at what level of detail should it be, how do you maintain it, and how do you use it to influence decisions.