Misplaced Pages

#813186

95-458: A federal enterprise architecture framework ( FEAF ) is the U.S. reference enterprise architecture of a federal government . It provides a common approach for the integration of strategic, business and technology management as part of organization design and performance improvement. The most familiar federal enterprise architecture is the enterprise architecture of the Federal government of

190-583: A common language and framework to describe and analyze investments. Overall the Federal Enterprise Architecture (FEA) is mandated by a series of federal laws and mandates. These federal laws have been: Supplementary OMB circulars have been: The Collaborative Planning Methodology (CPM) is a simple, repeatable process that consists of integrated, multi-disciplinary analysis that results in recommendations formed in collaboration with leaders, stakeholders, planners, and implementers. It

285-487: A core mission area, business service, or enterprise service. Segment architecture is driven by business management and delivers products that improve the delivery of services to citizens and agency staff. From an investment perspective, segment architecture drives decisions for a business case or group of business cases supporting a core mission area or common or shared service. The primary stakeholders for segment architecture are business owners and managers. Segment architecture

380-400: A framework for information systems architecture, Zachman looked at the field of classical architecture , and a variety of complex engineering projects in industry. He saw a similar approach and concluded that architectures exist on many levels and involves at least three perspectives: raw material or data , function of processes, and location or networks. The Information Systems Architecture

475-565: A government organization the framework can be applied to an entire agency at an abstract level, or it can be applied to various departments, offices, programs, subunits and even to basic operational entities. Zachman Framework is applied in customized frameworks such as the TEAF , built around the similar frameworks, the TEAF matrix . Other sources: Zachman Framework is also used as a framework to describe standards, for example standards for healthcare and healthcare information system. Each cell of

570-619: A hierarchy, the TRM categorizes the standards and technologies that collectively support the secure delivery, exchange, and construction of business and application Service Components that may be used and leveraged in a component-based or service-oriented architecture . In the FEA, enterprise, segment, and solution architectures provide different business perspectives by varying the level of detail and addressing related but distinct concerns. Just as enterprises are themselves hierarchically organized, so are

665-419: A high-level depiction of the TRM. Aligning agency capital investments to the TRM leverages a common, standardized vocabulary, allowing interagency discovery, collaboration, and interoperability. Agencies and the federal government will benefit from economies of scale by identifying and reusing the best solutions and technologies to support their business functions, mission, and target architecture. Organized in

760-576: A number of existing approaches to performance measurement, including the Balanced Scorecard , Baldrige Criteria, value measuring methodology , program logic models , the value chain, and the Theory of Constraints . In addition, the PRM was informed by what agencies are currently measuring through PART assessments, GPRA, enterprise architecture , and Capital Planning and Investment Control. The PRM

855-406: A particular style of application integration. Research points to EA promoting the use of SOA as an enterprise-wide integration pattern. The broad reach of EA has resulted in this business role being included in the information technology governance processes of many organizations. Analyst firm Real Story Group suggested that EA and the emerging concept of the digital workplace are "two sides to

950-417: A reduction of business risks from system failures and security breaches. EA also helps reduce risks of project delivery. Establishing EA as an accepted, recognized, functionally integrated and fully involved concept at operational and tactical levels is one of the biggest challenges facing Enterprise Architects today and one of the main reasons why many EA initiatives fail. A key concern about EA has been

1045-401: A set of common goals and collaborate to provide specific products or services to customers. In that sense, the term enterprise covers various types of organizations, regardless of their size, ownership model, operational model, or geographical distribution. It includes those organizations' complete sociotechnical system , including people, information, processes, and technologies. Enterprise as

SECTION 10

#1732802288814

1140-512: A set of interrelated reference models designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps and opportunities for collaboration within and across agencies. Collectively, the reference models comprise a framework for describing important elements of federal agency operations in a common and consistent way. Through the use of the FEAF and its vocabulary, IT portfolios can be better managed and leveraged across

1235-430: A sociotechnical system defines the scope of EA. The term architecture refers to fundamental concepts or properties of a system in its environment; and embodied in its elements, relationships, and in the principles of its design and evolution. A methodology for developing and using architecture to guide the transformation of a business from a baseline state to a target state, sometimes through several transition states,

