Chapter 3

The Value of the Business Architecture
in Strategy Execution

In This Chapter:

• Defining the Enterprise Architecture

• Defining the Business Architecture

• Business Architects

• Architecture Frameworks

• Creating the Business Architecture

• Challenges

• Best Practices

In today’s world of global competition and mergers and acquisitions, organizations are large, complex, and often in some state of chaos. Business processes and IT systems have been built from the ground up as businesses rapidly changed and evolved. As business entities have increased in complexity, they have begun to employ engineering principles to assist in managing organizational complexity and change. Engineering disciplines have historically used blueprints and architectural drawings to design and construct complex systems. To bring order to the rather chaotic business environment and to ensure that costly IT infrastructure supports the business, developingan enterprise architecture to make the components of the enterprise visible is becoming a widespread practice.

An essential element of the enterprise architecture is the business architecture, which is created and maintained by the business analyst. The business architecture provides a unified structure that guides the execution of strategy through managed change. This chapter first defines the overarching enterprise architecture, and then delves more specifically into the business sub-architecture.

Defining the Enterprise Architecture

Implementing business strategy and solving business problems are the drivers of major business change initiatives. Comparing the current and future states of the enterprise provides a common understanding of changes that the business must make to achieve its goals. As the business changes, rich pictures and textual statements embodied in the enterprise architecture makes the organization visible and enables business units and supporting IT systems to align. Architectural work captures and portrays business and technical information in an interconnected way that promotes consistency between business operations and their enabling IT products and services.

Enterprise architecture is all about understanding the complexity of the business by decomposing and documenting its components. It is widely viewed as a comprehensive framework used to align all components of an organization to its overall strategy.

Industry experts provide various definitions of enterprise architecture. The Open Group, a business and technology consortium bringing together best practices from across the industry, defines an enterprise as:¹

The Institute of Electrical and Electronics Engineers (IEEE) is an organization composed of engineers, scientists, and students that is best known for developing standards for computers and the electronics industry. The IEEE Standard 1471-2000 defines architecture as “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.”²

The Open Group contends that architecture has two meanings. One definition suggests that architecture is “a formal description of a system, or a detailed plan of the system at component level to guide its implementation.” Another definition calls architecture the “structure of components, their inter-relationship, and the principles and guidelines governing their design and evolution over time.”³

Using an enterprise architecture to address persistent disappointment in IT investments has become a significant practice within private industries and the U.S. federal government. The Open Group goes on to note the use of enterprise architecture to support IT as a key factor to business success:⁴

•    The enterprise architecture supports the business by providing technology and process structure for an IT strategy, thus making IT a strong and flexible asset that is indispensable to achieving competitive advantage.

•    The enterprise architecture provides a strategic context for the evolution of IT.

•    The enterprise architecture enables an organization to achieve the right balance between IT efficiency and business innovation.

Dennis A. Stevenson discusses the value of enterprise architecture in a paper he presented to the Department of Information Systems at the University of Cape Town in June 1995:⁵

A complete enterprise architecture encompasses both technical and business-related architectural components. A typical enterprise architecture consists of five sub-architectures: business, information, application, technology, and security. The following section discusses, in detail, the business sub-architecture, which is the business analyst’s responsibility.

Defining the Business Architecture

The business architecture serves as the overarching business model, constructed to provide a view of the business so that the other four architectures can then be designed in alignment. Also referred to as the enterprise business architecture, or the business area architecture (if its scope is one business unit within the enterprise), it defines the value streams, or processes, that flow value from the organization toits customers. The business architecture also defines the relationship of all external entities, as well as what the organization must produce to satisfy its customers and compete in the marketplace.

A website highlighting Enterprise Business Architecture: The Formal Link between Strategy and Results, written by Ralph Whittle and Conrad B. Myrick, notes:⁶

