This book is about enterprise architecture (EA). To paraphrase the IEEE definition, an EA, or more properly, an EA description, is a representation of the components and their relationships, the structure and the behavior of an enterprise, and the evolution of these elements over time. An EA is created to support planners and decision-makers in aligning the processes and technical infrastructure of the enterprise with the enterprise’s business strategy. An EA provides the enterprise business context that supports the decisions about what processes, systems, and technologies should be developed or acquired to achieve the enterprise’s strategic goals and objectives. So, EA informs and precedes systems engineering and its representations are distinct. Systems engineering is concerned with the building of solutions and draws context and constraints from EA. The EA also provides the information on the overall integration of the enterprise’s systems and the orchestration of system development projects. EA and SE interface with each other and are both critical parts of organizational transformation. EA models and artifacts are sometimes referred to as conceptual blueprints, whereas SE models are more detailed representations for the construction of solutions the EA identifies. (Both EA and SE are complemented by the disciplines of program and project management.)

Today, the discipline of EA is multifaceted and interacts with multiple other disciplines, ranging from business, management, IT, and systems engineering, to the social sciences. It is taught by a number of training organizations as well as academic departments. In addition, a growing number of universities offer certifications and professional master’s degrees in EA in the United States, England, and Australia. In contrast to many professional certifications, there is no single exam across the industry and discipline; rather, various training organizations provide their own branded forms of certification. For this reason, many enterprise architects hold several simultaneous EA certifications from different sources, including the Federal Enterprise Architecture Certification (FEAC) Institute (in both Federal Enterprise Architecture Framework, or FEAF, and Department of Defense Architecture Framework, or DoDAF) in conjunction with California State University, East Bay; The Open Group Architecture Framework (TOGAF); Zachman; the Enterprise Architecture Center for Excellence (EACOE); Pragmatics; and others. In addition, there are certifications and courses from universities including the National Defense University, Penn State, Carnegie Mellon University Software Engineering Institute, Kent State, National University, Griffith University, and more.

This book, as part of the McGraw-Hill All-in-One Series, provides exam preparation relevant to each of these certifications and is also a practitioner’s reference guide addressing different frameworks, types of models and artifacts used, and differences in terminologies and EA development methodologies employed. Our intent is to provide generic information relevant to any certification or academic course examination on enterprise architecture.

Although there are differences in the certifications and course curricula and the language and dialects of EA, we provide an orientation toward EA that is analogous to what sociologist C. Wright Mills attempted in his classic The Sociological Imagination (1959) for the social sciences. He advocated a theoretical intentional stance providing a vision or way of looking at the world that characterized a discipline. Taking this analogy, we advocate what might be called an Enterprise Architecture Imagination or, better, an Enterprise Architecture Attitude proffering a vision that underlies the various forms of inquiry about enterprises and their respective architectures relevant to all training and educational programs. A similar approach to business strategy and strategic planning was recommended by Kenichi Ohmae in his seminal book, The Mind of a Strategist (1991): “Recognize that strategy begins with analysis. The strategist analyzes a set of facts, in the sense of taking the set apart, and then reassembling it in an order that makes sound strategic sense. The purpose of strategy is to maximize one’s advantage. On a battlefield, this means picking the right place to fight, the right time to attack, the right time to retreat—weighing and re-assessing as circumstances change, but always with maximum advantage in mind. Strategy is intuitive, but it is also analytical; it is analytical, but also intuitive.”

Enterprises have intuitive patterns that are variously called business models, operating models, technology models, service concepts, business concepts, etc. (Hohpe and Woolf, 2003) Once having adopted this EA attitude stance, most architects are successful at passing the varying certification examinations and academic courses as they grasp core concepts and common truths despite the varied languages and techniques used to express them!

For instance, one of the authors with EA experience was among the first to get certified in TOGAF 9, when it was first introduced at The Open Group conference in San Diego in 2009. The Open Group offered volunteers willing to try out the exams a full day of testing; beginning with the TOGAF 8 transition to TOGAF 9 exam, followed by the TOGAF 9 Foundation, and then the TOGAF 9 Certification exam. Although the TOGAF 9 publications were not generally available at that time, he and others passed their TOGAF 9 certification based on their having what we call here an “EA mindset.”

