Activity 2 - Identify the Alignment Requirements

Anonymous
timer Asked: Feb 5th, 2019
account_balance_wallet $9.99

Question Description

*** Plagiarism is not acceptable ***

As part of Activity 2 need to complete on “Identify the Alignment Requirements" based on my documents. Kindly refer attached instruction and tasks for the topic carefully.

Instructions:

  • Project idea should be Cite any sources you use using correct APA format on a separate page. Plagiarism is not acceptable. (Please consider this top priority).
  • For Activity 2 complete instructions are attached. All instructions or tasks must be addressed. (Try to address all the information specified in each task)
  • Activity 2 should be minimum 300 to 500 words (and reference page)
  • With this instruction I am attaching the two documents Please read careful first based on this document you need to do my Activity 2 project.

Unformatted Attachment Preview

A Comparison of the Top Four Enterprise-Architecture Methodologies Roger Sessions ObjectWatch, Inc. May 2007 Applies to: Enterprise Architecture Summary: Twenty years ago, a new field was born that soon came to be known as enterprise architecture. This paper covers a broad introduction to the field of enterprise architecture. Although the history of the field goes back 20 years, the field is still evolving—and rapidly so. (36 printed pages) Contents Executive Summary Introduction A Brief History of Enterprise Architecture Case Study The Zachman Framework for Enterprise Architectures The Open Group Architecture Framework (TOGAF) Federal Enterprise Architecture (FEA) Gartner Comparison Conclusion Glossary References Executive Summary Twenty years ago, a new field was born that soon came to be known as enterprise architecture. The field initially began to address two problems:   System complexity—Organizations were spending more and more money building IT systems; and Poor business alignment—Organizations were finding it more and more difficult to keep those increasingly expensive IT systems aligned with business need. The bottom line: more cost, less value. These problems, first recognized 20 years ago, have today reached a crisis point. The cost and complexity of IT systems have exponentially increased, while the chances of deriving real value from those systems have dramatically decreased. Today's bottom line: even more cost, even less value. Large organizations can no longer afford to ignore these problems. The field of enterprise architecture that 20 years ago seemed quaintly quixotic today seems powerfully prophetic. Many enterprise-architectural methodologies have come and gone in the last 20 years. At this point, perhaps 90 percent of the field use one of these four methodologies:     The Zachman Framework for Enterprise Architectures—Although self-described as a framework, is actually more accurately defined as a taxonomy The Open Group Architectural Framework (TOGAF)—Although called a framework, is actually more accurately defined as a process The Federal Enterprise Architecture—Can be viewed as either an implemented enterprise architecture or a proscriptive methodology for creating an enterprise architecture The Gartner Methodology—Can be best described as an enterprise architectural practice This white paper discusses these four approaches to enterprise architecture. It does so within the context of a fictional company that is facing some very nonfictional operations problems. These problems include:     IT systems that have become unmanageably complex and increasingly costly to maintain. IT systems that are hindering the organization's ability to respond to current, and future, market conditions in a timely and cost-effective manner. Mission-critical information that is consistently out-of-date and/or just plain wrong. A culture of distrust between the business and technology sides of the organization. How should this company choose from among these four very different approaches to enterprise architecture? This white paper traces the journey the company is likely to face in using any one of these methodologies. When examining each of these methodologies in depth, one is struck by the fact that none of these approaches is really complete. Each has strengths in some areas and weaknesses in others. For many enterprises, none of these methodologies will therefore be a complete solution. For such organizations, this white paper proposes another approach, one that might be called a blended methodology. Choose bits and pieces from each of these methodologies, and modify and merge them according to the specific needs of your organization. This white paper gives an approach to creating such a blended methodology that is a best fit for your organization's needs. But even a blended methodology will only be as good as an organization's commitment to making changes. This commitment must be driven by the highest level of the organization. The good news is that, with a real commitment to change and a tailored methodology for guiding that change, the 20-year-old promise of enterprise architecture is within reach. That promise hasn't changed: reducing IT cost and complexity, while increasing business value and effectiveness—or, to put it even more simply, improving your competitiveness in an increasingly competitive world. Introduction The year 2007 marks the 20-year anniversary of enterprise architecture. In that time, a number of enterprise-architectural methodologies have come and gone. Today, four dominate the field: the Zachman Framework for Enterprise Architectures, The Open Group Architecture Framework (TOGAF), the Federal Enterprise Architecture (FEA), and Gartner (formerly, the Meta Framework). Should you care about a field that is 20 years old? It depends. This field was inaugurated to address two major problems in information technology (IT) that were then already becoming apparent. The first problem was managing the increasing complexity of information-technology systems. The second problem was the increasing difficulty in delivering real business value with those systems. As you can imagine, these problems are related. The more complex a system, the less likely it is that it will deliver maximum business value. As you better manage complexity, you improve your chances of delivering real business value. So, should you care about this field? It depends on how you feel about positively affecting your organization's bottom line. If managing system complexity and delivering business value are key priorities for you, you should care about enterprise-architecture methodologies. If you are focused on maintaining, or rebuilding, IT's credibility in your organization, or if you strive to promote the use of IT to maintain a competitive position in your industry, you should continue reading this white paper. If these issues don't concern you, these methodologies have little to offer. As systems become more complex, they generally require more planning. It is easy to see this in buildings. When Henry David Thoreau built his little cabin on Walden Pond (shown in Figure 1), he embraced simplicity and needed no architects. If you are building New York City (shown in Figure 2), simplicity is out of the question, and you will need many architects. Figure 1. Thoreau's cabin at Walden Pond, as drawn by Thoreau's sister, Sophia Thoreau Figure 2. New York City The relationship between complexity and planning for buildings and cities is similar for information systems. If you are building a simple, single-user, nondistributed system, you might need no architects at all. If you are building an enterprise-wide, mission critical, highly distributed system, you might need a database architect, a solutions architect, an infrastructure architect, a business architect, and an enterprise architect. This paper is about the methodologies needed to develop the overall architectural vision for an organization. This is the responsibility of the enterprise architect. This is the architect who specializes in the broadest possible view of architecture within the enterprise. This is the architect's architect, the architect who is responsible for coordinating the work of all of the other architects. Do you need such an architect? It all depends on what you are building: Thoreau's cabin or New York City. Building a large, complex, enterprise-wide information system without an enterprise architect is like trying to build a city without a city planner. Can you build a city without a city planner? Probably. Would you want to live in such a city? Probably not. Of course, hiring a city planner does not guarantee a livable city; it merely improves your chances. Similarly, having an enterprise architect does not guarantee a successful enterprise architecture. There are many examples of failed enterprise architectures in the world today, and all of them had enterprise architects (probably dozens!). Architectural methodologies can help, but they go only so far. I'll discuss some of the reasons for these failures, and how to avoid them, also in this paper. Before I get too far into comparing the methodologies that make up the enterprise architect's toolkit, I need to define some terms. This is especially important in an article that is comparing methodologies, because the different methodologies sometimes use similar terms to mean different things. For example, we have two methodologies that describe themselves as enterprise-architectural frameworks: the Zachman Framework for Enterprise Architectures and The Open Group Architectural Framework (TOGAF). Yet these two methodologies share little in common other than the words enterprise, architecture, and framework. So, I will start by defining the terms as I will use them in this white paper. Those definitions marked with an asterisk (*) are taken mostly from IEEE-1471-2000 [01], whose definitions I use where they exist and make sense. architect—One whose responsibility is the design of an architecture and the creation of an architectural description architectural artifact—A specific document, report, analysis, model, or other tangible that contributes to an architectural description architectural description*—A collection of products (artifacts) to document an architecture architectural framework—A skeletal structure that defines suggested architectural artifacts, describes how those artifacts are related to each other, and provides generic definitions for what those artifacts might look like architectural methodology—A generic term that can describe any structured approach to solving some or all of the problems related to architecture architectural process—A defined series of actions directed to the goal of producing either an architecture or an architectural description architectural taxonomy—A methodology for organizing and categorizing architectural artifacts architecture*—The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution enterprise architecture—An architecture in which the system in question is the whole enterprise, especially the business processes, technologies, and information systems of the enterprise Now that we have a common understanding of these key terms, I can take you through the history of enterprise-architecture methodologies, discuss the problems these methodologies are trying to solve, and compare the top four methodologies in terms of their approach and their relationship to each other. A Brief History of Enterprise Architecture The field of enterprise architecture essentially started in 1987, with the publication in the IBM Systems Journal of an article titled "A Framework for Information Systems Architecture," by J.A. Zachman. In that paper, Zachman laid out both the challenge and the vision of enterprise architectures that would guide the field for the next 20 years. The challenge was to manage the complexity of increasingly distributed systems. As Zachman said: The cost involved and the success of the business depending increasingly on its information systems require a disciplined approach to the management of those systems. [02] Zachman's vision was that business value and agility could best be realized by a holistic approach to systems architecture that explicitly looked at every important issue from every important perspective. His multiperspective approach to architecting systems is what Zachman originally described as an information systems architectural framework and soon renamed to be an enterprise-architecture framework. Zachman was a major influence on one of the earliest attempts by a branch of the U.S. Government, the Department of Defense, to create an enterprise architecture. This attempt was known as the Technical Architecture Framework for Information Management (TAFIM) [03] and was introduced in 1994. The promise of enterprise architectures, such as TAFIM, to better align technical projects with business need was noticed by no less a body than the U.S. Congress. Most likely influenced by the promised benefits of TAFIM, Congress in 1996 passed a bill known as the Clinger-Cohen Act of 1996 [04], also known as the Information Technology Management Reform Act, which mandated that all federal agencies take steps to improve the effectiveness of their IT investments. A CIO Council, consisting of CIOs from all major governmental bodies, was created to oversee this effort. In April 1998, the CIO Council began work on its first major project, the Federal Enterprise Architecture Framework (FEAF). Version 1.1 [05] of this framework was released in September of 1999. This document contained some innovate ideas, such as "segmented architectures"—that is, architectural focus on segmented subsets of the larger enterprise. Over time, responsibility for federal enterprise architecture moved from the CIO Council to the Office of Management and Budget (OMB). In 2002, the OMB evolved and renamed the FEAF methodology as the Federal Enterprise Architecture (FEA). I will describe FEA in greater detail, in the section dedicated to it. Despite the very significant enterprise-architectural activity in the Federal Government (one could argue that no organization has spent more money attempting to develop an enterprise architecture than the U.S. Government), progress has been slow and success stories are overshadowed by higher-profile failures. In 2004, a full eight years after the Clinger-Cohen Act mandated the use of effective IT planning processes, the General Accounting Office (GAO) reported the following: Only 20 of 96 agencies examined had established at least the foundation for effective architecture management. Further, while 22 agencies increased in maturity since 2001, 24 agencies decreased in maturity and 47 agencies remained the same. [06] Since January of 2005, the General Accounting Office (GAO, not to be confused with the OMB) has severely chastised a number of U.S. agencies for failures in their adoption or use of enterprise architecture. A few examples include the FBI [07], the Department of Defense [08], the Department of Homeland Security [09], and NASA [10]. In 1998, four years after TAFIM (remember TAFIM?) was introduced and two years after it became codified as Clinger-Cohen, TAFIM was officially retired by the Department of Defense. The work done on TAFIM was turned over to The Open Group. They morphed it into a new standard that is today known as The Open Group Architectural Framework—better known by its acronym, TOGAF. I will discuss the TOGAF work in the section dedicated to that topic. In 2005, about the same time that OMB was becoming the dominant EA force in the public sector, another organization was taking steps to become a dominant force in the private sector. This group was Gartner. By 2005, Gartner was already one of the most influential organizations specializing in CIO-level consulting. However, in the specific area of enterprise architecture, the best known IT research and advisory group was not Gartner, but Meta Group. Gartner had struggled to build an enterprise-architecture practice, but never achieved the status of the Meta Group. In 2005, Gartner decided that if they couldn't compete with Meta Group, they would do the next best thing: They would buy it. Following the purchase of Meta Group, Gartner/Meta spent a year looking at what each company brought to the table as far as enterprise-architecture experience and methodologies. The two companies discussed how best to reconcile their often quite different approaches. In the end, a fairly simple algorithm was applied: If Meta Group liked it, it was in; if Meta Group didn't like it, it was out. Gartner liked architectural frameworks. The Meta Group liked architectural process. So, frameworks were out; processes were in. I'll discuss this Gartner/Meta process in detail, in the section devoted to Gartner. Figure 3 summarizes this history with an enterprise-architecture timeline. This brings us up to date in the history of enterprise architecture. Now, let's look more closely at today's main methodologies and introduce a case study that will be used in this white paper. Figure 3. Enterprise-architecture timeline Case Study So that we can compare and contrast the four major approaches to enterprise architectures, I am going to illustrate how each would approach a similar scenario. This fictitious scenario is a composite of several enterprises with which I have worked over the past several years. So, while it is fictitious, it is very realistic. I'll first describe the scenario. MedAMore is a chain of drug stores. It started as a regional chain in 1960. In 1995, it developed an innovative software system that enabled it to run drug stores very efficiently. It called this system MedAManage, or MAM. MAM incorporated some innovate business ideas, such as patient-relationship management, inventory management, automated insurance billing, and even utility optimization. MAM consisted of three programs: MAM/Store, which ran on a small computer at a drug store; MAM/Warehouse, which ran on a server in a regional warehouse; and MAM/Home, which ran on a large server at the home office. These three programs communicated through files that were transferred from one location (for example, a store) to another (for example, a regional warehouse). When reliable communications lines existed, file transfers could occur through FTP. The system was also flexible enough to accommodate transfers through courier, where necessary. By 2000, MedAMore was doing quite well—in part, because of the cost-cutting moves enabled by the MAM system. MedAMore decided to begin expansion. To do this, it purchased three regional chains. With these purchases, MedAMore extended its reach through the southeast quadrant of the U.S. By 2002, it was clear that the same software systems that had initially fueled MedAMore's success were now hampering its future. Some of the problems MedAMore was running into were the following:    MAM/Store required regional specializations. For example, different insurance plans needed to be supported in different regions, and these all required changes to the MAM/Store module. The regional warehouses that had been acquired through acquisition each had different ways of receiving orders from the retail stores and different procedures from ordering supplies from the wholesalers. Each of these differences required changes to the MAM/Warehouse module. The file-transfer approach to information sharing that had worked so well when MedAMore consisted of 30 drugstores, one regional warehouse, and one home office were turning out to be difficult to coordinate among 200 drugstores, four regional warehouses, two geographic offices, and one home office. Files were often delivered late, sometimes not at all, and occasionally multiple times. This made it difficult for the home office to access reliable, up-to-date financial information, especially in the areas of sales and inventory. It was clear to MedAMore management that the MAM system needed many enhancements. However, upgrading this system was difficult. Each of the three modules (store, warehouse, and home office) was huge, inefficient, and cumbersome, and each included functionality for everything that each entity might need. The modules had grown to over 1 million lines of code each. It was difficult to change one function without affecting others. All of the functions accessed a single database, and changes to one record definition could ripple through the system in an unpredictable fashion. Changing even a single line of code required a rebuild of the entire multimillion-line module. MedAManage had become MedANightmare. Debugging was difficult. So ...
Purchase answer to see full attachment

Tutor Answer

peachblack
School: UIUC

Hey buddy, please find attached a complet a...

flag Report DMCA
Review

Anonymous
Thank you! Reasonably priced given the quality not just of the tutors but the moderators too. They were helpful and accommodating given my needs.

Similar Questions
Related Tags

Brown University





1271 Tutors

California Institute of Technology




2131 Tutors

Carnegie Mellon University




982 Tutors

Columbia University





1256 Tutors

Dartmouth University





2113 Tutors

Emory University





2279 Tutors

Harvard University





599 Tutors

Massachusetts Institute of Technology



2319 Tutors

New York University





1645 Tutors

Notre Dam University





1911 Tutors

Oklahoma University





2122 Tutors

Pennsylvania State University





932 Tutors

Princeton University





1211 Tutors

Stanford University





983 Tutors

University of California





1282 Tutors

Oxford University





123 Tutors

Yale University





2325 Tutors