The primary goal of the Enteprise Architecture Initiative is to establish a process which is focused on building and maintaining an enterprise-wide technical architecture that best enables the priority business activities of AdCom and facilitates the adaptation of technology to the changing business needs of the campus.

In a typical IT organization, there usually are several "architectures" at work. Architecture spans data, network, application, and security. Moreover, architecture can and should involve business strategy decisions, financial analysis, and business process analysis and design.

The role of an Enterprise Architect is to output from the process of architecture a set of design drawings and possibly models for aiding in visualizing the final result of an extended construction process. As is evident in the previous paragraph, in terms of IT, the output can be quite complicated and situation dependent.

The Enterprise Architect typically produces a high level design which can be used by an enterprise to manage information more effectively. This design is then used by network engineers, application designers, database designers and so forth to drive detailed functional designs in each of these areas. It is clear that the Enterprise Architect must be versed enough in the details of each specialty to realize the possible and impossible.

As quoted from a Commplexus article on Enterprise Architecture:

Enterprise Architecture is by its very nature interdisciplinary. The successful practitioner, while he may specialize in one particular area, must always maintain currency in each of the disciplines. Without this broad general knowledge, he will be unable to design effectively, as problems and opportunities will not be evident. The disciplines most crucial to the Enterprise Architect are:

• Business Strategy. The role of IT is to make businesses more successful in meeting their strategic goals. An Enterprise Architect must be able to understand those goals as expressed by the client, and translate them into winning IT strategies. The role of the Enterprise Architect is not to help the client develop her strategy, but to help the client execute it with technology, process, organizational design and IT operations as leverage points to deliver strategic value. It should be realized, however, that the Enterprise Architect will frequently feed back useful strategic ideas; knowing the capabilities of current technologies, he may be able to point out to the client some problems with their proposed strategy, or opportunities to extend their strategic ideas.
• Financial Management. The Enterprise Architect must be able to analyze, in more than a superficial way, the financial impact of current operations and of proposed changes. One of the weakest areas in general in the IT world is the application of financial management techniques to understand the true costs and benefits of various IT investment choices. Without going beyond superficial "pay back" analysis (which is what most technology vendors will use to persuade customers to buy "technology solutions"), the Enterprise Architect will only contribute to the very reasonable perception among senior managers that IT people don’t understand finance. However, careful analysis can put IT investment decisions on the same footing as decisions made concerning factories and business units. The Enterprise Architect’s job is to show senior management how to evaluate the options presented from an investment point of view.
• Organizational Dynamics. Frequently technology deployments fail because of inadequate consideration of the effects of the change on organizations. Organizations tend to evolve, and at any given moment most organizations will reflect the hard-learned lessons of the last generation of technology. For example, most firms have a large telecommunications operation and a large IT operation. While they may be joined at the head, usually under a CIO, they still speak different languages and often have competing interests. This does not reflect the current state of technology, but it does reflect the state of technology ten years ago. The challenge for the Enterprise Architect is to help the client make the transition to new designs in such a way that the new design can be managed by the changed organization, and that the financial benefits predicted can indeed be obtained.
• Business Process Design. The Enterprise Architect must of course carefully consider business processes as part of the design process; after all, the goal is to make the processes more effective and (usually) less costly. Without understanding how to think of business processes, and how to change them, the architect will be unable to go beyond the level of talented craftsman. Skillfully applying technology to the wrong process, or without considering all relevant processes, may result in a "cool" technology deployment. It will certainly also result in "hot" tempers among the client’s management, since such a deployment, while not all that uncommon, is nothing but a waste of valuable resources.
• Information Technology. Without a firm grasp of all areas of information technology, the Enterprise Architect is doomed to mediocrity. Falling back on our traditional architecture analogy, a great architect must keep current with new building technology trends. While the architect may not be qualified to design a heat pump system, she must understand the differences between heat pumps and standard air conditioners, so she can advise her client well. Similarly, the Enterprise Architect must understand application design, the Internet technologies, database and data warehouse design, network design, and the many other aspects of information technology at a thorough, cross disciplinary level.