Close Open

Please Update Your Browser.

It is recommended that you update your browser to the latest version to view the website's full experience.

Dismiss

Areas of Practice

You are here

Many enterprise architecture frameworks break down the practice of developing and using EA artifacts into four practice areas. This allows the enterprise to be described from four important viewpoints. By taking this approach, enterprise architects can assure their business stakeholders that they have provided sufficient information for effective decision making.

These practice areas are:

Business:

  • Strategy maps, goals, corporate policies, Operating model
  • Functional decompositions (e.g. IDEF0, SADT), capabilities and organizational models
  • Business processes
  • Organization cycles, periods and timing
  • Suppliers of hardware, software and services

Applications:

  • Application software inventories and diagrams
  • Interfaces between applications that is events, messages and data flows
  • Intranet, Extranet, Internet, E-Commerce, EDI links with parties within and outside the organization

Information:

  • Metadata - data that describes your enterprise data elements
  • Data models: Conceptual, Logical and physical

Technology:

  • Hardware platforms and hosting: servers and where they are kept
  • Local and wide area networks, Internet connectivity diagrams
  • Operating system
  • Infrastructure software: Application servers, DBMS
  • Programming Languages etc...

Security Architecture

While these four areas are the traditional breakdowns for analysis they imply that business understanding is approximately one quarter of the process or one quarter of the importance. These four practice areas are useful for conducting enterprise analysis but EA needs to be treated as a business issue and not a technology issue. The primary purpose of describing the architecture of an enterprise is to improve the effectiveness or efficiency of the business itself. This includes innovations in the structure of an organization, the centralization or federation of business processes, the quality and timeliness of business information or ensuring that money spent on information technology (IT) can be justified.

To reflect this perspective, the College of IST is partnering with the College of Business and plans to give the business side of the equation equal prominence with the IT side of the equation.

A final important element of EA practice is "Transformational Change." Enterprises undertake the process of enterprise architecture for a variety of reasons. The enterprise wants to perform better by doing things differently and it expects the EA program to effect that change. All the future-state models, principles and road maps will be for naught unless they are actually implemented or they are an ongoing part of how the enterprise operates. This usually requires a robust governance mechanism that will ensure that EA guidance is followed and that there is strong integration with the IT strategy, enterprise program management and portfolio management functions in order to ensure that common strategic goals are shared.

Academic and Industry research organizations alike point to change as an important variable (and area of study) to ensure that the focus is not only on different components of a representation but also includes the essential property of helping an organization (a complex entity) evolve and move along a desired and sometime changing trajectory. This can take several forms and may encompass one or more of the layers above as well as interactions among these layers (leading to shearing models of change suggested by IBM as continuing change efforts instead of traditional freeze-unfreeze models). EA facilitates these processes by explicitly stating these requirements spelling out future states and suggesting ways to better align technology with changes in strategy.