A goal of this book is to introduce and reinforce the EA attitude by providing practitioners with a full set of case study–based examples of the kinds of artifacts, products, and models that constitute an architecture and by highlighting EA as an approach that supports management decision-making and organizational transformation efforts. With the EA attitude and the basic concepts and patterns of EA, readers will have the requisite background knowledge and confidence for any type of certification examination.

We do not claim that this book will replace any specific training, educational program, or detailed treatise on any one specialized architecture topic such as process modeling. However, we attempt to clarify and cross-reference different frameworks and approaches to EA to emphasize the “enterprise architecture imagination” that underlies any and all programs, and in so doing enable the enterprise architect to leverage the wealth of knowledge to satisfy certification and course exams on the basics of EA. This includes the following:

• Modeling techniques

• Architecture artifacts, building blocks, and deliverables

• Business strategy

• Business pattern

• Governance

• Mined information about primary drivers for businesses such as laws, policies, and regulations for government and industry

As authors of this practitioner’s guide, we emphasize how our approach can be used to reduce the time to a first draft of the EA. Too often, especially in project-inspired attempts at developing the EA, schedule urgency far outstrips the need for detailed EA development, and many EA developments are too little, too late. This book shows you how to leverage knowledge to reduce the time drastically to understand and communicate the anatomy of the enterprise.

Today: Current Enterprise Challenges

In today’s environment, enterprises both large and small have become more and more dependent on information to fuel and information technology to propel their businesses. These enterprises face a number of challenges that affect their planning environment; their ability to make decisions; their ability to assess, evaluate, and prioritize many alternative proposals; and their ability to face new pressures from regulation, globalization, intense competition, and dramatic changes in their business environments. Many enterprises have not been able to address these challenges successfully as the evidence of a long list of failed multimillion-dollar IT initiatives seems to convey. The complexity and scale of some of these IT projects, though comparable to large civil engineering works or the building of airframes, do not appear to have benefited from a holistic, structured planning approach combined with an integrated, well-managed implementation approach that mitigates risks and results in good design tradeoffs. In short, these enterprises need a new approach for supporting their decision-making in both strategic and investment planning to manage the complexity and scale of the implementation. A systematic application of architecture, which is such an approach, is therefore a major subject of this book.

Enterprises face many challenges today, including the following:

• Failure of large IT projects. Failure results not only in the inability to support the business but also robs the enterprise of resources for future opportunities, forces the need to keep systems and solutions built on obsolete or aging technology, and introduces new vulnerabilities.

• Faster tempo of operations, which results in the need to detect and eliminate latencies and reduce the time of delivery to the customer. Military operations, for example, need to reduce latency in the delivery of intelligence, imagery, and other situational assessment and operating picture elements to support better operational planning and execution capabilities. Often in military operations, the ability to act is predicated on the availability of accurate and timely situational information. The ability to collaborate and cooperate is predicated on the establishment of a common operating picture.

• Mergers and acquisitions, where new parts of the IT environments acquired from merged enterprises increase the diversity in standards, information representations, architectures and equipment, and operational costs. Mergers also have cultural implications, and the way forward involves resolving inconsistencies, mismatches, gaps, and consolidations in business processes as well as in IT.

• Globalization, where parts of the workforce are located in different regions of the world. Workers bring their own cultures, languages, and local constraints on power, equipment, communications, and other factors. Operating a global enterprise involves mediating among cultures, languages, mindsets, work practices, and world views.

• Changing workforce skills and environments driven by new ways of interaction and collaboration and increased automation and use of computers, applications, information, and networking. With new technologies comes the need for new skills. Existing skills become obsolete or less useful than in the past, while the need for new skills becomes imperative. Understanding, representing, and forecasting skill needs in the face of constantly changing labor needs is imperative.

