The Zackman Framework

Transcription

1 The Zackman Framework

2 John Zachman published the Zachman Framework for Enterprise Architecture. He wrote "To keep the business from disintegrating, the concept of information systems architecture is becoming less of an option and more of a necessity." This framework is used most frequently for business and industry information systems. Background Intent The Zachman Framework is influenced by principles of classical architecture that establish a common vocabulary and set of perspectives for describing complex enterprise systems. This influence is reflected in the set of rules that govern an ordered set of relationships that are balanced and orthogonal. By designing a system according to these rules, the architect can be assured of a design that is clean, easy to understand, balanced, and complete in itself. The framework provides the blueprint, or architecture, for an organization's information infrastructure. Purpose Scope Structure

3 The purpose of the framework is to provide a basic structure which supports, organization, access, integration, interpretation, development, management, and changing of a set of architectural representations of the organizations information systems. Such objects or descriptions of architectural representations are usually referred to as Artifacts. Background Intent Purpose Scope Structure

4 John Zachman published the Zachman Framework for Enterprise Architecture. He wrote "To keep the business from disintegrating, the concept of information systems architecture is becoming less of an option and more of a necessity." This framework is used most frequently for business and industry information systems. Background Intent The Zachman Framework describes a holistic model of an enterprise's information infrastructure from six perspectives: planner, owner, designer, builder, subcontractor, and the working system. There is no guidance on sequence, process, or implementation of the framework. The focus is on ensuring that all aspects of an enterprise are well-organized and exhibit clear relationships that will ensure a complete system regardless of the order in which they are established. Purpose Scope Structure

5 Background Intent A simple concept with powerful implications. By understanding any particular aspect of a system at any point in its development, system designers construct a tool that can be very useful in making decisions about changes or extensions. The framework contains 6 rows and 6 columns yielding 36 unique cells or aspects. See the framework diagram. Purpose Scope Structure

6 Evolution of Zackman Framework 1984->1987->1992->1993->2001->2002->2003->2004->2011

7 Zachman Framework Row 1 Scope External Requirements and Drivers Business Function Modeling Row 2 Enterprise Model Business Process Models Row 3 System Model Logical Models Requirements Definition Row 4 Technology Model Physical Models Solution Definition and Development Row 5 As Built Deployment As Built Row 6 Functioning Enterprise Functioning Enterprise Evaluation What How Where Who When Why 1 Contextual Contextual 2 Conceptual Conceptual 3 Logical Logical 4 Physical Physical 5 As Built As Built 6 Functioning Functioning What How Where Who When Why

8 Understanding Rows in ZF Scope. Corresponds to an executive summary for a planner who wants an estimate of the size, cost, and functionality of the system. Business model. Shows all the business entities and processes and how they interact. System model. Used by a systems analyst who must determine the data elements and software functions that represent the business model. Technology model. Considers the constraints of tools, technology, and materials. Components. Represent individual, independent modules that can be allocated to contractors for implementation. Working system. Depicts the operational system.

9 Understanding Columns in ZF WHO Represents the people relationships within the enterprise. The design of the enterprise organization has to do with the allocation of work and the structure of authority and responsibility. The vertical dimension represents delegation WHENof authority, and the horizontal represents the assignmenttime, of responsibility. Represents or the event relationships that establish performance criteria and quantitative levels for enterprise resources. This is useful for designing the master schedule, the processing architecture, control architecture, and timing devices. WHY Describes the motivations of the enterprise. This reveals the enterprise goals and objectives, business plan, knowledge architecture, and knowledge design. WHAT Describes the entities involved in each perspective of the enterprise. Examples include business objects, system data, relational tables, or field definitions. HOW Shows the functions within each perspective. Examples include business processes, software application function, computer hardware function, and language control loop. WHERE Shows locations and interconnections within the enterprise. This includes major business geographical locations, separate sections within a logistics network, allocation of system nodes, or even memory addresses within the system.