The business architecture fosters a common business and technology planning structure. It records both a current view of the business and the desired future state. The current view facilitates the management of day-to-day business operations and supports continuous improvement efforts. The future or strategic view is designed to facilitate planning for broad, radical transformation initiatives. As new business opportunities turn into proposed new projects, the enterprise architecture views are used to determine the impact of change on the business and on the IT systems supporting the business.

The business architecture helps to ensure the integration of the policies, processes, and IT systems as they change by:

•    Documenting the current state of the business

•    Developing the future state of the business to bring the strategic vision into view

•    Analyzing the gaps between the current and future states to determine the extent of change required to achieve the vision

•    Providing a context in which to assess proposed new projects

•    Helping identify which new business opportunities to pursue

Components

The business architecture consists of a set of documents, models, workflows, events, and diagrams organized to present information about the business in terms that members of the business and technical communities can understand. Components of the business architecture may vary, but they typically include descriptive documentation for the business vision, mission, strategy, functions, rules, policies, procedures, processes, organizations, competencies, and locations that together constitute the business as a system for delivery of value. The business architecture is essentially “a blueprint of how an organization’s business systems should interoperate in the fulfillment of the mission and business objectives of the organization.”⁷

Scope

The scope of the business architecture development effort depends on the availability of resources, the time allocated to complete architecture work, and the needs, complexity, and maturity of the enterprise. In small, easily understood organizations, the business architecture likely consists of a simple set of organization charts, business plans, policies, and procedures. In large, complex organizations, the business architecture might consist of the traditional documents and charts that describe the business mission, organizational structure, and policies, accompanied by abstract representations ofthe more complex components of the business. These representations take the form of models, graphs, matrices, and structured text, and they are used to depict the complex interrelationship between various components of the enterprise.

Whatever form the architectural views take, most business architecture efforts have a common goal: to bring order to the complexity of businesses today. Because businesses are undergoing massive amounts of change, the business architecture is becoming a powerful change management tool. The business architecture must not only provide structure and efficiency, but also remain flexible enough to accommodate different business strategies, functions, rules, and components—all of which seem to change constantly. The business architecture focuses on the functional aspects of the business from a number of perspectives:⁸

•    People—the human resources of the business and their knowledge, skills, roles, responsibilities, and capabilities

•    Process—the external and internal processes used by the business to flow value through the organization to the customers and, ultimately, to achieve its goals

•    Functions—the functions required to support the processes

•    Data and information—the data and information required to flow through the processes

Tools and Techniques

Determining how to develop the business architecture involves reviewing available tools to support the development, storage, presentation, and enhancement of architecture components. As with architecture methodologies and frameworks, enterprise architecture tools to support the architectural development process are stillemerging. Whether common desktop tools or powerful modeling and management tools are used, it is important to standardize and consolidate the collection of architectural drawings and documents into a single repository to support enterprise analysis. Numerous techniques are available to help architects model, store, manage, and share information about the enterprise. We present just a few.

Business Scenarios

Business scenarios are perhaps the single most important technique that can be used to develop the business architecture. Business scenarios help the architecture team identify and understand the true business needs. They can be used to depict what should happen when planned and unplanned events occur, and to help understand the magnitude of necessary changes to business processes.

Business scenarios can describe a business process or business problem; the business and technology environment; the business objective; the human resources (called actors) that execute the scenario and their place in the business model; the roles, responsibilities, and measures of success; computer actors; and the desired outcome of the scenario.⁹

Models

In addition, a variety of modeling techniques are often used to accompany the business scenarios. Models are used to capture business and technology elements in graphical form to help others comprehend business scenarios and to facilitate the validation of business scenarios.¹⁰ The following modeling techniques represent just a few of those commonly used during the development of a business architecture. Refer to another volume in this series, Getting It Right: Business Requirements Analysis Tools and Techniques, for more detailed information about models commonly used in business analysis.

•    Reference model—a structure that enables system modules and interfaces to be described in a consistent manner

•    Business process model—a network of activities that consistently and routinely produces a planned result

•    Use case model—a model that can describe either business processes or systems functions, depending on the focus of the modeling effort

