First, having a business leader heavily involved in enterprise architecture is necessary because only they understand the real information needs of the company and how they fit in with the business plans (Cook xix). This may be an executive, CIO, VP, or similar high-ranking individual. They may also act as a "sponsor" type of role in developing and presenting the plans to upper management. This is a very important role. Irrespective of the quality of the Enterprise Architecture, the success of the effort is primarily dependent on the support and enforcement of management (Meta - Managing Change Through...).
The following picture demonstrates the connection between business drivers and IT infrastructure:
(From Gartner - The Unexpected Case...)
Executives and managers can bring the business drivers to the table while the IT experts identify the appropriate IT components.
Next, there are the architects or planners of individual business units. This group may also be specialty groups for specific IT projects or technologies that have their own planning teams. These are the people who know their area the best and can provide the necessary insight. Often, these may be the same people who do some of the implementation. Finally, the enterprise level architects consolidate the business information and goals with the individual business units and specialty groups. Enterprise level architects may also deal with other high level architects in the areas of data management, application development, or infrastructure (Gartner – What Do IT Architects Do?).
Once data is accumulated from all areas of the business and technical areas, then the architect's job is to define all of the major elements, interfaces, and partitions between the different areas. Even though much of the information will have to be found at the departmental level, the architect should take a enterprise view of the organization during the analysis. Priorities and responsibilities of individual departments may change over time, but the overall nature of the organization should be relatively stable (Miller). Depending on the organization, further responsibilities of the architects may included managing the lifecycle of major groups of technologies, procurement of infrastructure level technologies, methodologies for design and documentation, standards for lifecycle development and operational processes, training needs, data architecture (naming standards, storage, etc.) (Gartner – What Do IT Architects Do?). Creating standards between different areas of the company will ensure that applications can be effectively integrated with each other.
A paper on Enterprise Architecture wouldn't be complete without mentioning the Zachman Framework. This framework provides a basic structure for organizing a business's architecture through dimensions such as data, function, network, people, time, and motivation. The last three dimensions were more recent additions to the framework. Each dimension is then described through the perspectives of different players in business's IT organization such as the planner, owner, designer/architect, builder, subcontractor, and user. This very technical and rather theoretical framework is rarely used "as-is" rather it is the basis for other, more practical applications of Enterprise Architecture (http://www.istis.unomaha.edu/isqa/vanvliet/arch/isa/isa.htm). The Zachman Framework should be something that any IT Architect should at least be familier with, and to understand some of the questions of who, what, when, why, and how - and from who's perspective are the answers (Meta - Managing Change Through...). Answering these questions will be beneficial in producing a complete Enterprise Architecture. Another advantage of the Zachman's Framework is the idea of classification. Classification allows you to "eat the elephant one bite at a time" and identify different pieces of the IT infrastructure through different perspectives in logical pieces. By doing this, you have a much more manageable list of components to analyze (Cook 47).
A final part of the architects job involves actually using the architecture that they have created. Communication is probably the biggest part – an architecture isn’t any good if the other managers and technical designers in the company are not aware of it. By educating these people, and showing them roadmaps for technology, they can make better decisions. The architects should be responsible for dealing with exceptions and helping to minimize their impact on the stability of the infrastructure (Gartner – What Do IT Architects Do?).
Despite much industry wide concern about outsourcing, these enterprise architect jobs are not likely to move outside of the organization. The type of business insight, longevity, and systems thinking are hard to find in a typical IT outsourcing arrangement (Gartner – Enterprise Architects: Technologists...). As important as Enterprise Architecture is to a company, having stability in this role is crucial.