10 Zackman Framework Rules Basic Model = Entities and Relationships Relationship Entity Entity Rule 1: Columns have no order Rule 2: What Each column has a simple, basic model Where Who When Why Contextual Contextual Conceptual Conceptual Logical Logical Each row represents a distinct view Physical Physical Rule 5: As Built As Built Functioning Functioning Rule 3: Basic model of each column is unique How Rule 4: Each cell is unique Rule 6: Combining the cells in one row forms a complete description from that view What How Where Who When Why

11 Zackman Framework Row 1 Scope / Planner s View Motivation / Why Business goals, objectives and performance measures related to each function Function / How High-level business functions External Requirements and Drivers Business Function Modeling Data / What High-level data classes related to each function People / Who Stakeholders related to each function Network / Where locations related to each function Time / When Cycles and events related to each function What 1 How Where Who When Why Contextual Contextual Conceptual Conceptual Logical Logical Physical Physical As Built As Built Functioning Functioning What How Where Who When Why

12 Zackman Framework Row 2 Enterprise Model / Designer s View Motivation / Why Policies, procedures and standards for each process Function / How Business processes Business Process Models Business Function Allocation Elimination of Function Overlap and Ambiguity Data / What Business data What People / Who roles and responsibilities in each process Network / Where locations related to each process Time / When Events for each process and sequencing of integration and process improvements 2 How Where Who When Why Contextual Contextual Conceptual Conceptual Logical Logical Physical Physical As Built As Built Functioning Functioning What How Where Who When Why

13 Zackman Framework Row 3 System Model / Designer s View Motivation / Why policies, standards and procedures associated with a business rule model Function / How Logical representation of information systems and their relationships Logical Models Project Management Requirements Definition Data / What Logical data models of data and data relationships underlying information What People / Who Logical representation of access privileges constrained by roles and responsibilities Network / Where Logical representation of the distributed system architecture for locations Time / When Logical events and their triggered responses constrained by business events and their responses 3 How Where Who When Why Contextual Contextual Conceptual Conceptual Logical Logical Physical Physical As Built As Built Functioning Functioning What How Where Who When Why

14 Zackman Framework Row 4 Technology Model / Builder s View Motivation / Why business rules constrained by information systems standards Function / How Specifications of applications that operate on particular technology platforms Physical Models Technology Management Solution Definition and Development Data / What Database management system (DBMS) type requirements constrained by logical data models What People / Who Specification of access privileges to specific platforms and technologies Network / Where Specification of network devices and their relationships within physical boundaries Time / When Specification of triggers to respond to system events on specific platforms and technologies 4 How Where Who When Why Contextual Contextual Conceptual Conceptual Logical Logical Physical Physical As Built As Built Functioning Functioning What How Where Who When Why

15 Zackman Framework Row 5 As Built / Integrator s View Motivation/Why business rules constrained by specific technology standards Function / How Programs coded to operate on specific technology platforms As Built Configuration Management Deployment Data / What Data definitions constrained by physical data models What People / Who Access privileges coded to control access to specific platforms and technologies Network / Where Network devices configured to conform to node specifications Time / When Timing definitions coded to sequence activities on specific platforms and technologies 5 How Where Who When Why Contextual Contextual Conceptual Conceptual Logical Logical Physical Physical As Built As Built Functioning Functioning What How Where Who When Why

16 Zackman Framework Row 6 Functioning Enterprise/User s View Motivation / Why Operating characteristics of specific technologies constrained by standards Function / How Functioning computer instructions Functioning Enterprise Operations Management Evaluation Data / What Data values stored in actual databases What People / Who personnel and key stakeholders working within their roles and responsibilities Network / Where Sending and receiving messages Time / When Timing definitions operating to sequence activities 6 How Where Who When Why Contextual Contextual Conceptual Conceptual Logical Logical Physical Physical Integrated Integrated Functioning Functioning What How Where Who When Why