1330-695: A travel agent company, whose business is more concerned with people and event-timing, could find it beneficial to focus their documentation efforts on Who , When , and Where columns. However, there is no escaping the Why column's importance as it provides the business drivers for all the other columns. Since the 1990s the Zachman Framework has been widely used as a means of providing structure for information technology engineering -style enterprise modeling . The Zachman Framework can be applied both in commercial companies and in government agencies. Within

1425-415: Is a component-driven, technical framework categorizing the standards and technologies to support and enable the delivery of Service Components and capabilities. It also unifies existing agency TRMs and E-Gov guidance by providing a foundation to advance the reuse and standardization of technology and Service Components from a government-wide perspective. The TRM consists of: The figure on the right provides

1520-563: Is also designed to ease sharing of information and resources across federal agencies, reduce costs, and improve citizen services. In September 1999, the Federal CIO Council published the "Federal Enterprise Architecture Framework" (FEAF) Version 1.1 for developing an Enterprise Architecture (EA) within any Federal Agency for a system that transcends multiple inter-agency boundaries. It builds on common business practices and designs that cross organizational boundaries, among others

1615-401: Is being addressed. The framework is named after its creator John Zachman , who first developed the concept in the 1980s at IBM . It has been updated several times since. The title "Zachman Framework" refers to The Zachman Framework for Enterprise Architecture with version 3.0 being the most current. The Zachman Framework has evolved in its thirty-year history to include: In other sources

1710-414: Is commonly related to segment architecture and enterprise architecture through definitions and constraints. For example, segment architecture provides definitions of data or service interfaces used within a core mission area or service, which are accessed by individual solutions. Equally, a solution may be constrained to specific technologies and standards that are defined at the enterprise level. Results of

1805-552: Is currently composed of four measurement areas: The "FEA business reference model " is a function-driven framework for describing the business operations of the Federal Government independent of the agencies that perform them. This business reference model provides an organized, hierarchical construct for describing the day-to-day business operations of the Federal government using a functionally driven approach. The BRM

1900-421: Is designed to be a classification schema for organizing architecture models. It provides a synoptic view of the models needed for enterprise architecture. Information Systems Architecture does not define in detail what the models should contain, it does not enforce the modeling language used for each model, and it does not propose a method for creating these models. In the 1992 article "Extending and Formalizing

1995-547: Is designed to ease sharing of information and resources across federal agencies, reduce costs, and improve citizen services. It is an initiative of the US Office of Management and Budget that aims to comply with the Clinger-Cohen Act . The PRM is a standardized framework to measure the performance of major IT investments and their contribution to program performance. The PRM has three main purposes: The PRM uses

SECTION 20

#1732802288814

2090-513: Is effectively used. The functional approach promoted by the BRM will do little to help accomplish the goals of E-Government if it is not incorporated into EA business architectures and the management processes of all Federal agencies and OMB. The Service Component Reference Model (SRM) is a business and performance-driven, functional framework that classifies Service Components with respect to how they support business and/or performance objectives. The SRM

2185-618: Is intended as a full planning and implementation lifecycle for use at all levels of scope defined in the Common Approach to Federal Enterprise Architecture: International, National, Federal, Sector, Agency, Segment, System, and Application. The Consolidated Reference Model of the Federal Enterprise Architecture Framework (FEAF) equips OMB and Federal agencies with a common language and framework to describe and analyze investments. It consists of

2280-459: Is intended for use to support the discovery of government-wide business and application Service Components in IT investments and assets. The SRM is structured across horizontal and vertical service domains that, independent of the business functions, can provide a leverage-able foundation to support the reuse of applications, application capabilities, components, and business services. The SRM establishes

2375-462: Is not a methodology in that it does not imply any specific method or process for collecting, managing, or using the information that it describes; rather, it is an ontology whereby a schema for organizing architectural artifacts (in other words, design documents, specifications, and models) is used to take into account both who the artifact targets (for example, business owner and builder) and what particular issue (for example, data and functionality)