•    Class model—a model that describes static information and relationships between information and informational behaviors

Bringing about large-scale business change requires attention to both the organizational and technological aspects of change. All too often, projects involving significant IT components have difficulty resolving issues involving organizational structure, processes, and people, which causes costly delays in getting the new business solution up and running and places the expected business benefits at risk. Building and maintaining the enterprise architecture ensures that significant change initiatives will focus on all potential areas of change.

Business Architects

As the business analysis practice matures, a small group of business architects, also know as architecture analysts, is emerging. Business architects are typically senior business analysts who focus—sometimes exclusively—on documenting the current and future states of the business so that everyone has a correct, accurate, and consistent view of where the business is (the “as is” state) and where it is going (the “to be” state). These business architects may also keep an eye on the work done by project analysts to ensure they are adhering to the standards set forth in the business architecture. If necessary, business architects may extract architectural components from projectsthat will change the business architecture. In addition, business architects closely monitor changes to the business vision, strategy, and goals to ensure the future state business architecture accurately represents the future vision.

Meta Group, a provider of information technology research, advisory services, and strategic consulting, predicts that by 2008, 40 percent of enterprise architects will have primary expertise in business strategy or process engineering and may no longer reside under the IT umbrella. This reflects the rising importance of business architecture and the need for a more balanced skillset (beyond technical architecture). Scott Bittler, a vice president at Gartner Research who specializes in enterprise architecture, IT strategy, and portfolio management, contends that:¹¹

According to Bittler, effective business architects have key characteristics; business architects are:¹²

•    Enthusiastic—they have a passion about their work.

•    Technology-agnostic—they are vendor/product-neutral and maintain an objective perspective.

•    Broadly knowledgeable about technology—it is important that an architect understand enough about the broad range of technologies to be able to engage in discussions with technical experts.

•    Well-respected and influential—architects need the support of senior IT and business managers, and they need the ability to influence those managers and the IT organization at large.

•    Able to represent a constituency—members of an business architecture team have a constituency—the part of the organization they represent in the process.

•    Articulate and persuasive—business architects must spend substantial time communicating and educating. Therefore, it is important that they have the skills to clearly communicate ideas in a persuasive, compelling manner.

•    Persistent—business architects are strategically inspired change agents. People tend to resist change, and this is certainly true when changes are instituted by architecture-related efforts. Therefore, it is critical to be persistent in pursuit of positive transformation.

•    Good at “helicoptering“—business architects have the rare ability to “zoom out” to discuss business strategy with the CEO and a minute later, “zoom in” to discuss complex details with a technical expert without getting lost.

•    Strategic—architects must be strategically driven, but they should also balance strategy with effective, tactical operations. Strategic ideas contribute to defining or fulfilling the transformations described in the business strategy of the organization, while tactical operations execute those ideas.

•    Focused on what is truly best for the organization—limited personal agendas.

•    Knowledgeable about the business—business architects are leaders, and therefore they must have a strong interest in and understanding of the business and its strategic direction, dysfunctions, and strengths.

•    Able to facilitate—business architects frequently facilitate content development meetings or lead subcommittees, which makes effective group facilitation skills important.

•    Able to negotiate—it is important to seek the win-win positions/solutions on issues when developing architecture content. Effective negotiation skills are invaluable for resolving contentious situations.

•    Focused on the long term: The idea is to take a series of short-term steps that not only deliver immediate value but also contribute toward achieving a long-term vision for the enterprise. Focus on identifying and driving toward that long-term goal.

•    Able to lead—architects should take the initiative to persuade, inspire, motivate, and influence others. They should also focus on attaining a high level of stakeholder buy-in for important decisions.

This list doesn’t include a strong understanding of enterprise architecture as a key characteristic of business architects per se, because those who possess all or most of these traits can learn architecture best practices quickly and can rapidly become effective architects.

Architecture Frameworks

