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.
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.