2470-453: Is related to EA through three principles: " Solution architecture " defines agency IT assets such as applications or components used to automate and improve individual agency business functions. The scope of a solution architecture is typically limited to a single project and is used to implement all or part of a system or business solution. The primary stakeholders for solution architecture are system users and developers. Solution architecture

2565-425: Is the first layer of the Federal Enterprise Architecture and it is the main viewpoint for the analysis of data, service components and technology. The BRM is broken down into four areas: The Business Reference Model provides a framework that facilitates a functional (as opposed to organizational) view of the federal government's LoBs, including its internal operations and its services for the citizens, independent of

2660-455: Is too complex and extensive to document in its entirety, so knowledge management techniques provide a way to explore and analyze these hidden, tacit, or implicit areas. In return, EA provides a way of documenting the components of an organization and their interaction in a systemic and holistic way that complements knowledge management. In various venues, EA has been discussed as having a relationship with Service Oriented Architecture (SOA),

2755-515: Is usually known as an enterprise architecture framework . A framework provides a structured collection of processes, techniques, artifact descriptions , reference models, and guidance for the production and use of an enterprise-specific architecture description. Paramount to changing the EA is the identification of a sponsor . Their mission, vision , strategy, and the governance framework define all roles, responsibilities, and relationships involved in

2850-555: The Federal Enterprise Architecture 's reference guide aids federal agencies in the development of their architectures. As a discipline, EA "proactively and holistically lead[s] enterprise responses to disruptive forces by identifying and analyzing the execution of change" towards organizational goals. EA gives business and IT leaders recommendations for policy adjustments and provides best strategies to support and enable business development and change within

2945-839: The NIST Enterprise Architecture Model , the C4ISR AE, the DOE AE, and the DoDAF : The Zachman Framework methodology has for example been used by the United States Department of Veterans Affairs (VA) to develop and maintain its One-VA Enterprise Architecture in 2001. This methodology required defining all aspects of the VA enterprise from a business process, data, technical, location, personnel, and requirements perspective. The next step in implementing

Federal enterprise architecture - Misplaced Pages Continue

3040-561: The NIST Enterprise Architecture Model . The FEAF provides an enduring standard for developing and documenting architecture descriptions of high-priority areas. It provides guidance in describing architectures for multi-organizational functional segments of the Federal Government. At the time of release, the Government's IT focus on Y2K issues and then the events of September 2001 diverted attention from EA implementation, though its practice in advance and subsequent to this may have ameliorated

3135-507: The Caliber-RM Software Product. Caliber-RM is intended to be used as a software configuration management tool; not as an EA repository. However, this tool permitted defining entities and relationships and for defining properties upon both entities and relationships, which made it sufficient for building an EA repository, considering the technology available in early 2003. The personal motivation in selecting this tool

3230-516: The Federal Enterprise Architecture program are considered unsatisfactory: Enterprise architecture The United States Federal Government is an example of an organization that practices EA, in this case with its Capital Planning and Investment Control processes. Companies such as Independence Blue Cross , Intel , Volkswagen AG , and InterContinental Hotels Group also use EA to improve their business architectures as well as to improve business performance and productivity . Additionally,

3325-415: The Federal Government. The Common Approach promotes increased levels of mission effectiveness by standardizing the development and use of architectures within and between Federal Agencies. This includes principles for using EA to help agencies eliminate waste and duplication, increase shared services, close performance gaps, and promote engagement among government, industry, and citizens. On January 29, 2013,

3420-614: The Framework for Information Systems Architecture" John F. Sowa and John Zachman present the framework and its recent extensions and show how it can be formalized in the notation of conceptual graphs. Also in 1992: John Zachman's co-author John Sowa proposed the additions of the Scope perspective of the ‘planner’ (bounding lists common to the enterprise and its environment) and the Detailed Representation perspective of

3515-501: The IT/IS aspects of the enterprise and other aspects service only as inputs. The Enterprise Integrating school believes that the purpose of EA is to create a greater coherency between the various concerns of an enterprise (HR, IT, Operations, etc.), including the link between strategy formulation and execution. Architecture proposals and decisions here encompass all aspects of the enterprise. The Enterprise Ecosystem Adaption school states that

