Chapter 7—Enterprise Architecture

Enterprise architecture (EA) is a planning and analysis tool that can help education agencies through the self- and needs-assessment stages of the LDS project (see chapters 6 and 8). Various complex definitions of EA are available, but this guide follows the Microsoft Corporation's description of enterprise architecture as "a conceptual tool that assists organizations with the understanding of their own structure and the way they work. It provides a map of the enterprise and is a route planner for business and technology change."

Enterprise architecture is "a conceptual tool that assists organizations with the understanding of their own structure and the way they work. It provides a map of the enterprise and is a route planner for business and technology change." (Source: Microsoft Corporation)

For the purposes of LDS development, the education agency and all of its parts make up the "enterprise." The "architecture" is both the process of describing, and the description of, "the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution" (IEEE 2000). Viewed as a process, EA identifies the mission and goals of an organization and the applications, technology, data, relationships, and other resources it uses to accomplish its work. As a description, EA documents the organization's findings in the form of a top-level, low-detail blueprint that can be used to efficiently guide LDS development and maintenance. Though EA focuses largely on technology and the organization of data, its main function is to clarify the technological nuts and bolts so that technology and business needs can be better aligned.

The EA should first describe the current system. The architecture exists whether you describe it or not, but depicting and documenting the "here" gives staff a better grasp of how the agency and its information system work. This depiction, at least at first, should focus on high-level business operations rather than get mired in details. Then an EA of the future, ideal system can be created. With these blueprints, an agency will be in a better position to make decisions about how the enterprise needs to be modified to meet evolving goals (Aden 2008). The EA process also identifies who has authority over different system components, and who has been assigned responsibility for certain activities. EA will therefore be beneficial in both planning and governing the LDS.

Figure 4 divides EA into five areas or perspectives, drawing focus to increasingly detailed aspects of the enterprise.

While many details need to be determined as organizations drill down into the EA process, some high-level questions will help in early LDS planning and are presented below. A variety of stakeholders should be involved in answering these questions about what the system looks like and the purposes it serves.

Business architecture

• What is our business?
• Why does our business exist? What is its mission? What does it accomplish?
• How do we do what we do? What are our core processes? Who do we serve?
• How are we organized? How do people and processes interact to do what we do?
• What are the strengths of our enterprise? What do we do well and very well?
• What are our weaknesses or failures? What have we learned from these failures?
• How will our business change in the future? What are our growth challenges?

Information architecture

• What information do we need?
• What decisions do we make? What information do we need to make each decision?
• What are the components of that information? How do we obtain each part?
• Where does that information originate? Who creates it? What is its quality?
• What information is needed to create the products our business produces?
• Is any of the information highly sensitive? How is that information protected?
• Is there information we do not have that could be valuable to our business?

Applications architecture

• How is that information presented?
• What automated services support our business processes?
• How do our applications interact and depend on one another?
• How are data presented to users?
• How do our applications link various staff within the organization? With the outside world?
• How do our applications help us transform data into information?
• How do our applications serve different groups to achieve common business objectives?
• Do we have plans for developing new applications and revising old ones to meet our goals? (Microsoft)

Data architecture

• What are the data components?
• What are the sources of our data?
• How are data managed? What business rules and quality assurance procedures are in place?
• Do we have a data model?
• What metadata do we maintain? Is a system in place to manage these metadata?
• Do we have an authoritative, agencywide data dictionary?

Technology architecture

• What technology supports our data?
• What technology standards and services are used to accomplish our mission? (Microsoft)
• What technologies are used to collect and maintain our data?
• What technologies protect our data?
• What technologies provide access to our data?
• What technology expertise is needed to support this effort?

Developing an enterprise architecture is most beneficial before or during the planning and analysis stages of the LDS development process. But it is never too late, and great insight can be gained from the process at any point throughout the LDS's life cycle.

Top