The Zackman Framework 1987 - John Zachman published the Zachman Framework for Enterprise Architecture. He wrote "To keep the business from disintegrating, the Background 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. 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. Purpose 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. Scope The framework provides the blueprint, or architecture, for an organization's information infrastructure.
Structure The purpose of the framework is to provide a basic structure which supports, organization, Background access, integration, interpretation, development, Intent 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. Purpose
Scope
Structure 1987 - John Zachman published the Zachman Framework for Enterprise Architecture. He wrote "To keep the business from disintegrating, the Background 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. Intent
The Zachman Framework describes a holistic model of an enterprise's information infrastructure from six Purpose perspectives: planner, owner, designer, builder, subcontractor, and the working system. There is no guidance on sequence, process, or Scope 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 Structure regardless of the order in which they are established. 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 Purpose be very useful in making decisions about changes or extensions. The framework contains 6 rows and 6 columns yielding 36 unique cells or aspects. Scope See the framework diagram.
Structure Evolution of Zackman Framework
1984->1987->1992->1993->2001->2002->2003->2004->2011 Zachman Framework
Row 1 – Scope External Requirements and Drivers Business Function Modeling What How Where Who When Why
Row 2 – Enterprise Model 1 Contextual Contextual Business Process Models
2 Conceptual Conceptual Row 3 – System Model Logical Models Requirements Definition 3 Logical Logical
Row 4 – Technology Model Physical Physical Physical Models 4 Solution Definition and Development 5 As Built As Built Row 5 – As Built As Built Functioning Functioning Deployment 6
What How Where Who When Why Row 6 – Functioning Enterprise Functioning Enterprise Evaluation 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. 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 delegationWHEN of authority, and the horizontal represents the Represents assignment time, of responsibility. 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. Zackman Framework Rules
Basic Model = Entities and Relationships
Relationship Entity Entity
Rule 1: Columns have no order
Rule 2: Each column has a simple, basic model What How Where Who When Why Contextual Contextual Rule 3: Basic model of each column is unique Conceptual Conceptual
Logical Logical Rule 4:
Each row represents a distinct view Physical Physical
Rule 5: As Built As Built Each cell is unique Functioning Functioning
Rule 6: What How Where Who When Why Combining the cells in one row forms a complete description from that view Zackman Framework – Row 1 Scope / Planner’s View
Motivation / Why Business goals, objectives and External Requirements and performance measures related to each Drivers function Function / How Business Function Modeling High-level business functions
Data / What High-level data classes related to each function What How Where Who When Why 1 Contextual Contextual People / Who Stakeholders related to each function Conceptual Conceptual
Logical Logical Network / Where locations related to each function Physical Physical
As Built As Built Time / When Cycles and events related to each Functioning Functioning function What How Where Who When Why Zackman Framework – Row 2 Enterprise Model / Designer’s View
Motivation / Why Business Process Models Policies, procedures and standards for each process Business Function Allocation Elimination of Function Function / How Business processes Overlap and Ambiguity
Data / What Business data What How Where Who When Why
Contextual Contextual People / Who roles and responsibilities in each process 2 Conceptual Conceptual
Logical Logical Network / Where locations related to each process Physical Physical
As Built As Built Time / When Events for each process and sequencing Functioning Functioning of integration and process improvements What How Where Who When Why Zackman Framework – Row 3 System Model / Designer’s View
Motivation / Why policies, standards and procedures associated with a business rule model Logical Models Project Management Function / How Requirements Definition Logical representation of information systems and their relationships
Data / What Logical data models of data and data relationships underlying information What How Where Who When Why
Contextual Contextual People / Who Logical representation of access privileges Conceptual Conceptual constrained by roles and responsibilities 3 Logical Logical Network / Where Logical representation of the distributed Physical Physical system architecture for locations
As Built As Built Time / When Logical events and their triggered responses Functioning Functioning constrained by business events and their responses What How Where Who When Why Zackman Framework – Row 4 Technology Model / Builder’s View
Motivation / Why business rules constrained by information Physical Models systems standards Technology Management Function / How Specifications of applications that operate Solution Definition and on particular technology platforms Development
Data / What Database management system (DBMS) type requirements constrained by logical data models What How Where Who When Why
Contextual Contextual People / Who Specification of access privileges to Conceptual Conceptual specific platforms and technologies
Logical Logical Network / Where Specification of network devices and their Physical Physical relationships within physical boundaries 4
As Built As Built Time / When Specification of triggers to respond to system Functioning Functioning events on specific platforms and technologies What How Where Who When Why Zackman Framework – Row 5 As Built / Integrator’s View
Motivation/Why business rules constrained by specific As Built technology standards Configuration Management Function / How Deployment Programs coded to operate on specific technology platforms
Data / What Data definitions constrained by physical data models What How Where Who When Why
Contextual Contextual People / Who Access privileges coded to control access Conceptual Conceptual to specific platforms and technologies
Logical Logical Network / Where Network devices configured to conform to Physical Physical node specifications 5 As Built As Built Time / When Timing definitions coded to sequence Functioning Functioning activities on specific platforms and technologies What How Where Who When Why Zackman Framework – Row 6 Functioning Enterprise/User’s View
Motivation / Why Functioning Enterprise Operating characteristics of specific technologies constrained by standards Operations Management Evaluation Function / How Functioning computer instructions
Data / What Data values stored in actual databases What How Where Who When Why
Contextual Contextual People / Who personnel and key stakeholders Conceptual Conceptual working within their roles and responsibilities
Logical Logical Network / Where Sending and receiving messages Physical Physical
Integrated Integrated Time / When Timing definitions operating to sequence Functioning Functioning activities 6 What How Where Who When Why Zackman’s Framework for Information Systems Architecture What How Where Who When Why
R Data Function Network People Time Motivation E Q List of Things List of Processes the List of Locations List of Organizations List of Events List of Business U Scope / Important to Business Business Performs Important to Business Important to Business Significant to Business Goals/Strategies I R Contextual E M E Planner / N Entity=Class of Function=Class of Node=Major Business Time=Major Business End/Means=Major T Investor Business Thing Business Process Location Agent=Class of Agent Event Business Goal S e.g., Semantic / Entity e.g., Function Flow e.g., Logistics Network e.g., Organization e.g., Master Schedule e.g., Business Plan A Enterprise e.g.,Relationship Semantic / Entity Diagram Chart N Relationship A Model / Diagram L Diagram Y Business Model S / Conceptual Node=Business End=Business I Location Objectives S Ent=Business Entity Function=Business Link=Business Agent=Org Unit Time= Business Event Means=Business Owner Rel=BusinessEnt=Business Rule Entity Process Linkage Work=Work Product Cycle=Business Cycle Strategy Rel=Business Rule Information e.g., Data Model e.g., Data Flow Diagram e.g., Distributed e.g., Human Interface e.g., Processing e.g., Knowledge D System Architecture Structure Structure Architecture E System Analyst Eng Secy S Model I Phone WS WS G Entity=Data Entity N Relationship= Data Funct=Appl Function Node=Info Sys Funct Agent=Role Time=Trigger End=Criterion Designer Relationship Arg=User Views Link=Line Char Work=Job Cycle=Component Cycle Means=Option
e.g., Data Design e.g., Structure Chart e.g., System / Technology e.g., Human/ e.g., Control Structure e.g., Knowledge Technology l Architecture Technology Interface Organization D Analyst Eng Secy E Model V Phone WS WS E Entity=Segment/Row Funct=Computer Funct Node=Hardware/ L Builder Relationship=Pointer/ Arg=Screen/Device System Software Agent=User Time=Execute End=Condition O Key Formats Link=Line Specification Work=Job Cycle=Component Cycle Means=Action P M Components / e.g., Data Definition e.g., Program e.g., Network e.g., Security e.g., Timing Definition e.g., Knowledge E Detailed Description Architecture Architecture Definition N representations T Integrator / Ent=Fields Funct=Language Stmts Node=Addresses Agent=Identity Time=Interrupt End= Subcontractor Rel=Addresses Arg=Control Blocks Link=Protocols Work=Transaction Cycle=Machine Cycle Means Functioning e.g., Data e.g., Function e.g., Network e.g., Organization e.g., Schedule e.g., Strategy System / Users 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 As- Is status before implementing it. Software Architecture Zackman and TOGAF Frameworks
Enterprise Architecture
Enterprise Architecture
Enterprise Architecture Example case
CEO
Business CIO Manager
Enterprise Architecture
Enterprise Architecture
Enterprise Architecture
The Open Group Architecture Framework (TOGAF) Open Group Tech. version (developed) till ver. 7 Enterprise CapGemini version HP ver. 8 NEC onwards EDS IBM Developed framework provides a step-wise approach to understand reqs., design, plan, build, implement, maintain 55-60 and for governance of an enterprise architecture members Architecture is typically modelled (present) at 4 levels/domains Curr. version Business, Application, Data 9.1 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. The Open Group Architecture Framework (TOGAF) Open Group Tech. version (developed) till ver. 7 Enterprise CapGemini version HP ver. 8 NEC onwards EDS IBM Developed framework provides a step-wise approach to understand reqs., design, plan, build, implement, maintain 55-60 and for governance of an enterprise architecture members Architecture is typically modelled (present) at 4 levels/domains Curr. version Business, Application, Data 9.1 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.
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.
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.
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.
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.
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.
TOGAF Enterprise Continuum and ADM
3
1
2
TOGAF Enterprise Continuum and ADM
3
1
Good architecture will depend on experience of TOGAF Consultant
2
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.
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.