3610-501: The Transformations. The cell descriptions are taken directly from version 3.0 of the Zachman Framework. Since the product development (i.e., architectural artifact) in each cell or the problem solution embodied by the cell is the answer to a question from a perspective, typically, the models or descriptions are higher-level depictions or the surface answers of the cell. The refined models or designs supporting that answer are

3705-497: The U.S. Federal Government. Enterprise Architecture became a recognized strategic and management best practice in U.S. Federal Government with the passage of the Clinger-Cohen Act in 1996. There are numerous benefits that accrue from implementing and using an enterprise architecture within the U.S. Federal Government. Among them is to provide a common approach for IT acquisition in the United States federal government . It

3800-574: The United States , the U.S. "Federal Enterprise Architecture" (FEA) and the corresponding U.S. "Federal Enterprise Architecture Framework" (FEAF). This lemma will focus on this particular enterprise architecture and enterprise architecture framework . Enterprise architecture (EA) is a management best practice for aligning business and technology resources to achieve strategic outcomes, improve organizational performance and guide federal agencies to better execute their core missions . An EA describes

3895-582: The White House released Version 2 of the Federal Enterprise Architecture Framework (FEAF-II), to government agencies, making it public about a year later. The document meets the criteria set forth by Common Approach, emphasizing that strategic goals drive business services, which in turn provide the requirements for enabling technologies. At its core is the Consolidated Reference Model (CRM), which equips OMB and Federal agencies with

Federal enterprise architecture - Misplaced Pages Continue

3990-403: The Zachman Framework is introduced as a framework, originated by and named after John Zachman, represented in numerous ways, see image. This framework is explained as, for example: Beside the frameworks developed by John Zachman, numerous extensions and/or applications have been developed, which are also sometimes called Zachman Frameworks, however they generally tend to be graphical overlays of

4085-427: The actual framework itself. The Zachman Framework summarizes a collection of perspectives involved in enterprise architecture. These perspectives are represented in a two-dimensional matrix that defines along the rows the type of stakeholders and with the columns the aspects of the architecture. The framework does not define a methodology for an architecture. Rather, the matrix is a template that must be filled in by

4180-433: The agencies, bureaus and offices that perform them. By describing the federal government around common business areas instead of by a stovepiped, agency-by-agency view, the BRM promotes agency collaboration and serves as the underlying foundation for the FEA and E-Gov strategies. While the BRM does provide an improved way of thinking about government operations, it is only a model; its true utility can only be realized when it

4275-416: The agency mission and strategic goals and objectives. From an investment perspective, EA is used to drive decisions about the IT investment portfolio as a whole. Consequently, the primary stakeholders of the EA are the senior managers and executives tasked with ensuring the agency fulfills its mission as effectively and efficiently as possible. By contrast, " segment architecture " defines a simple roadmap for

4370-404: The anticipated transformation. Changes considered by enterprise architects typically include innovations in the structure or processes of an organization; innovations in the use of information systems or technologies; the integration and/or standardization of business processes; and improvement of the quality and timeliness of business information. According to the standard ISO/IEC/IEEE 42010 ,

4465-559: The areas related to design and re-design of the organizational structures during mergers, acquisitions, or general organizational change; enforcement of discipline and business process standardization, and enablement of process consolidation, reuse, and integration ; support for investment decision-making and work prioritization; enhancement of collaboration and communication between project stakeholders and contribution to efficient project scoping and to defining more complete and consistent project deliverabless ; and an increase in

4560-428: The article. Later during the 1990s In the 1997 paper "Concepts of the Framework for Enterprise Architecture" Zachman said that the framework should be referred to as a "Framework for Enterprise Architecture", and should have from the beginning. In the early 1980s however, according to Zachman, there was "little interest in the idea of Enterprise Reengineering or Enterprise Modeling and the use of formalisms and models

