MSF Enterprise Architecture Model

How does the enterprise function today? Many organizations can only tentatively answer this question. The MSF Enterprise Architecture Model gives current systems a context that can provide a rationale for the systems' existence, both current and future. Additionally, the MSF Enterprise Architecture Model can provide the foundation for the implementation of business solutions by using technology. Not only do different systems provide features and functionality of their own, but these systems can be logically combined to create an overall system that is greater than the sum of its parts. This overall effect is the desired future state of the organization's enterprise architecture, which the evolutionary implementation of the MSF Enterprise Architecture Model can provide.

As illustrated in Figure 1.2, the MSF Enterprise Architecture Model is a framework composed of four architecture perspectives: Business, Application, Information, and Technology.

Figure 1.2 The four enterprise architecture perspectives

Business Perspective

The Business Perspective includes broad business strategies and plans for moving the organization from its current state to its desired future state. The Business Perspective describes how the business works. It includes:

• The organization's high-level goals and objectives.
• The organization's products and services.
• Business processes that embody the functions and the cross-functional activities performed by the organization.
• Major organizational structures.
• The interaction of all these elements.

Application Perspective

The Application Perspective represents the services, information, and functionality that cross organizational boundaries, linking users of different skills and functions to achieve common business objectives. It defines the enterprise application portfolio and includes:

• Descriptions of the automated services that support the business processes presented in the business architecture.
• Descriptions of the interaction and interdependencies of the organization's application systems.
• Priorities for developing new applications and revising old applications based directly on the business architecture.

Information Perspective

The Information Perspective describes what the organization needs to know to run its business processes and operations. It includes:

• Standard data models.
• Data management policies.
• Descriptions of the patterns of information consumption and production in the organization.

The Information Perspective also describes how data is bound into the workflow, including structured data stores such as databases, and unstructured data stores such as documents, spreadsheets, and presentations that exist throughout the organization. Often, the information most critical to an organization resides not only in database servers, but on the thousands of desktop computers that comprise the enterprise's active working environment.

Technology Perspective

The Technology Perspective lays out the hardware and software supporting the organization. It includes:

• Desktop and server hardware.
• Operating systems.
• Network connectivity components.
• Printers.
• Internet connectivity.
• Other necessary peripheral devices.

The Technology Perspective provides a logical, vendor-independent description of infrastructure and system components that is necessary to support the application and information perspectives. It defines the set of technology standards and services needed to execute the business mission. These standards and services include, but are not limited to:

• Topologies.
• Development environments.
• Application Programming Interfaces (APIs).
• Security.
• Network services.
• Database management system (DBMS) services.
• Technical specifications.

Four Perspectives, One Architecture

Although the MSF Enterprise Architecture Model has four perspectives, there is only one enterprise architecture. As an organization builds an enterprise architecture, it is important to remember that the architecture's value is not in any one individual perspective but in the relationships, interactions, and dependencies between the perspectives.

The development of these four architecture perspectives and the examination of their individual and collective interactions should reveal the information that an organization requires to make rational decisions about its IT priorities, projects, policies, standards, and guidelines. This information is critical for IT implementation and purchasing decisions, and provides a powerful communication tool between the organization's IT and business units.

Alignment of Business and IT Goals

Two significant problems arise for IT managers when facing software deployment and development of business applications:

• After the fact By the time the IT group gets involved, the fundamental business processes are already established, and the IT group misses a major opportunity to effectively apply technology.
• Out of the business decision-making process Because IT is disassociated from the line of business, myriad miscommunications and poor decisions are made about technology.

Organizations should focus on forming a partnership between IT and the line of business. People and processes must rest on a solid foundation before new technology that provides true business value can successfully be deployed.

When confronted with the rate of change and innovation that are inherent in high-technology industries, IT departments may become so consumed with keeping up with new technology, or so frozen with indecision, that they lose sight of the organization's purpose and vision. As a result, they may lose credibility and relevance within the entire organization. To maintain credibility and relevance, IT departments must constantly focus on applying new information technologies in ways that consistently support the organization's purpose and business vision.

The MSF Enterprise Architecture Model is a tool for ensuring the alignment of IT activities to the business operations of the organization. Business unit managers should never doubt that the IT group, and all information technologies under it, exist to support the business. On the other hand, the IT group cannot be expected to align its plans with the business units if it is not given the opportunity. It is critical that the IT and line-of-business managers share a cooperative and reciprocal relationship.

Artificial Wall

Often, an artificial wall exists between the IT and business units of an organization. We say "artificial" because it primarily results from two false assumptions made by both the business and IT communities:

• Business false assumption: "They don't need to know" Many business people think that they should be able to list requirements outside of a specific business context and have the IT group produce valuable solutions based solely on those requirements. An abundance of empirical evidence suggests that requirements are very difficult to meet without a contextual frame, and that generating requirements should involve a number of organizational perspectives, especially that of IT departments.
• IT false assumption: "We already know" Many IT people believe that, even with their limited exposure to the front-line business activities, they can "do it better." Again, empirical evidence suggests that until people actually carry out the functions of a job, they don't understand all its nuances.

For the IT group to successfully support the business groups, both groups must work to tear down this artificial wall. The IT and business groups must forge a partnership based on recognition of their common goal: satisfying the business objectives of the organization. Crucial to this objective are these considerations:

• Business-driven requirements first The MSF Enterprise Architecture Model's Business Perspective provides a framework for determining the impact a project must have to meet the business needs of the organization. These business needs serve to justify each project.
• IT's understanding of business The IT group must have an understanding of the organization's business drivers and opportunities, core processes, and business goals so that it can make rational and informed decisions about IT support activities.
• Business's understanding of IT costs Business unit managers must recognize that when considering the value proposition for altering existing processes or undertaking the development of new ones, true IT costs, including the cost implications of using specific information technologies, must be part of the equation.
• IT's involvement in business decisions Business units should involve the IT group in the development of their business cases and in the definition of changes to business processes.
• Business's involvement in IT decisions Investments in IT infrastructure should be presented and approved based on business, not technical, grounds.