17 Zackman s Framework for Information Systems Architecture R E Q U I R E M E N T S A N A L Y S I S Scope / Contextual Planner / Investor Enterprise Model / Business Model / Conceptual Owner D E S I G N D E V E L O P M E N T Information System Model Designer Technology Model Builder Components / Detailed representations Integrator / Subcontractor Functioning System / Users What How Where Data Function Network People Time Motivation List of Things Important to Business List of Processes the Business Performs List of Locations Important to Business List of Organizations Important to Business List of Events Significant to Business List of Business Goals/Strategies Entity=Class of Business Thing Function=Class of Business Process Node=Major Business Location Agent=Class of Agent Time=Major Business Event End/Means=Major Business Goal e.g., Function Flow Diagram e.g., Logistics Network e.g., Master Schedule e.g., Business Plan e.g., Semantic / Entity e.g., Semantic / Entity Relationship Relationship Diagram Diagram Ent=Business Entity Ent=BusinessRule Entity Rel=Business Rel=Business Rule e.g., Data Model Entity=Data Entity Relationship= Data Relationship e.g., Data Design l Function=Business Process e.g., Data Flow Diagram Who When e.g., Organization Chart Why Node=Business Location Link=Business Linkage Agent=Org Unit Work=Work Product Time= Business Event Cycle=Business Cycle End=Business Objectives Means=Business Strategy e.g., Distributed System Architecture e.g., Human Interface Structure e.g., Processing Structure e.g., Knowledge Architecture Analyst Eng Secy Phone WS WS Funct=Appl Function Arg=User Views Node=Info Sys Funct Link=Line Char Agent=Role Work=Job Time=Trigger Cycle=Component Cycle End=Criterion Means=Option e.g., Structure Chart e.g., System / Technology Architecture e.g., Human/ Technology Interface e.g., Control Structure e.g., Knowledge Organization Analyst Eng Secy Phone WS WS Entity=Segment/Row Relationship=Pointer/ Key Funct=Computer Funct Arg=Screen/Device Formats Node=Hardware/ System Software Link=Line Specification Agent=User Work=Job Time=Execute Cycle=Component Cycle End=Condition Means=Action e.g., Data Definition Description e.g., Program e.g., Network Architecture e.g., Security Architecture e.g., Timing Definition e.g., Knowledge Definition Ent=Fields Rel=Addresses Funct=Language Stmts Arg=Control Blocks Node=Addresses Link=Protocols Agent=Identity Work=Transaction Time=Interrupt Cycle=Machine Cycle End= Means e.g., Data e.g., Function e.g., Network e.g., Organization e.g., Schedule e.g., Strategy

18 Conclusion The Zachman Framework is one of the renowned frameworks that is comprehensive and simple to understand. Some drawbacks of this framework for the modeling of information systems may be summarized in the following. ZF has large amount of documentations (in detailed texts, modeling diagrams and charts) for each of ZF's cell (for each of 36 cells). ZF doesn't have any consideration to As-Is of the Information Systems. ZF considers only establishing of new architectures for information systems of enterprises without considering the previous systems (As-Is status of systems). Whereas, the most enterprises information systems need to consider to AsIs status before implementing it.

19 Software Architecture Zackman and TOGAF Frameworks

20 Enterprise Architecture

21 Enterprise Architecture

22 Enterprise Architecture Example case CEO CIO Business Manager

23 Enterprise Architecture

24 Enterprise Architecture

25 Enterprise Architecture

26 The Open Group Architecture Framework (TOGAF) Open Group (developed) CapGemini HP NEC EDS IBM members (present) Curr. version 9.1 Tech. version till ver. 7 Enterprise version ver. 8 onwards Developed framework provides a step-wise approach to understand reqs., design, plan, build, implement, maintain and for governance of an enterprise architecture Architecture is typically modelled at 4 levels/domains Business, Application, Data and Technology Complements Zachman TOGAF is a process-driven framework. Zachman tells you how to categorise artifacts; TOGAF provides a process for creating them. Central process is called Architecture Development Method (ADM) ADM is a recipe for creating architecture. Using ADM, an architect can develop different aspects of an Enterprise Architecture to meet business and IT needs of an organization. ADM should be adapted to each organization's needs for architecture planning activities.