• Increasing expenses in information technology as a whole, despite dramatic decreases in per-unit cost of processing and memory. Expenses can increase as a result of labor costs, the need to control obsolescence, the evolution of standards and technologies, and the need to constantly increase the speed of processing and increase the availability of memory. Though the per-unit cost of information technology investment is decreasing year after year, the scope and scale of the systems keeps increasing, which means enterprises do more and more with their IT every year at significant expense. One of the big disrupters is the advent of cloud technology that promises elasticity, demand computing, expensing rather than capital investment, and the opportunity to offload non-core IT assets to service providers and use IT as a service.

• Increases in complexity and scale of IT projects. Complexity includes scope and reach and the consequent need for orchestrating work outputs of large numbers of professionals located all over the globe to complete projects successfully.

• Inability to fully assess impact of complexity and scale at the planning or at the implementation level.

• Rampant adoption of technology driven by marketplace competition and vendor push as well as the pressure to align to contemporary standards. As customers and consumers get used to advanced technology in their products and services, they begin to demand more from their suppliers. Enterprises, including federal government agencies, have had to retrofit or adapt their legacy systems to meet this new demand.

• Rampant outsourcing, based on financial analyses, competitive price pressures, and the current enterprise focus on the core mission and the decision to outsource all non-critical supporting services. Outsourcing brings its own challenges related to lack of day-to-day control and the reliance on service agreements to enforce contractual obligations.

• Dramatic opportunities posed by evolving IT architecture style that change the way systems are built and introduce new planning and transformational challenges. Changing to a new style of architecting, such as service-oriented architecture and cloud computing, can change the way business is performed, often disrupting existing methods of connecting supplier to consumer or customer.

The Case for Enterprise Architecture

The famous Finnish architect Eero Saarinen recommended a design principle: “Always design a thing by considering it in its next larger context—a chair in a room, a room in a house, a house in an environment, an environment in a city plan.” This design principle reminds us that changes to the enterprise, such as changes in systems, business processes, or organizations, need to be considered in the context of the entire enterprise, including the enterprise strategy, goals, and objectives. Given this design principle, developing an EA is an exercise of common sense.

What are some of the key high-level concepts of an enterprise architecture?

• An enterprise architecture has three components: a current or as-is understanding of the enterprise, a target or to-be vision of the enterprise, and a transition plan.

• An enterprise architecture needs to provide traceability or line of sight from the IT infrastructure through the business processes and organization to the strategy, goals, and measurable objectives of the enterprise. In other words, the EA shows how well the IT infrastructure and business processes align with the enterprise strategy. Line of sight is essential to provide governance and course correction.

• An enterprise architecture needs to include the artifacts and models that can address the issues or expected problems the enterprise is facing.

• An enterprise architecture can focus on different levels of the enterprise. The enterprise may need multiple levels of architecture to understand and resolve its problems. A common set of levels of architecture are Enterprise Level, Segment Level, and Solution Level.

These concepts and some of the challenges they help address are discussed next.

Three Components of an Enterprise Architecture

Enterprises are constantly transforming, either proactively as part of a planned improvement, or reactively, struggling and kicking as a response to changes in environment or competition. In either case, any successful transformation is predicated on the following:

• A clear understanding of the current state, which we call the baseline or as-is state. This understanding needs to be documented and based on verifiable fact, not supposition.

• A clear understanding of the objective, or target state, which we call the to-be or target state. The to-be state of the enterprise must also be represented in the same dimensions, artifacts, and models as is the as-is state. From this representation comes an understanding of what remains the same, what cannot change easily or must stay, and what must change.

• A clear transformation plan/roadmap that will transform the enterprise from the as-is state to the to-be state. This plan requires a timeline that is acceptable within the window of change; otherwise, you risk a transformation that is too late, usually calling for enterprise triage measures. The roadmap will generally consist of a number of concurrent initiatives or projects that must all support one another and join together to provide the net transformation effect that the enterprise desires.

Even this simple concept can address many of the challenges identified. In all cases, having these three components of the EA can boost the chances of successful transformation if used as the basis of communication and buy-in for all the parties involved.

IT Failures