Because the business architecture is a sub-component of the larger enterprise architecture, it is prudent to use common frameworks, tools, and techniques to develop the subsets of the enterprise architecture. Engineering architectural approaches are emerging as a useful method for capturing complex knowledge about organizations and technology. Enterprise architectural approaches range from broad, enterprise-focused approaches to scaled-down efforts aimed at specific domains.

Not every business requires a comprehensive business architecture, and those that do may not require all possible views or representations of the business.¹³ Therefore, it is important to determine the specific requirements that are driving the business architecture effort, who intends to use the resulting architecture, and how. It’s important to understand the expectations of both the business and the IT groups.

Once user requirements are fully understood, documented, and approved, the business architect determines which architectural framework and corresponding tools and techniques to use to create the architecture. Three common architecture frameworks include the Open Group Architecture Framework, the Zachman Framework for Enterprise Architecture, and the POLDAT Framework for Business Process Reengineering. Each framework is different and has associated pros and cons.

The Open Group Architecture Framework

The Open Group Architecture Framework (TOGAF^™) is a valuable resource for businesses embarking upon the development of an enterprise architecture.¹⁴ It consists of three elements: the TOGAF^™ Architecture Development Method (ADM)—a description of the processes and techniques needed to develop an enterprise architecture; the Enterprise Continuum—a virtual repository of architectural assets from which to choose; the TOGAF^™ Resource Base—a set of guidelines, templates, and other reference information to help architecture analysts use the ADM.

For the organization that is new to enterprise architecture, the TOGAF^™ set of tools, templates, and guidelines provides an invaluable place to start. TOGAF^™ resources are available for free and may be used by any organization wishing to develop an enterprise architecture for internal use.

The Zachman Framework for Enterprise Architecture

Organizations typically use a defined framework that provides a common classification scheme for descriptive representations of an enterprise. One such framework that both public and private organizations have adopted is the Zachman Framework for Enterprise Architecture. Indeed, the United States Federal Chief Information Officers Council has adopted this framework as part of the Federal Enterprise Architecture Framework Standard.¹⁵ The purpose of the Zachman Framework is described below:¹⁶

The framework has become widely employed because it provides a comprehensive view of business domains and their information characteristics. The value of this framework is in its integration of key elements; it provides a common language and a structure for describing a business entity. “Integration does not happen by accident,” says John Zachman. Without a unifying framework, an organization may be a disintegrated, poorly functioning enterprise, fraught with redundancies, inefficiencies, and interoperability issues. The Zachman Framework (Figure 3-1) is complex and comprehensive.¹⁷ It is presented in a matrix format where the columns represent the interrogatives, or the questions that must be answered to build a business component as part of the architecture (e.g., what, how, where, who, when, why). The rows describe the perspectives of managers of the enterprise: scope, business model, system model, technology model, and detailed representations.

Figure 3–1—The Zachman Framework

Copyright © 1987 John A. Zachman. Reprinted with permission.

The POLDAT Framework

An alternative, simpler structure that is often used in business process reengineering projects is the POLDAT Framework for Business Process Reengineering, referred to as the hexagon of change or the six domains of change.¹⁸ This framework provides an easily understood approach to defining the scope of business transformation initiatives. The model develops artifacts (e.g., documents, tables, matrices, graphs, models) and organizes them into the following domains:

•    Process—the business processes that flow value from the organization to the customer. What are our current processes, and do we have opportunities to improve those processes? What is the desired state of business operations?

•    Organization—the organizational entities that operate the business processes, including the management teams, staff positions, roles, competencies, knowledge, and skills. What changes in culture, capabilities, competencies, teams, organizations, and training are needed to accomplish the necessary business change? What support systems are needed to accept the new business solution and ensure it operates efficiently?

•    Location—the location of the business units and other organizational entities, such as call centers and distribution centers. What effects will the change have on geography, people, infrastructure, data, and applications? What physical facilities are needed to deploy the change?