4655-420: The associated physical processes, roles, locations etc. related to those items. In the 1980s John Zachman had been involved at IBM in the development of business system planning (BSP), a method for analyzing, defining and designing an information architecture of organizations. In 1982 Zachman had already concluded that these analyses could reach far beyond automating systems design and managing data into

4750-662: The core reference models (see below), as well as a very robust methodology for actually developing an architecture in a series of templates forming the Federal Segment Architecture Methodology (FSAM) and its next generation replacement, the Collaborative Planning Methodology (CPM), which was designed to be more flexible, more widely applicable, and more inclusive of the larger set of planning disciplines. These federal architectural segments collectively constitute

4845-511: The creation a Federal Enterprise Architecture Project and the creation of the FEA Office at OMB. This was a shift from the FEAF focus on Information Engineering, to a J2EE object re-use approach using reference models comprising taxonomies that linked performance outcomes to lines of business, process services components, types of data, and technology components. Interim releases since that time have provided successive increases in definition for

SECTION 50

#1732802288814

4940-424: The current and future state of the agency, and lays out a plan for transitioning from the current state to the desired future state. A federal enterprise architecture is a work in progress to achieve these goals. The U.S. Federal Enterprise Architecture (FEA) is an initiative of the U.S. Office of Management and Budget , Office of E-Government and IT, that aims to realize the value of enterprise architecture within

5035-468: The data and information that support government program and business line operations. This model enables agencies to describe the types of interaction and exchanges that occur between the federal government and citizens. The DRM categorizes government information into greater levels of detail. It also establishes a classification for federal data and identifies duplicative data resources. A common data model will streamline information exchange processes within

5130-405: The deliverables from each perspective must provide sufficient detail to define the solution at the level of perspective and must translate to the next lower row explicitly. Each perspective must take into account the requirements of the other perspectives and the restraint those perspectives impose. The constraints of each perspective are additive. For example, the constraints of higher rows affect

5225-424: The detailed descriptions within the cell. Decomposition (i.e., drill down to greater levels of detail) takes place within each cell. If a cell is not made explicit (defined), it is implicit (undefined). If it is implicit, the risk of making assumptions about these cells exists. If the assumptions are valid, then time and money are saved. If, however, the assumptions are invalid, it is likely to increase costs and exceed

5320-472: The different views provided by each type of architecture. The Federal Enterprise Architecture Practice Guidance (2006) has defined three types of architecture: By definition, Enterprise Architecture (EA) is fundamentally concerned with identifying common or shared assets – whether they are strategies, business processes, investments, data, systems, or technologies. EA is driven by strategy; it helps an agency identify whether its resources are properly aligned to

5415-402: The difficulty in arriving at metrics of success because of the broad-brush and often opaque nature of EA projects. Additionally, there have been a number of reports, including those written by Ivar Jacobson , Gartner , Erasmus University Rotterdam and IDS Scheer , Dion Hinchcliffe , and Stanley Gaver , that argue that the frequent failure of EA initiatives makes the concept not worth

5510-679: The effort and that the methodology will fade out quickly. According to the Federation of Enterprise Architecture Professional Organizations (FEAPO), EA interacts with a wide array of other disciplines commonly found in business settings such as performance engineering and management , process engineering and management , IT and enterprise portfolio management , governance and compliance , IT strategic planning, risk analysis , information management , metadata management , organization development , design thinking , systems thinking , and user experience design . The EA of an organization

5605-695: The elements on either axis is explicitly different from the others, it is possible to define precisely what belongs in each cell. The Zachman Framework typically is depicted as a bounded 6 x 6 "matrix" with the Communication Interrogatives as Columns and the Reification Transformations as Rows. The framework classifications are repressed by the Cells, that is, the intersection between the Interrogatives and

5700-543: The enterprise, and the actors involved in the development of enterprise systems. While there is no order of priority for the columns of the Framework, the top-down order of the rows is significant to the alignment of business concepts and the actual physical enterprise. The level of detail in the Framework is a function of each cell (and not the rows). When done by IT the lower level of focus is on information technology , however it can apply equally to physical material (ball valves, piping, transformers, fuse boxes for example) and