You need a good understanding of the current state of the architecture to understand the impact of proposed changes on the enterprise, not only in terms of process and IT but also in terms of the impact on enterprise personnel, their required skills, and their organization. Some planners and managers don’t want to spend time and money on developing this “as-is” understanding of the enterprise, since this is something they will be changing. Yet some of the most expensive IT system failures have resulted from attempts to install enterprise resource planning (ERP) systems without any understanding of the complicated nature of the enterprise’s existing payroll processes. ERP systems need to be customized to support the business rules of the enterprise. If you don’t know the number of rules that need to be addressed, you won’t be able to correctly estimate to cost of customization or the length of time it will take to perform the customization process, leading to potentially uncontrolled cost and schedule overruns. In fact, if you don’t understand these business rules, you won’t be able to customize the ERP system successfully and the effort will be a failure.

Other expensive failures have resulted, at least in part, from the failure of planners and management to understand the impact of the proposed changes on the existing workforce or their resistance to change. For example, if operational workers discover that the new process or system supports only part of their job and leaves them struggling to get through their workload with two unintegrated systems that require duplicated effort, they may refuse to use the new system and the transition effort with fail. The importance of getting buy-in on changes from all affected stakeholders cannot be underestimated.

Mergers and Acquisitions

If both of the merging enterprises have an EA, then the as-is component of each architecture can be used to identify disjoints in policy, process, and IT infrastructure. Given the disjoints, a vision of the merged enterprise and a potentially phased transition plan can be developed. Given the existing EAs, this planning process may not take a long time, and, done correctly, it will ensure that valuable enterprise assets, such as critical business data, are not lost in a rush to consolidate. The new vision and transition plan can be communicated to the new management and the employees and used to get buy-in. Clashes in corporate cultures can be identified and reasonable plans made to resolve them. However, changes that mean lost jobs are always resisted and have to be handled carefully.

Globalization

An as-is architecture identifies current operating requirements and documents existing processes, business rules, and aspects of corporate culture. For enterprises thinking of global expansion, the underlying assumptions of the work environment need to be explicitly documented. This information can be used to perform risk analysis on the expansion into new global regions and to develop mitigation strategies. The as-is and to-be architectures aid identification of potential conflicts with new culture, languages, mindsets, work practices, and world views.

Some IT failures have resulted from failing to recognize the difference in communications and electrical power stability in areas of the world where systems installations are planned. One U.S. agency developed an online timecard system and tested it in a lab located within the United States, where electrical power and communications are usually stable. They forgot that in many other “austere” locations where the system would be installed, communications and electricity availability are unstable and unpredictable. Needless to say, the system had to be scrapped in those locations.

Failure to understand differences in laws and regulations, such as privacy laws, in overseas areas have also led to serious IT problems.

Off-loading Non-core Assets, IT as a Service, and Outsourcing

Careful analysis of the as-is and to-be architectures in conjunction with the transition plan can identify risks and issues with off-loading non-core assets, treating IT as a service, and outsourcing. The usual issues to consider are the availability and control of critical business information, fallback plans if service providers fail or payment disputes arise with service providers or outsourcing contractors, and security, as well as the impact on current business processes and personnel in the face of these types of changes.

New Styles of IT Architecture

Frequently, when an IT department sees new IT architecture technologies that promise performance or cost improvements, the department lobbies for permission to employ or install these new approaches. However, with the EA approach, a new to-be architecture reflecting the new IT infrastructure will need to be developed together with any changes in the current business processes and organizations that result from the adoption of the new IT architecture. Then the new to-be architecture and transition plan will need to be analyzed to determine whether the new IT architecture will actually bring the benefits promised in terms of improved business performance and cost. It may be that the new IT architecture does not really provide much benefit to the enterprise or that the new architecture must meet certain requirements or criteria before its use will be beneficial. EA evolved to combat this expensive tendency to adopt new technologies for technology’s sake.

Alignment