•    Data—the data and information that are the currency of the organization, flowing through the processes to accomplish the business functions. What new information content and structures are needed to meet the strategies? What data security is needed?

•    Applications—the IT applications that enable the business processes to operate efficiently and provide decision-support information to the management team. Which applications should be changed and/or developed? How will the applications be integrated?

•    Technology—the enabling technology that supports the operation of the processes and applications. What hardware, system software, and communications networks are needed to support the business? How can we leverage existing and emerging technology?

In the early stages of an architecture effort for a major project, each domain listed above is defined as either in scope or out of scope. In this framework, artifacts in the process, organization, and location categories constitute elements of the business architecture. When they are accompanied by artifacts in the data, applications, and technology categories, the entire enterprise architecture is complete.

The value of this framework lies in its simplicity. Organizations embarking on the first iteration of their enterprise architecture would do well to first use the POLDAT framework and then move on to a more comprehensive approach if appropriate.

Creating the Business Architecture

One approach to building a business architecture involves the following steps:

1. Build a core architecture team

2. Determine the sponsor, business drivers, and scope for the business architecture effort

3. Plan the business architecture activities

4. Create the architectural components

5. Conduct a quality review and baseline the business architecture

This is not a mandatory process for creating and maintaining the business architecture. The process steps and the sequence of activities may vary considerably depending on the drivers of the architecture effort. For example, some enterprises begin by collecting all descriptive information relevant to the current state of the business, identifying gaps, and developing documents, lists, or graphics to fill in the gaps. Others begin by developing the architecture for the desired future state of the enterprise.

Build a Core Architecture Team

As the business architect embarks upon the effort to create and maintain the business architecture, it is wise to first build a core team of subject matter experts (SMEs) to ensure that the models and documents represent the collective wisdom about the organization from various business and technical perspectives. We recommend the following experts:

•    Project manager—involve an experienced project manager to help develop the project scope and prepare time and cost estimates.

•    Business visionaries—involve business SMEs from all areas of the organization that are affected by the effort. Recruit creative thinkers—futurists, if possible.

•    Business architect—involve an experienced architect to provide oversight and advice during the effort.

•    Technology architect—involve an experienced IT architect to ensure alignment between the business and technical architectures.

Collaborating with these professionals to plan, create, refine, and determine the business architecture structure can greatly smooth the progress of the architecture project. This team can estimate costs and resource requirements, identify key stakeholders, get the right people involved in architectural activities, facilitate business architecture design, development and review meetings, and negotiate decisions.

Determine the Sponsor, Business Drivers, and Scope of the Business Architecture Effort

The business analyst should develop a description of the business entities the architecture is focusing on to create a high-level understanding of the current state of the business and to begin understanding the scope of the effort.

The business analyst should collect and review all existing documentation about the business entity under consideration. The scope and level of detail needed for the current-state description depend on the business drivers for the creation of the architecture, and on whether current architectural descriptions already exist. At this point, the goal is to create a matrix of architectural assets that will meet the immediate business need and identify which business architecture models and documents, also known as building blocks, already exist and which need to be updated or created.

The business analyst should prepare a list of the key stakeholders of the initiative and conduct a stakeholder analysis. Enlist the help of a sponsor and define their expectations for the business architecture effort. Review the list of architectural assets with key stakeholders and the sponsor to gain consensus on the scope of the effort. Include stakeholders that will use the architectural models and documents (e.g., business analysts, project managers, IT architects and developers, business representatives) to ensure they are complete and fit for use.

Plan the Business Architecture Activities

Once the sponsor, key stakeholders, and scope of the architectural effort are understood, enlist the assistance of a senior project manager and an experienced architect to help plan architecture activities. It’s possible to manage the creation of the business architecture as a standalone project, or to manage those activities as part of a larger project. Follow these steps to plan the architectural effort:

•    Select what is referred to as relevant business architectural viewpoints—lines of business or business units (e.g., operations, management, financial, engineering). These viewpoints must be in the project’s scope so the architect can document the organization’s key capabilities.

