Information for

Request for

Send us an email Microsoft Partner Network membership
Microsoft BizSpark Startup member
VMWare member
Valid XHTML 1.0 Transitional Valid CSS!

Postcode Anywhere

PayPal for Business



Home -> Development -> Zachman Framework within Enterprise Unified Process (EUP)
ATL - Zachman Framework

Zachman Framework within Enterprise Unified Process (EUP)

It is possible to apply the ZF successfully within the RUP/EUP if you focus on its strengths and address its weaknesses. Figure 1 shows how we have extended the ZF so that it aligns with the RUP/EUP disciplines. As you can see we have made significant changes to it:

  1. Replaced the six rows with the sixteen disciplines of the EUP, providing a more finely detailed collection of views. The enterprise management columns are listed first then the project-level disciplines to remain consistent with the ZF’s top-down approach. The primary benefit of showing the disciplines as rows is that it makes it clear how to apply the questions represented by the framework columns to each aspect of the EUP. Unfortunately this approach could exacerbate many of the weaknesses of the ZF.

  2. Introduced addition of a 7th column for costing. The cells of this column, for the most part, identify the potential savings which you should achieve by implementing the discipline effectively. Yes, you will still incur the operational costs of performing the activities of each discipline but to simplify the chart we don't indicate this information. Interestingly, in German all the columns can be labelled with single word interrogatives starting with the letter "w"[md] was, wie, wo, wer, wann, warum, and wieviel respectively.

  3. Changed the first column, which addresses the question of “what”, is really a structural issue and not a data issue. This simple generalization helps to remove the data-oriented bias of the ZF, making it clear that you have more options available to you than data-oriented artifacts.

  4. The cells describe the issues to address. Each cell indicates the potential issue(s) to address, if any, as well as suggest a potential artifact to explore those issue(s). Some cells are left blank because the column isn’t applicable to the discipline.

Figure 1 The Zachman Framework within Enterprise Unified Process (EUP).

  WHAT
(Structure)
HOW
(Function / Activities)
WHERE
(Locations)
WHO
(People)
WHEN
(Time)
WHY
(Motivation)
COST / BENEFIT
(Finance)
Enterprise Managment Disciplines Enterprise Business Modeling Most significant business concepts (Enterprise Glossary) Enterprise business processes (Process Model) International view of locations (Location Map) Organisational strategy (Organisation Chart) Business events and planning Enterprise vision / mission Corporate financials
Portfolio Management List of systems and inter-relationships Map business processes to systems Map project teams to locations Project team assignments IT planning IT vision Savings from improved management
Enterprise Architecture Domain Architecture (UML component diagram) Workflow Architecture Physical Network Architecture (UML deployment diagram) Actaul and potential interactions Middleware and scheduling Architecture Enterprise Technical Requirements Savings from common architecture(s)
Strategic Reuse Domain components Functions (Web services, CICS transactions)   User interface components   Rulebase Saving from reusable components
People Management Positions and relationships between positions Roles played in each location and relationships between roles Offices and relationships between them Hurman resource philosophies and strategies Annual reviews & appraisals, project milestones Career management strategies Savings from improved team configurations
Enterprise Administration Information assets (Corporate data sources, licenses, etc) Guidance (Standards and guidelines) Physical assets Security policy     Savings from common platforms, guidance, and corp. licensing
Software Process Improvement   Software process definition Span of software process (e.g. divisional va gloabl) Software engineering process group (SEPG) mandate   IT department improvement goals Savings from improved processes
Core Development Disciplines Business modeling Most significant business concepts (Project Glossary) Project mission, strategies process (Process model) Project view of locations (Location Map) Affected positions (Organisation Chart) Business events System vision / mission Savings from reengineered business processes
Requirements Domain model (CRC Cards, UML Class Model) Usage of the system (Use cases)   Users of the system (Actors, Personas) Timing requirements (Use cases, business rules) Business policies and technical requirements Savings from improved understanding of stakeholder needs
Analysis and Design Structural design (UML Class Diagram, Physical Data Model) Implementation design of domain classes / services Map of processes to location User Interface Design Scheduled events Business rules and 'ilities'  
Implementation Source code and data definition language (DDL) Source code and DDL Hardware, network, middleware Implementation of user interface Implementation of system triggers Implementation of business rules  
Test Test suite Tests Testing framework Test plan Test and defect tracking strategy Quality goals Savings from improved quality
Deployment Installation packages Installation scripts         Savings to deploy system (includes training end users)
Supporting Disciplines Configuration and Change Management Configuration builds (CM) Build scripts CM repository C&CM plan C&CM strategy Quality goals  
Project Management Project task list (Gantt chart) Project schedule (Gantt chart) Team work arae strategy Staffing plan Project schedule (Gantt chart) Project charter  
Environment List of required tools and guidance Tool installation plan          
Operations & Support Deployed classes, components, tables, etc Deployed functions and operations Deployed hardwar, middleware, and software Deployed user interface (including documentation) Deployed systems Deployed software  

It’s important to recognize that using the ZF is optional within the EUP – It provides very good guidance for your modeling and development efforts because it reminds you of the critical issues which you need to address. The following advice should help you to apply this enhanced version of the ZF with your organization:

  • Keep it simple. You don’t need to create artifacts for all of the cells, the important thing is that you at least consider the issues for that cell. You can in fact be quite agile with the ZF if you choose. The secret is to avoid documentation-heavy, bureaucratic processes centered around the ZF. Remember, your goal is to develop working software not to create lots of fancy models and documentation.

  • Remember that you have choices. Each cell indicates the required perspective, not suggested models. For example, in the Structure column, David Hay suggests that you create a language-divergent data model in row 2, a convergent entity/relationship model in row 3, and a database design in row 4 of the ZF. Moriarty suggests a business class diagram, a class diagram, and a schema data model respectively in the same rows. Object developers would probably suggest a component model, a class diagram, and another class diagram for these rows. All three approaches are valid, but all three represent the experiences and prejudices of the individual methodologists. Far better advice would be to understand the perspective represented by each box, understand the strengths and weaknesses of each type of modeling artifact, and then apply the right artifact(s).

-> Abstract Technology's Offshore Development Center
-> Abstract Technology software development process
-> Abstract Technology free pilot trial

Home | Contact us | Site map | Terms of use | Privacy | Resources | Newsletter subscription | FAQ
© 2004 - Abstract Technology Ltd. Online payment enabler and integrator and outsource and offshore development