5795-1089: The enterprise." Important players within EA include enterprise architects and solutions architects. Enterprise architects are at the top level of the architect hierarchy, meaning they have more responsibilities than solutions architects. While solutions architects focus on their own relevant solutions, enterprise architects focus on solutions for and the impact on the whole organization. Enterprise architects oversee many solution architects and business functions. As practitioners of EA, enterprise architects support an organization's strategic vision by acting to align people, process, and technology decisions with actionable goals and objectives that result in quantifiable improvements toward achieving that vision. The practice of EA "analyzes areas of common activity within or between organizations, where information and other resources are exchanged to guide future states from an integrated viewpoint of strategy, business, and technology." The term enterprise can be defined as an organizational unit , organization , or collection of organizations that share

SECTION 60

#1732802288814

5890-560: The federal enterprise architecture. In 2001, the Federal Architecture Working Group (FAWG) was sponsoring the development of Enterprise Architecture products for trade and grant Federal architecture segments. Method—s prescribed way of approaching a particular problem. As shown in the figure, the FEAF partitions a given architecture into business, data, applications, and technology architectures. The FEAF overall framework created at that time (see image) includes

5985-486: The federal government and between government and external stakeholders. Volume One of the DRM provides a high-level overview of the structure, usage, and data-identification constructs. This document: The DRM is the starting point from which data architects should develop modeling standards and concepts. The combined volumes of the DRM support data classification and enable horizontal and vertical information sharing. The TRM

6080-460: The federal government, enhancing collaboration and ultimately transforming the Federal government. The five reference models in version 1 (see below) have been regrouped and expanded into six in the FEAF-II. The FEA is built using an assortment of reference models that develop a common taxonomy for describing IT resources. FEA Version 1 reference models (see image) included the following: It

6175-563: The first three columns of the Zachman Framework and the Spewak 's Enterprise Architecture Planning methodology. In May 2012 OMB published a full new guide, the "Common Approach to Federal Enterprise Architecture". Released as part of the federal CIO's policy guidance and management tools for increasing shared approaches to IT service delivery, the guide presents an overall approach to developing and using Enterprise Architecture in

6270-721: The following domains: Each Service Domain is decomposed into Service Types. For example, the three Service Types associated with the Customer Services Domain are: Customer Preferences; Customer Relationship Management; and Customer Initiated Assistance. And each Service Type is decomposed further into components. For example, the four components within the Customer Preferences Service Type include: Personalization; Subscriptions; Alerts and Notifications; and Profile Management. The Data Reference Model (DRM) describes, at an aggregate level,

6365-400: The framework contains such a series of standards for healthcare and healthcare information system. Another application of the Zachman Framework is as reference model for other enterprise architectures, see for example these four: Other examples: Less obvious are the ways the original Zachman framework has stimulated the development of other enterprise architecture frameworks , such as in

6460-400: The goals/rules, processes, material, roles, locations, and events specifically required by the organization. Further modeling by mapping between columns in the framework identifies gaps in the documented state of the organization. The framework is a logical structure for classifying and organizing the descriptive representations of an enterprise. It is significant to both the management of

6555-652: The impact of these events. As part of the President's Management Agenda, in August 2001, the E-Government Task Force project was initiated (unofficially called Project Quicksilver). A key finding in that strategy was that the substantial overlap and redundant agency systems constrained the ability to achieve the Bush administration strategy of making the government "citizen centered". The Task Force recommended

6650-442: The information systems the business depends on. EA provides a guide for decision making towards these objectives. The National Computing Centre 's EA best practice guidance states that an EA typically "takes the form of a comprehensive set of cohesive models that describe the structure and functions of an enterprise. The individual models in an EA are arranged in a logical manner that provides an ever-increasing level of detail about

6745-417: The interfaces and... [i]ntegration of all the components of a system" is necessary. Zachman in particular urged for a " strategic planning methodology ." Within the field of enterprise architecture, there are three overarching schools: Enterprise IT Design, Enterprise Integrating, and Enterprise Ecosystem Adaption. Which school one subscribes to will impact how they see the EA's purpose and scope, as well as