•    Determine the appropriate framework and approach to building the architectural assets.

•    Identify appropriate tools and techniques to use to capture, model, and analyze architectural models and documents. Depending on the degree of sophistication warranted, these may include simple documents and spreadsheets or more sophisticated architectural tools.

•    Determine which architectural assets or components (e.g., documents, graphics, matrices, drawings) to create or update. Limit the set of assets that will be produced to reduce the risk of “analysis paralysis.” Not all artifacts are produced for every effort.

•    Determine how to store the artifacts. This may involve creating a repository to serve as the archiving mechanism.

As plans emerge, a number of considerations must be taken into account. The plans in place must meet the business need. Ensure that the approach will support business planning activities and helpdetermine the scope of change initiatives. This decision will help determine the level of detail needed when building the architecture.

Comply with—or develop, if nonexistent—organizational standards for each of the architecture’s deliverables. Developing architectural standards can be a difficult and time-consuming task. It’s also necessary to decide whether to build the architecture using a top-down holistic approach or a bottom-up, change-initiative-driven approach that creates only a limited set of architectural models and documents to satisfy a particular project’s needs. Limit the size and complexity of the architectural effort by creating or maintaining only the components necessary to meet the needs of the business drivers. In addition, decide whether to build only the future state (to-be) model, the current state (as-is) model, or both. This could depend in part by how much documentation on the current state already exists.

Create the Architectural Components

Once the plan has been drafted and approved, and funding is available, the architecture team then creates the documents and models that describe the core organizational components. As noted, these may include some or all the following elements of the business model: vision, mission, strategy, goals, themes, objectives measures, rules, processes, features, functions, organizational structures, roles, locations, competencies, data requirements, business and operational plans, annual reports, and the like. Once again, create only the artifacts that are required to meet the specific business need to avoid investing too heavily in building the business architecture.

Review the architectural components to ensure they are complete. It is helpful to build a requirements traceability matrix to ensure that architectural components meet the business need and to validate that all requirements within the scope of the architecture effort have been addressed.

After creating the set of architectural components, identify those that are likely to be reused by other projects (e.g., working practices, roles, business rules, business relationships, job descriptions) and publish them for the appropriate stakeholders. Archive all architectural components in the architecture repository. Prepare the final architecture report documenting the rationale for structure and composition, and other decisions (e.g., whether to build or not to build certain elements of the architecture).

Conduct a Quality Review and Baseline the Business Architecture

A baseline establishes a starting point or condition for future changes. Review the architecture artifacts, ensuring the requirements for this effort have been met. In addition, validate each artifact to determine not only that it is fit for use to fulfill the immediate need, but also to support subsequent work in the other architecture domains, and to ensure compliance with organizational standards. At the conclusion of the review, refine the business architecture as necessary to close any gaps uncovered during these final quality reviews. As a final step, review and refine business performance measures, ensuring performance metrics are defined for all elements of the strategic scorecard.

Challenges

Introducing an enterprise architecture as a means to overcome the alignment deficits between business and IT units is an arduous task. It involves resolving differences in interests, perceptions, and goals. Business architects must overcome some unique challenges to successfully develop the business architecture:

•    If the organization is not mature enough to develop a business architecture, there may not be enough funds or resources for the effort. The business architect should attempt to involve stakeholders, offering a considerable amount of educationabout business architectures if necessary, and employing sophisticated influence strategies to enlist adequate support for the effort.

•    The IT organization may believe that it owns the business architecture because it has the modeling skills, thus preventing proper business ownership. This may result in a business architecture that does not truly represent the current or future state of the organization from a business perspective.

•    Strategic plans, strategic goals, and/or the current-state business documentation don’t capture the future strategic direction in enough depth to create the future-state architecture.

•    There are no senior business analysts that have the knowledge and skills to create and maintain the business architecture.

Best Practices

What makes a successful business architecture endeavor? Lessons learned during previous architectural effort offer insight. The following success factors may come into play, depending on the culture and maturity of the organization:

•    Using a standard framework (e.g., POLDAT) and tool set

•    Requiring standard business architecture deliverables for all major change initiatives

•    Requiring skilled architects to report to a central group (e.g., PMO, center of excellence)

•    Focusing on the approach that will bring the most value to the enterprise

•    Performing tradeoff analysis to resolve any conflicts among the different views

•    Validating that the business architecture initiative supports overall strategic goals, organizational principles, and short-term objectives and constraints.

Endnotes

1. The Open Group. The Open Group Architecture Framework, Frequently Asked Questions. Online at http://www.opengroup.org/architecture/togaf8-doc/arch/toc.html (accessed September 5, 2007).

2. Institute of Electrical and Electronics Engineers. IEEE Recommended Practice For Architectural Description Of Software-Intensive Systems, 2000. Online at http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?isnumber=18957&arnumber=875998&count=1 (accessed September 5, 2007).

3. The Open Group. The Open Group Architecture Framework, Frequently Asked Questions. Online at http://www.opengroup.org/architecture/togaf8-doc/arch/toc.html (accessed September 5, 2007).

4. Ibid.

5. Dennis A. Stevenson. Presentation to the Department of Information Systems, University of Cape Town, June 1995. Online at <users.iafrica.com/o/om/omisditd/denniss/text/eapositn.html> (accessed October 11, 2006).

6. Ralph Whittle and Conrad B. Myrick. Enterprise Business Architecture: The Formal Link between Strategy and Results, 2005. Boca Raton, FL: CRC Press. Website highlighting the book is online at www.enterprisebusinessarchitecture.com/index.html (accessed September 2006).

7. Michael Kull and John Zachman. Managing Integration in a Federated Architecture Environment, 2003. The Intervista Institute, Inc. Online at http://www.intervista-institute.com/articles/zachman-by-kull.html (accessed September 2007).

8. The Open Group. “Developing a Business Architecture View,” TOGAF™ 8.1.1 Online, 2006. Online at www.opengroup.org/architecture/togaf8-doc/arch/chap31.html#tag_32_08 (accessed October 11, 2006).

9. Ibid.

10. For more information on business modeling, visit the Business Process Management Initiative website at www.BPMI.org. The Business Process Management Initiative is an organization that defines standards for business process modeling, including the language used to specify business processes, their tasks/steps, and deliverables.

11. Scott Bittler. Characteristics of an Effective Enterprise Architect, 2005. META Group. Online at http://www.itworldcanada.com/Pages/Docbase/ViewArticle.aspx?ID=idgml-3e21a390-4090-42f5-9279-23970f2ec7fe&Portal=
1fa35bf9-d296-4571-8fff-c665a851ec1d&
ParaStart=15&ParaEnd=30&direction=prev&
Previous=Previous (accessed April 18, 2006).

12. Ibid.

13. Dennis A. Stevenson. Presentation to the Department of Information Systems, University of Cape Town, June 1995. Online at <<users.iafrica.com/o/om/omisditd/denniss/text/eapositn.html> (accessed October 11, 2006).

14. The Open Group. “Developing a Business Architecture View,” TOGAF™ 8.1.1 Online, 2006. Online at www.opengroup.org/architecture/togaf8-doc/arch/chap31.html#tag_32_08 (accessed October 11, 2006).

15. The Chief Information Officers Council. Federal Enterprise Architecture Framework, Version 1.1, September 1999. Online at http://www.cio.gov/Documents/fedarch1.pdf (accessed September 2007).

16. John A. Zachman. The Zachman Framework for Enterprise Architecture, 1987. Pinckney, MI: The Zachman Institute for Framework Advancement. Online at http://www.zifa.com (accessed April 17, 2006).

17. Ibid.

18. Computer Science Corporation introduces its framework methodology on its website at http://www.csc.com/solutions/knowledgemanagement/
mds/mds122/212.shtml (accessed September 2007).