Ask a question from expert
Layers of an Enterprise Architecture - PDF
18 Pages9186 Words202 Views
Added on 2020-09-09
Layers of an Enterprise Architecture - PDF
Added on 2020-09-09
BookmarkShareRelated Documents
IntroLayers of an Enterprise ArchitectureTo cope with the complexity of the relations between all the elements of anEnterprise Architecture and the different views and viewpoints of the stakeholdersto address, it is common to use a layering scheme (Fig. 2.1).As stated in the definition given by The Opengroup for the term «ArchitectureDomains» the layering in (TOGAF) is done as follows:Business Architecture: As TOGAF states«In summary, the Business Architecture describes the product and/or service strategy, andthe organizational, functional, process, information, and geographic aspects of the businessenvironment.»This architecture is extremely important, as all the other architectures rely on it.The exact extent to which business-related activities to define this layer willeffectively be driven and managed by an Enterprise Architecture program dependson the business environment. For example, in our environment the EnterpriseArchitecture team had the lead for the definition of an information model andbusiness glossary, but not for the business process architecture itself.Data Architecture: This architecture deals with all necessary aspects of datamanagement, how applications, services, and business functions utilize enterprisedata, how the relationship among data objects are to be modeled, how the transformationof data is to be done, etc. TOGAF provides the following definition:«A description of the structure and interaction of the enterprise’s major types and sourcesof data, logical data assets, physical data assets, and data management resources.»Business ArchitectureData & Application ArchitectureTechnology ArchitectureFig. 2.1 Layers of an enterprise architecture12 2 TheoryApplication Architecture: This layer provides all necessary information for themanagement of the application landscape, how business functions will be realizedin terms of applications.Maybe to useIn addition to the above requirements on enterprise architecture as a means, basedon the discussions in this chapter, we also identify seven key applications for enterprisearchitecture:1. Investigate problems/shortcomings in a preexisting situation, including the creationof a shared (among stakeholders) understanding of the existing situation;2. Express (and motivate) the future direction of an enterprise, as well as investigate(and evaluate) different alternatives. This also involves the creation of a shared(among stakeholders) conceptualisation of the (possible) future directions, andshared agreement for the selected alternative;3. Identify key problems, challenges, issues, impediments, chances, etc., as wellas make well-motivated design decisions that enable a move from the existingsituation into the desired strategic direction;4. Provide boundaries and identify plateaus (intermediary steps) for the transformationof the enterprise toward the articulated strategic direction. In this context,enterprise architecture is used as a planning tool, making the realization of astrategy more tangible;5. Give a clear context and direction for a portfolio of projects working toward therealization of the first plateau as defined at the tactical planning level;6. Select one or more standard solutions and/or packages that are to become part
of the solution and/or decide to outsource an entire business process/service toanother enterprise;7. Create the high level design of an actual step in the enterprise transformation asit will be realized (and implemented) in the context of a specific project.3.3 Key Applications for Enterprise ArchitectureBased on the needs and challenges of enterprises as discussed in the previous chapter(in particular, Sect. 2.6), we identify seven key applications for enterprise architectureas a means. In combination, these applications provide an instrument to makeinformed decisions as well as to ensure compliance of the transformation to thesedecisions, at several levels of specificity:– Situation description—Use enterprise architecture as a means for goal/causeanalysis to investigate problems/shortcomings in an existing situation. This also involves the creation of a shared (among stakeholders) understanding of the existingsituation.– Strategic direction—Use enterprise architecture to express (and motivate) thefuture direction of an enterprise, as well as investigate (and evaluate) different alternatives.This also involves the creation of a shared (among stakeholders) conceptualizationof the (possible) future directions, and shared agreement for theselected alternative.– Gap analysis—Use enterprise architecture to identify key problems, challenges,issues, impediments, chances, threats, etc., as well as make well-motivated designdecisions that enable a move from the existing situation into the desired strategicdirection.– Tactical planning—Use enterprise architecture to provide boundaries and identifyplateaus (intermediary steps) for the transformation of the enterprise towardthe articulated strategic direction. In this context, enterprise architecture is usedas a planning tool, making the realization of a strategy more tangible.– Operational planning—Use enterprise architecture to give a clear context anddirection for a portfolio of projects working toward the realization of the firstplateau as defined at the tactical planning level.– Selection of partial solutions—Use enterprise architecture as a means to selectone or more standard solutions and/or packages that are to become part of thesolution and/or decide to outsource an entire business process/service to anotherenterprise.– Solution architecture—Use enterprise architecture to create the high level designof an actual step in the enterprise transformation as it will be realized (andimplemented) in the context of a specific project.In Fig. 3.7, we have illustrated these seven application areas. Each of these sevenapplication areas will yield different enterprise architectures, which are clearly interdependent.By ensuring compliance among these architectures, governance, andinformed decision-making, from the strategic level to the operational level is enabled.BackgroundEnterprise Architecture is still fairly young. It began getting traction in the mid to late 1980s after John Zachman published an article describing a framework for information systems architectures in the IBM Systems Journal. Zachman said he lived to regret initially calling his
framework “A Framework for Information Systems Architecture,” instead of “Enterprise Architecture” because the framework actually has nothing to do with information systems.Rather, he said, it was “A Framework for Enterprise Architecture.” But at the time of publication, the idea of Enterprise Architecture was such a foreign concept, Zachman said, that people didn’t understand what it was. Even so, the origins of his ontological framework were already almost 20 years old by the time he first published them.In the late 1960s, Zachman was working as an account executive in the Marketing Division of IBM. His account responsibility was working with the Atlantic Richfield Company (better known as ARCO). In 1969, ARCO had just been newly formed out of the merger of three separate companies, Atlantic Refining out of Philadelphia and Richfield in California, which merged and then bought Sinclair Oil in New York in 1969.By separating these two independent variables, management could change organizational responsibilities without affecting or changing existing systems or the organization. Many years later, Jim Champy and Mike Hammer popularized this notion in their widely read 1991 book, “Reengineering the Corporation,” Zachman said.Source 8In the early ‘80’s, there was little interest in the idea of Enterprise Engineering or Enterprise Modeling and the use of formalisms and models was generally limited to some aspects of application development within the Information Systems community. The subject of architecture was acknowledged at that time, however, there was little definition to support the concept. This lack of definition precipitated the initial investigation that ultimately resultedin the “Framework for Information Systems Architecture” (later referred to as The Zachman Framework). Although from the outset, it was clear that it should have been referred to as the “Framework for Enterprise Architecture,” that enlarged perspective could only now begin to be generally understood as a result of the relatively recent and increased, world-wide focus on Enterprise EngineeringSource 7In my 1998 article, "Enterprise Architecture: The Issue of the Century," I argued that the Enterprise that can accommodate the concepts of Enterprise Architecture will have the opportunity to stay in the game ... and the Enterprise that cannot accommodate the conceptsof Enterprise Architecture is not going to be in the game. I might observe that a lot of Enterprises have been falling out of the game of late.Source 6In 1998, the ZIFA Forum was held in August at the Camelback Inn in Scottsdale, Arizona. If anything, that year's program was even more enthusiastically received than previous years, although my program strategy was completely different from the past.Tom Bruce -- who was at the Bank of America when he wrote Designing QualityDatabases Using IDEF1X Information Modeling, a seminal work on Column 1 (data)models. The basic idea of the book is that if you want the end result to representwhat the 'Owners' have in mind, each model has to accurately reflect the intent ofthe next higher row model. In his presentation, Tom also was making some incrediblyinteresting observations about designingthe data models to accommodate downstreamEnterprise change.
Melissa Cook -- who is at Hewlett Packard and wrote Building Enterprise InformationArchitectures, a book on Rows 1 (Scope) and a high-level sliver of Row 2 (Modelsof the Business) for Columns 1 (Data), 2 (Process) and 3 (Location). This isa very easy-to-read book on using classification theory to establish architecturalboundaries for all ensuing implementations. It contains one of the clearestdiscussions I have ever read on why architecture is so critical for the Column 3(Network) design. In 1998, Melissa was recounting her experience in implementingher ideas at HP.Don Hodge -- from the Bank of America, currently building a very large set ofRow 2 models (Models of the Business). He was very interesting, not only becausehe represents an 'implementing Enterprise,' but also because the model they are buildingis very large (something over 5,000 objects at present) and also, he is using a modelingtool supplied by NCR called METIS, to capture and manipulate the model.Tom Hokel -- from Framework Software, who built an 'Artifact Management' tool,specifically using the Framework as the basis for classifying and accessing any kindof artifact. You can associate a document, a model, a standard, an application,or whatever with a Cell or set of Cells and then retrieve it later through the Framework. Click on the Cell, find the artifact, launch the application where it is stored,and present it through the Framework Cell. This tool is receiving wide acceptanceand, specifically, it is being heavily used in the U.S. Air Force, Health InformationResources System.Judi Reeder and Howard Jachter -- of Knowledge Partners and Lucent Technologies(respectively) who are building a set of Row 2 models (Models of the Business)forLucent Technologies. This is another 'implementing Enterprise' experience wherethey arebuilding very large models to serve as a basis for bounding all ensuing'systems' implementations and accumulating a 'meta-data' repository to serve as acontrol point for all I.T. decision making. This was very interesting in thatit is a kind of 'prototype' effort at Lucent to accumulate knowledge on architecturesand architectural practices for subsequent deployment broadly in the corporation.Ron Buck -- of the South Bay Group who, as CEO of IVI Publishing, produced allof the publications for the Mayo Clinic, including the very innovative "PrimePractice: CD-ROM Series for Primary Care Practitioners." This continuingeducation program for physicians is amodel of Column 4, Presentation Architectureconcepts that employs the practices of the publishing industry in designing 'userinterfaces.' Ron described even more interesting execution of these ideas inseveral Knowledge Management projects on which he is currentlyworking.Tom DeMarco -- who wrote Structured Analysis and System Specification (publishedby Yourdon Press in 1978), a seminal piece of work on Process models, Column 2, Rows4 and 5. He could attend only by video and had some very interesting observationson architecture and reusability. He also observed that 'Architecture' is sucha powerful concept that when it
End of preview
Want to access all the pages? Upload your documents or become a member.
Related Documents
Enterprise Architecture Solutions Assignmentlg...
|12
|2122
|168