6840-439: The intersection between two historical classifications. The first are primitive interrogatives: What, How, When, Who, Where, and Why . The second is derived from the philosophical concept of reification, the transformation of an abstract idea into an instantiation. The Zachman Framework reification transformations are: identification, definition, representation, specification, configuration and instantiation. The Zachman Framework

6935-416: The means of achieving it, the skills needed to conduct it, and the locus of responsibility for conducting it. Under Enterprise IT Design, the main purpose of EA is to guide the process of planning and designing an enterprise's IT / IS capabilities to meet the desired organizational objectives, often by greater alignment between IT/IS and business concerns. Architecture proposals and decisions are limited to

7030-448: The methodology has been to define all functions related to each business process and identify associated data elements. Once identified, duplication of function and inconsistency in data definition can be identified and resolved, . The Department of Veterans Affairs at the beginning of the 21st century planned to implement an enterprise architecture fully based on the Zachman Framework. Eventually, an enterprise architecture repository

7125-493: The organization's mission. The main difference between these two definitions is that Zachman's concept was the creation of individual information systems optimized for business, while NIST's described the management of all information systems within a business unit. The definitions in both publications, however, agreed that due to the "increasing size and complexity of the [i]mplementations of [i]nformation systems... logical construct[s] (or architecture) for defining and controlling

7220-412: The other, it is still a fundamentally structural representation of the enterprise and not a flow representation. One of the strengths of the Zachman Framework is that it explicitly shows a comprehensive set of views that can be addressed by enterprise architecture. Some feel that following this model completely can lead to too much emphasis on documentation, as artifacts would be needed for every one of

7315-551: The product used to describe the architecture of a system is called an architectural description . In practice, an architectural description contains a variety of lists, tables, and diagrams. These are models known as views . In the case of EA, these models describe the logical business functions or capabilities, business processes , human roles and actors, the physical organization structure, data flows and data stores , business applications and platform applications, hardware, and communications infrastructure. The first use of

7410-504: The purpose of EA is to foster and maintain the learning capabilities of enterprises so they may be sustainable. Consequently, a great deal of emphasis is put on improving the capabilities of the enterprise to improve itself, to innovate, and to coevolve with its environment. Typically, proposals and decisions encompass both the enterprise and its environment. The benefits of EA are achieved through its direct and indirect contributions to organizational goals. Notable benefits include support in

7505-592: The realms of strategic business planning and management science in general. It may be employed in the (in that time considered more esoteric) areas of enterprise architecture, data-driven systems design, data classification criteria, and more. In the 1987 article "A Framework for Information Systems Architecture" Zachman noted that the term "architecture" was used loosely by information systems professionals, and meant different things to planners, designers, programmers, communication specialists, and others. In searching for an objective, independent basis upon which to develop

7600-461: The rows below. The constraints of lower rows can, but do not necessarily affect the higher rows. Understanding the requirements and constraints necessitates communication of knowledge and understanding from perspective to perspective. The Framework points the vertical direction for that communication between perspectives. The current version (3) of the Zachman Framework categorizes the rows as follows: In summary, each perspective focuses attention on

7695-401: The same coin." The Cutter Consortium described EA as an information and knowledge-based discipline. Zachman Framework The Zachman Framework is an enterprise ontology and is a fundamental structure for enterprise architecture which provides a formal and structured way of viewing and defining an enterprise. The ontology is a two dimensional classification schema that reflects

7790-436: The same fundamental questions, then answers those questions from that viewpoint, creating different descriptive representations (i.e., models), which translate from higher to lower perspectives. The basic model for the focus (or product abstraction) remains constant. The basic model of each column is uniquely defined, yet related across and down the matrix. In addition, the six categories of enterprise architecture components, and

7885-415: The same thing from different perspectives. This creates a holistic view of the environment, an important capability illustrated in the figure. Each row represents a total view of the solution from a particular perspective. An upper row or perspective does not necessarily have a more comprehensive understanding of the whole than a lower perspective. Each row represents a distinct, unique perspective; however,