Both business and IT managers must let go of the notion that only those people trained in their own respective disciplines can truly understand their needs. The more each group understands and experiences the "realities" of the other group, the less likely they are to perceive the other as being on an "opposing side" and the more likely they are to find common ground.

Dangers to Avoid During the Enterprise Architecture Process

As an organization defines an enterprise architecture, significant issues can seriously impede its chances of successful implementation.

"Buy" List Focus

The idea of enterprise architecture is not new. Most large organizations claim to have an enterprise architecture in place, but often what they have is no more than a simple "buy" list of approved products. A list of approved products, however, does not constitute or guarantee an effective enterprise architecture. The organization must go beyond the product list to specify the overall strategy and migration steps, as well as provide guidelines on how individual project teams should use the listed products to achieve the IT goals of the enterprise.

Lack of a Clearly Articulated Future State

Without adequate planning and a clear vision of where an organization needs to be, based on business drivers and other reasons specific and internal to the organization, introducing an enterprise architecture will not help the organization arrive at the future state it strives to reach.

For clarity, look again at the definition outlined earlier. The only way to have a progression is to be making progress toward a clearly defined goal. The opposite of progression can be regression, but it can also be walking in circles. It is imperative that an enterprise architecture plan include a clearly defined description of the desired future state.

Too Big and Too Complex to Achieve

Another common problem lies in attempting to define all the details of an enterprise architecture, no matter how wide or deep. The enterprise architecture can become so large that individual and enterprise-wide IT projects suffocate under the weight of their own paper. Because the architecture takes so long to develop, the problem changes before the organization can produce a solution.

Enterprise architecture debates are problematic. A typical enterprise architecture plan can be hundreds or even thousands of pages long, and take one to two years to complete. Remember that this is the time frame for the plan itself, and does not include the implementation. The size and complexity of the resulting enterprise architecture, and the time frame in which it is developed, often make it difficult to identify and prioritize key, organization-wide IT needs. The resulting projects fail to address real business problems, and the IT unit still has the problems it originally set out to solve.

No Provision for Feedback and Course Correction

Building an enterprise architecture should be a collaborative process between the users of the architecture (the project teams), the business owners, and the enterprise architecture team. Enterprise architectures are often built without any provision for feedback from individual project teams. At some point, the architecture must be moved from planning to implementation, and it is the individual project teams that drive the implementation. Without clear communication and a mechanism for feedback from the people actually doing the work, an architecture might be put into place that looks good on paper but is inappropriate or unstable.

All too frequently, business conditions and priorities change over the course of developing an enterprise architecture plan. Additionally, newer and more powerful technologies often supersede the technologies originally proposed as solutions to problems identified in the plan. If there is no opportunity for periodic feedback and course correction, the entire architectural effort is jeopardized.

Lack of Integration and Stability

Even when individual IT solutions work, they often stand alone without being an integral part of the overall enterprise architecture. Frequently, power users bring in unsubstantiated, or "cool," technologies or application features that can destabilize the architecture. This in turn causes other technologies or application systems that could significantly improve operations to suffer, because the environment is too chaotic to introduce them effectively.

Lack of Focus on Implementation

A true enterprise architecture encompasses not just the plan, but also the implementation. Application systems must be built and infrastructure must be deployed. Everything that is defined in the architecture must be implementable within reasonable constraints. Often, however, enterprise architecture efforts are not firmly based in reality.

It is acceptable to have goals that "push the envelope" within the architecture, but the basics must come first. For example, if the architecture specifies that systems consolidate onto specific platforms, it should also put into place specific migration assistance or incentives for individual project teams to support and implement the architecture.

Failure to Deliver on Immediate Business Needs

Many enterprise architecture plans lose sight of the fact that business operations must be maintained and projects must be delivered while the architecture is under development.

If the IT department offers no assistance for the organization's business requirements, the business units will implement technology and systems on their own in an attempt to survive and thrive in any way they can. Any approach to enterprise architecture must stress the delivery of key application system functionality to meet immediate business needs during the development of the architecture.

Objectives of the MSF Enterprise Architecture Model

The MSF Enterprise Architecture Model consists of a suggested process augmented with discussions of techniques and key principles. The process is designed to quickly deliver benefits to the organization and to take advantage of rapid advances in technology and changing business conditions, by using versioned project releases. A dynamic MSF Enterprise Architecture Model facilitates learning from feedback and rational decision-making. This approach improves an organization's ability to adopt and internally apply innovative technology that provides direct business value.

NOTE

---

As an organization implements the MSF Enterprise Architecture Model, it's important to remember that this approach provides a roadmap that can and should be appropriately customized to reflect the specific needs of the organization or situation.

The MSF Enterprise Architecture Model has the following characteristics:

• Integrated Specific needs of business stakeholders, the architecture team, and individual project teams are balanced. Project teams understand both the whole system and the individual parts of the technology within their organization. Business stakeholders understand where technology objectives are aligned with business needs.
• Iterative The enterprise architecture is built through a succession of versioned releases.
• Actionable The primary goal of all enterprise architecture development is to quickly reach an interim release that can be implemented. In the meantime, project teams work to advance the architecture to the desired future state. This approach provides ample opportunity for feedback and course correction.
• Prioritized Efforts focus on where they can provide the most value to the business while improving overall IT efficiency. Architectural decisions are always framed to maintain support for critical business processes.