If an enterprise has an as-is architecture with good performance measures and current measure values on its business processes and IT infrastructure, then the line of sight that the architecture provides from infrastructure to strategy gives the enterprise a perfect model for identifying latencies and their probable causes. When the time to delivery needs to be decreased, many enterprises simply attempt to add more automation and computer support. However, in some cases, it is the business processes that are broken and no amount of additional automation will fix the problem. The business processes and organizations need to be optimized and then new IT support provided to meet the desired business performance requirements. Implementing change in business processes and organizations can be tricky; if a set of middle managers perceive that their “turf” is being impacted or their importance in the management chain is being decreased, they will band together to resist the changes and derail the improvement effort.

The case of the “common operating picture” is, in fact, an example of a need to change the business process. If an EA exists for each of the organizations that need to share a common operating picture, then an analysis of all the relevant as-is business processes and the data they use should reveal the data needed in the common operating picture. Once the common operating picture is defined, the business processes need to be restructured to use and update the common data source and, finally, the IT adjusted to support the new business processes.

A Rich Set of Artifacts and Models

An enterprise architect needs a rich and flexible set of artifacts and models to document an enterprise’s architecture. The set needs to be able to capture data to support decision-making with respect to the questions and issues of the architecture stakeholders. One of the areas that must be addressed is the tracking of emerging technologies, evolving standards, and marketplace trends and their potential impacts on the IT infrastructure and workforce skills of the enterprise. Comparison of the as-is architecture to the to-be architecture shows changes in business processes resulting from the expected inclusion of new technologies and standards and highlights the new skills and organizations that may be needed if the new to-be architecture is adopted. The new IT base and changed business processes and personnel needs can be checked for alignment with enterprise strategy, goals, and objectives. A return-on-investment analysis can determine whether the new technology is worth the overall investment.

The tracking of marketplace trends along with other emerging technologies must be included. Sometimes unexpected changes in the marketplace, such as the emergence of a popular cell phone, can cause major impacts on an enterprise’s plans. With an EA in place, an enterprise can perform rapid “what if” analyses to understand potential impacts and to make corrections in everything from its strategy to its IT base and security approaches.

Levels of Architecture

Enterprise architectures can be developed at many levels of abstraction. If increasing complexity and scope of IT projects drive a need to orchestrate work outputs from multiple sets of widely separated workers, then two levels of architecture can be employed. There should be one lower level of abstraction architecture for each project. The focus of these architectures should be on the development and delivery of the work products. A single higher level architecture can focus on the orchestration of these work products. This higher level architecture documents dependencies among the work products and how they fit together to provide functionality to operational organizations. Schedules from the projects are compared and analyzed to ensure that work products from one project that are input to work products from another project arrive in good time and that the delivered functionality is completed in a timely manner to avoid gaps in functionality coverage.

Similarly, if complexity and scope are impacting planning and implementation, several levels of architecture need to be used to separate detailed concerns from higher level issues.

Enterprise Architecture Skills and Expertise

People entering the EA field come from a variety of backgrounds. Many come from systems and software engineering, because EA impacts and interacts with these disciplines and many of the modeling techniques used in the various architecture frameworks are familiar to them. However, managers and executives are also interested in the field because they want to understand firsthand and directly exploit the information available for management decision-making that is available from an EA. Managers will also need to manage EA program offices and the development, sustainment, and governance of the EA.

An EA development team also uses expertise from a variety of other disciplines, including business and social sciences. Business experts are key to providing both generic and specific business knowledge to domain-specific architectures. Those with a social science background are needed to understand organizational and cultural issues such as corporate culture and emergent groups that are resistant to change and can seriously impact the success of transformations.

An important skill needed by all members of the architecture team is the ability to communicate ideas and concepts, both to other team members and to architecture stakeholders. The medium of communication within the team is a uniform set of organized artifacts and models provided by an architecture framework. The architecture framework provides the language used to capture and document the enterprise’s architecture. While specific modeling experts on the team may develop the artifacts and models, all members of the team need to understand these artifacts and models and be able to use them to “tell the story of the enterprise” and the transformation that is being planned for it. The architects need the analytical skills to understand how to use the architecture framework artifacts and models to address stakeholder questions.