7980-409: The schedule for implementation. The framework comes with a set of rules: The framework is generic in that it can be used to classify the descriptive representations of any physical object as well as conceptual objects such as enterprises. It is also recursive in that it can be used to analyze the architectural composition of itself. Although the framework will carry the relation from one column to

8075-428: The system's implementation and operational costs, and minimization of replicate infrastructure services across business units; reduction in IT complexity, consolidation of data and applications, and improvement of interoperability of the systems; more open and responsive IT as reflected through increased accessibility of data for regulatory compliance , and increased transparency of infrastructure changes; and

8170-401: The term "enterprise architecture" is often incorrectly attributed to John Zachman 's 1987 A framework for information systems architecture . The first publication to use it was instead a National Institute of Standards (NIST) Special Publication on the challenges of information system integration. The NIST article describes EA as consisting of several levels. Business unit architecture is

8265-588: The thirty cells in the framework. Zachman, however, indicates that only the facts needed to solve the problem under analysis need be populated. John Zachman clearly states in his documentation, presentations, and seminars that, as framework, there is flexibility in what depth and breadth of detail is required for each cell of the matrix based upon the importance to a given organization. An automaker whose business goals may necessitate an inventory and process-driven focus, could find it beneficial to focus their documentation efforts on What and How columns. By contrast,

8360-464: The thirty-six necessary categories for completely describing anything; especially complex things like manufactured goods (e.g., appliances), constructed structures (e.g., buildings), and enterprises (i.e., the organization and all of its goals, people, and technologies). The framework provides six different transformations of an abstract idea (not increasing in detail, but transforming) from six different perspectives. It allows different people to look at

8455-441: The timeliness of requirements elicitation and the accuracy of requirement definitions through publishing of the EA documentation. Other benefits include contribution to optimal system designs and efficient resource allocation during system development and testing; enforcement of discipline and standardization of IT planning activities and contribution to a reduction in time for technology-related decision making; reduction of

8550-571: The top level and might be a total corporate entity or a sub-unit. It establishes for the whole organization necessary frameworks for "satisfying both internal information needs" as well as the needs of external entities, which include cooperating organizations , customers , and federal agencies . The lower levels of the EA that provide information to higher levels are more attentive to detail on behalf of their superiors. In addition to this structure, business unit architecture establishes standards , policies , and procedures that either enhance or stymie

8645-514: The underlying interrogatives that they answer, form the columns of the Zachman Framework and these are: In Zachman's opinion, the single factor that makes his framework unique is that each element on either axis of the matrix is explicitly distinguishable from all the other elements on that axis. The representations in each cell of the matrix are not merely successive levels of increasing detail, but actually are different representations—different in context, meaning, motivation, and use. Because each of

8740-401: The ‘sub-contractor’ (being the out-of-context vendor solution components). The Who, When and Why columns were brought into public view, the notion of the four levels of metaframeworks and a depiction of integration associations across the perspectives were all outlined in the paper. Keri Anderson Healey assisted by creating a model of the models (the framework metamodel) which was also included in

8835-613: Was created at the macro level by the Zachman framework and at a cell level by the meta-model outlined below. This diagram has been incorporated within the VA-EA to provide a symbolic representation of the metamodel it used, to describe the One-VA Enterprise Architecture and to build an EA Repository without the use of Commercial EA Repository Software. It was developed using an object oriented database within

8930-739: Was generally limited to some aspects of application development within the Information Systems community". In 2008 Zachman Enterprise introduced the Zachman Framework: The Official Concise Definition as a new Zachman Framework standard. Since the 1990s several extended frameworks have been proposed, such as: The basic idea behind the Zachman Framework is that the same complex thing or item can be described for different purposes in different ways using different types of descriptions (e.g., textual, graphical). The Zachman Framework provides

9025-481: Was that none of the commercial repository tools then available provided a true Zachman Framework representation, and were highly proprietary, making it difficult to incorporate components from other vendors or from open source. This diagram emphasizes several important interpretations of the Zachman Framework and its adaptation to information technology investment management . Row-six provides measured return on investment for Individual Projects and, potentially, for

#813186