27 The Open Group Architecture Framework (TOGAF) Open Group (developed) CapGemini HP NEC EDS IBM members (present) Curr. version 9.1 Tech. version till ver. 7 Enterprise version ver. 8 onwards Developed framework provides a step-wise approach to understand reqs., design, plan, build, implement, maintain and for governance of an enterprise architecture Architecture is typically modelled at 4 levels/domains Business, Application, Data and Technology Complements Zachman TOGAF is a process-driven framework. Zachman tells you how to categorise artifacts; TOGAF provides a process for creating them. Central process is called Architecture Development Method (ADM) ADM is a recipe for creating architecture. Using ADM, an architect can develop different aspects of an Enterprise Architecture to meet business and IT needs of an organization. ADM should be adapted to each organization's needs for architecture planning activities.

28

29 ADM Key Points The ADM is iterative, over the whole process, between phases, and within phases. For each iteration of the ADM, a fresh decision must be taken as to: Breadth of coverage of the enterprise to be defined (Defined Coverage) Level of detail to be defined ( Defined Details) Extent of the time horizon aimed at, including the number and extent of any intermediate time horizons (Defined Timeline) Architectural assets to be leveraged in the organization's Enterprise Continuum, including: ( Defined Reusability) Assets created in previous iterations of the ADM cycle within the enterprise Assets available elsewhere in the industry (other frameworks, systems models, vertical industry models, etc.) These decisions need to be made on the basis of, Practical assessment of resource and competence availability, and Value that can realistically be expected to accrue to the enterprise from chosen scope of the architecture work.

30 ADM Key Points As a generic method, the ADM is intended to be used by enterprises in a wide variety of different geographies and applied in different vertical sectors / industry types. As such, it may be, but does not necessarily have to be, tailored to specific needs. For example, It may be used in conjunction with the set of deliverables of another framework, where these have been deemed to be more appropriate for a specific organization. For example, many US federal agencies have developed individual frameworks that define the deliverables specific to their particular departmental needs. It may be used in conjunction with the well-known Zachman Framework, which is an excellent classification scheme, but lacks an openly available, well-defined methodology.

31 ADM Key Points In addition to the method itself being iterative, there is also iteration within the ADM cycle, both among the individual phases and among the steps within each phase. Throughout the ADM cycle, there needs to be frequent validation of results against the original expectations Both those for the whole ADM cycle, and those for the particular phase of the process. Note that output is generated throughout the process, and that the output in an early phase may be modified in a later phase. The versioning of output is managed through version numbers. The ADM numbering scheme can be provided. It should be adapted by the architect to meet the requirements of the organization and to work with the architecture tools and repositories employed by the organization.

32

33

34

35

36 The objective is to define the major types and source of data necessary to support the business. It is NOT about database design. The goal is to define the data entities relevant to the enterprise. Target information and application architecture.

37

38

39 Enterprise Continuum TOGAF views the Enterprise Architecture as a continuum of architectures, ranging from the highly generic to the highly specific. It views the process of creating a specific enterprise architecture as moving from the generic to the specific. TOGAF s ADM provides a process for driving this movement from the generic to the specific.

40 TOGAF Enterprise Continuum and ADM 3 1 2

41 TOGAF Enterprise Continuum and ADM 3 1 Good architecture will depend on experience of TOGAF Consultant 2

42 Reference Model for Open Distributed Processing (RM-ODP) It provides a framework for specification of distributed computing systems. It is based on, current practices in distributed processing community, and use of formal description techniques for specification of architectures. It combines the concepts of open systems (supplier independent) in specifying distributed systems. Found to be very useful and widely adopted. RM-ODP framework is the origin of the famous 4+1 view model. RM-ODP guides the modeling process of systems architecture Gives five view points that are considered essential. Enterprise viewpoint, Information viewpoint, Computational viewpoint, Engineering viewpoint, and Technology viewpoint.

43 Summary TOGAF provides a set of foundation architectures to aid architects understand the present and future needs of the architecture In enterprise version, TOGAF was expanded to cover business, application and information aspects of EA. The process of these is not as fully developed as the process for the technical architecture The relationships between different aspects of architecture are also not completely captured and documented. One main criticism It is concerned with the process of developing artefacts. There is no emphasis on the quality or the format of the artefacts.