Enterprise architects also need to be able to translate the framework artifacts and models into reports, presentations, simple graphs, or other representations that are easily understandable to the architecture stakeholders and enterprise decision-makers who need the input from the architecture. Architects also need to work with business, simulation, and performance analysts to provide the architecture information they need to complete their work. Example types of business analysis that need architecture input include business case analysis, return on investment, and activity based costing.

So, enterprise architects, regardless of background, need the following skills:

• Good communication skills

• Good analytical skills

• Good understanding of the architecture framework they are using

Since communication skills and analytical skills are difficult to teach and are gained mainly through experience, most EA education focuses either general concepts or on architecture frameworks.

Architecture Frameworks

The main tool of EA is the architecture framework. The framework establishes a common vocabulary for architecture elements and defines an organized set of artifacts and models that use these architecture elements. Further, these artifacts and models should be integrated—that is, the artifacts and models all show a different view of the same reality and provide that line of sight from strategy to IT infrastructure, enabling the alignment of IT and business investments with the strategy of the enterprise.

An architecture framework establishes a set of terms that describe the various types of architecture elements. For example, the DoD Architecture Framework (DoDAF) defines architecture elements such as activity, performer, location, and capability. The use of a single architecture framework across an enterprise means that all the architects will be using the same set of well-understood terms.

Enterprise Architecture Certification

EA has developed as a practitioner-based and practice-driven discipline rather than being grounded in any specific academic discipline. A prime driver for EA was the U.S. government’s search for a way to ensure that large investments in IT would create actual improvements in business performance and outcomes. Though this effort began with requiring agencies to have an integrated IT architecture that encompassed multiple views of the enterprise, it soon became apparent that a more holistic enterprise view was required. EA provided the ability to establish traceability or “line of sight” from automation and IT infrastructure through business process performance to strategic goals and objectives (desired business outcomes). Independently, the Department of Defense had also turned to EA to solve its interoperability problems in its move from single military service war-fighting to a Joint Task Force approach. The DoD needed an enterprise approach to ensure that complex weapons systems, planning systems, and communications from multiple military services would work together in a Joint Task Force environment.

As industry also adopted EA approaches, both government and industry wanted some form of assurances that the people they hired to develop their EAs had the skills, expertise, and experience to do the job. As demand increased, various certification approaches evolved.

What It Means to Be Certified

Certification in most areas refers to a formal procedure to recognize the knowledge, skills, and experience of members of a profession. This is most often done in part by asking candidates to demonstrate their knowledge through some form of examination procedure. In most, but not all instances, certification is done through some external body or organization that is recognized as a credible body to assess capabilities. In many disciplines, such as medicine, education, and law, this certification is under the authority of major professional organizations and/or governmental entities. There are also a number of technical certifications that are promoted by industrial organizations that test for competencies with a defined body of knowledge and skill sets. These range from certifications in specific products such as those offered by Microsoft, CISCO, and Oracle to the mastery of a set of approaches that are often incorporated into the curricula of various university departments. These include such fields as program management, Six Sigma, information assurance, and the like.

Because EA is an emerging discipline, no single professional organization has yet materialized with the necessary prestige and acknowledged professionalism to establish a single certification examination or process. So far, the government has not established any standards for EA education or training, although a few very preliminary attempts at these standards have been made. Since professionals seeking to enter the EA field may come from a variety of backgrounds, the certification approaches typically focus on either general EA concepts or on a specific architecture framework. EA certifications can come from a variety of sources, as mentioned earlier:

• Universities and colleges—master’s degree programs, certifications from specific programs (independent of a degree program), or passing of single courses

• Certification bodies associated with organizations that control the development of specific frameworks such as the Zachman Framework or TOGAF, which offer both training courses and certification examinations

• Independent training vendors offering certification courses, which range from professional short courses on EA overview and concepts to more in-depth courses that focus on a specific framework or approach, and which may or may not include a certification examination

Thus, professionals seeking certification must decide what type of certification they want. The choice may depend on their background and the requirements of the job they are currently working in or would like to work in. This book provides both overview and in-depth materials relevant to certification examinations.

Learning Objectives for this Book

The goal of this book is to prepare the reader for certification by covering major EA concepts and helping readers to demonstrate competencies in areas such as the following:

• Selection of the correct level of architecture (such as Enterprise Level, Segment Level, or Solution Level) needed to address a specific enterprise problem

• Planning for the development of useful architecture by selecting appropriate views and artifacts depending on the problems the architecture needs to address and the stakeholder issues

• Understanding and using reference models such as the Federal Enterprise Architecture Consolidated Reference Model

• Understanding the TOGAF Architecture Development Methodology (ADM), FEAF Collaborative Planning Methodology (CPM), and DoDAF Six-Step methodologies

• Engaging in EA analysis and building actual customer deliverables

• Identifying the enterprise’s corporate tribes, conducting stakeholder interviews, and developing EA analyses

• Using EA for organizational transformation

How to Use This Book

Table 1 provides an overview of the organization of this book and its contents. Parts II and III have a primary focus on DoDAF details to provide the initial introduction to a complete framework. DoDAF was chosen because of its extensive influence on defense-oriented architecture frameworks worldwide; its influence on U.S. government federal and agency architecture frameworks, including FEAF; and because its views and viewpoints are compatible with TOGAF.

Table 1   Overview of Organization of this Book

Reading Advice

Readers should read or at least skim Part I to understand the EA vocabulary used throughout the book and the basic cultural concepts important to EA, such as corporate tribes. If readers want to read any other chapters in Parts II and III, they should read Chapter 3 to understand the discussions and examples involving the RMN Airport Case Study. Readers who want to know about planning for an EA development, developing an EA, setting up an EA project office, and EA management, governance, dissemination, and use should read the rest of Part II. Readers who want a detailed introduction to DoDAF viewpoints and views with examples should read Part III. A study of the examples in Part III will provide an introduction to the concept of integration that is one of the keys to a useful architecture. Readers interested in a framework other than the DoDAF or with a general interest in architecture frameworks should read Part IV.

At the end of most chapters is a “Questions” section. These questions are designed to reinforce the meaning of concepts presented in the book. These questions often require self-examination of your own enterprise in the light of the concepts presented in order to deliver value to you in the understanding of your own enterprise. Thus, the questions at the end of each chapter are to be taken more as a study guide to assist in the understanding of the concepts involved and therefore no answer keys have been provided.

Questions

1. Discuss what motivates (or hinders) EA development in your organization. What are the key drivers for EA in your enterprise? What are the key demotivators?

2. What are the early reasons for the emergence of EA? Are those reasons still valid? Are there new reasons driving the need for EA? What are they?

3. What is the relationship between enterprise architecture and enterprise transformation?

4. What is the role of project management as a discipline in enterprise architecture? Think of two roles—projects that are related to the development of the EA itself and projects that represent transformation initiatives or investments.

5. Why is EA certification beneficial to enterprises? What are the elements of EA certification? How does EA certification described in this book differ from or resemble other certification processes such as product certifications from, say, a Microsoft or professional certifications such as the Project Management Institute?

6. Should EA be restricted to use in information technology planning or is it applicable to all aspects of the enterprise such as the value-added business processes, inbound logistics, outbound logistics, and aspects of sales and marketing, for instance? Discuss why, or why not, and present examples of how EA can be used in the IT realm as well as in the business realm.

References

Gregor, Hohpe, and Bobby Woolf. 2004. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. New York: Addison-Wesley Professional.

Lankhorst, Marc. 2017. Enterprise Architecture at Work: Modelling, Communication and Analysis. Berlin: Springer.

Mills, C. Wright. 1959. The Sociological Imagination. Oxford, U.K.: Oxford University Press.

Ohmae, Kenichi. 1991. The Mind of a Strategist: The Art of Japanese Business. New York: McGraw-Hill Education.

Rao, Prakash, Ann Reedy, and Beryl Bellman. 2011 FEAC Certified Enterprise Architect CEA Study Guide. New York: McGraw-Hill Education.