Zachman Enterprise Architecture Framework Builders Perspective Information Technology Essay

The Enterprise Architecture has revolutionized the way todays enterprises work and operate. The EA as what it is abbreviated, is a major factor in designing, operating, and organizing large scale or small scale enterprises easily and efficiently. John Zachman from IBM pioneered and nurtured the EA concept when it was almost unknown to the world and created his own EA framework. Zachman Framework has played a major role in evolution of many other EA frameworks over a period of last 25 years.

Index Terms- Enterprise Architecture, Zachman Framework, Builder’s Row, history, case studies.

INTRODUCTION

THIS paper tries to analyze the details of the Enterprise architecture in general and Zachman Framework in specific. We will give special attention to the fourth row viz. the Builder’s Row of the framework. During this entire paper you will see some examples and case studies of the real life implementation of the Enterprise Architecture or the Zachman Framework.

Enterprise architecture

The enterprise architecture, abbreviated as EA, is an engineering art of designing, implementing and operating a generic enterprise. EA can be termed as framework/guide/rules for comprehensive set of models relevant for describing an enterprise. The EA defines the optimum and long term strategy for an enterprise and helps integrate strategies, business plans, assets, people, operations, projects and planning.

In a nutshell EA is a systematic application of business architecture, technology architecture and strategic planning.

As per the Institute for Enterprise Architecture Development (IFEAD) the key guiding principle of the enterprise architecture discipline is summed up as “No strategic vision, no EA.” What this essentially means is that today’s enterprise architecture is about tomorrow’s business systems. Per IFEAD “An important aspect of this assertion is that enterprise architecture is a holistic discipline that unites business and technology elements based on a single, strategic enterprise vision”.

Enterprise architecture framework

An Enterprise Architecture Framework is a simple, comprehensive, lucid, planning tool that can implement EA. A good well defined EA framework also needs to be a problem solving tool and should always be neutral to any given situation. What this means is that the framework should be flexible enough to match a given situation.

As per John Zachman, “From an Enterprise point of view, you wouldn’t start with a warehouse full of Raw Materials, an office building full of people, and a distribution center full of finished Products and try to form them into a coherent Enterprise!” [] .

Benefits of enterprise architecture

The benefits of EA can be summarized into following points:

Synchronizes all the departments to the core values and missions of the enterprise

Improves interoperability and integration. See Appendix 1 (1)

Brings agility in the processes by:

Storing information from various resources across various departments

Departments and people collaborate thus saving a lot of time and resources

Entities get connected and hence can easily find each other’s useful resources

Systematic cost reduction by maintaining standards and well defined processes

Security improvements due to:

Defined roles and access restrictions

Defined data archival standards and processes

Defined data integrity and confidentiality standards

Systematic system integrations

Improved morale as the individuals see a direct correlation between their work and organization’s success

Benefits of enterprise architecture – real example

Lockheed Martin

Lockheed Martin implemented Federal Enterprise Architecture in 1998 and their achievements are as follows:

1998

2008

18 Different heritages and cultures

1 Corporate Environment

136 Legacy HR/Payroll/Benefits Systems

1 Highly Integrated System

348 Process Variations

1 Uniform Policy and Process

Decentralized Administrative Overheads

Robust Centralized Services/Call Center

$100M Investment

Over $50M in Savings

A major automated information system, the Navy Standard Integrated Personnel System is responsible for performing pay/personnel functions for over 400,000 sailors on ship and shore.

brief history of enterprise architecture

In late 60’s, Dewey Walker, the grandfather of architecture methodologies- Produced architecture planning documents that later became known as Business Systems Planning. At that time he was IBM’s Director of Architecture.

John Zachman, one of Walker’s students has been focusing on Enterprise Architecture since 1970 and has written extensively on the subject. Zachman is also known for his early contributions to IBM’s Information Strategy methodology (Business Systems Planning) as well as to their Executive team planning techniques (Intensive Planning). He published “Business Information Control Study” in the first edition of the IBM Systems Journal in 1982. Zachman became widely recognized for his work, he realized the need enterprise architecture for defining and controlling the integration of systems and their components in an easy manner.

Zachman in his interview with Roger Session said, “During the 1980s, I became convinced that architecture, whatever that was, was the thing that bridged the strategy and its implementation. This led me to investigate other disciplines that manufactured complex engineering products to learn how those disciplines crossed the analogous bridge. I published the result of this investigation in the September 1987 issue of the IBM Systems Journal in an article entitled “A Framework for Information Systems Architecture.”

John A. Zachman is the originator of the “Framework for Enterprise Architecture” which has received broad acceptance around the world as an integrative framework, or “periodic table” of descriptive representations for Enterprises. Very soon he is known as a developer of the “Zachman Framework”. Mr. Zachman retired from IBM in 1990, having served them for 26 years. He is the Chief Executive Officer of his own education and consulting business, Zachman International. He also is Chairman of the Board of Zachman Framework Associates, a worldwide consortium managing conformance to The Zachman Frameworkâ„¢ principles and Chief Executive Officer of the Zachman Institute for Framework Advancement (ZIFA), an organization dedicated to advancing the conceptual and implementation states of the art in Enterprise Architecture. ZI imparts training on EA and ZF.

In 1994, the US Department of Defense came up with the Technical Architecture Framework for Information Management (TAFIM)-an enterprise architectural standard for all defense work. After several iterations, it was discontinued in 2000.

Then, in 1995 first version of The Open Group Architectural Framework (TOGAF) was launched, it used some pieces of TAFIM. Followed closely by Zachman, today, in the private sector, TOGAF is probably the most popular enterprise architecture framework.

The main push for EA in the federal government came in 1996, along with the Clinger-Cohen Act (also known as the Information Technology Management Reform Act (ITMRA) requiring department CIOs to let business needs drive technology buys. Congress passed the Clinger/Cohen act. This act gave the Office of Management and Budget (OMB) widespread authority to dictate standards for “analyzing, tracking, and evaluating the risks and results of all major capital investments made by an executive agency for information systems.”

Evolution of ea frameworks

The above figure represents the evolution of EA frameworks over the period from 1985 to 2005.

Top 4 ea frameworks

As per the MSDN Architecture Center website [] , the top four EA frameworks used in the industry are as follows:

TOGAF – this framework is a creation of the Open Group consortium. Although a framework, this is actually more accurately defined as a process. This framework initially contained only technical architecture but was later updated by inclusion of the business architecture.

FEA – The Federal Enterprise Architecture is owned by the US federal government. It can be viewed as either implemented enterprise architecture or a proscriptive methodology [] for creating enterprise architecture.

The Gartner Methodology – this framework is owned by the Gartner Inc. and can be best described as an enterprise architectural practice.

Zachman Framework – Created by John Zachman in 1984 and later revised, this framework is more accurately defined as taxonomy [] . This is a decision support framework [] and focuses on:

What are the right questions

How do I organize those questions

What do those answers mean

Zachman ea framework

This framework is the oldest EA framework and was created by John Zachman in 1984. It was later revised twice.

Zachman framework properties

The following properties can be associated with Zachman Framework:

Primitive and comprehensive [] 

Cross disciplinary

Influences extending beyond IT

Neutral, applies almost to everything

Provides a standardized global view

Simplicity in application/analysis

Flexibility in application

Standardization and Adaptability

Promotes re-usability. Per Zachman “Reuse and interoperability, does not happen by accident. It is the result of engineering” [] 

Cons of Zachman Framework

The following cons can be associated with Zachman Framework [] :

No methodology attached to it

No standard way to populate it

No clear definitions or examples of the content of cells

Comparison of EAF by Views and Abstractions

Here, we have showed the comparison between few of the top EAF. As we are here Zachman Framework broadly, all other EAF are tried to be explained in the form of Zachman’s terminology (Table 1).

The first view, i.e. planners’ view puts the concepts for the final result or product and may include items such as the relative size, shape, and basic intent of the final structure.

The second view, i.e. owners’ view which may represent an architect’s drawings that the architect has captured as per owners’ prospective.

The third view, i.e. designer view represents the plan that will be committed to construction.

The fourth view, i.e. builder view is where the designers’ plans are modified to reflect how construction will proceed.

The fifth view, i.e. subcontractors’ view represents drawings of parts or subsections of the plans. They are considered “an ‘out-of-context’ specification of what actually will be fabricated or assembled.

The last view represents the final product, building, or project. It is the physical result. From the standpoint of an information system, this would reflect the users’ view and therefore, the functional enterprise.

To add, most of the EAFs studied, provide recommendations for what each of the abstractions represent, but do not provide methods, procedures, or deliverables that are required. All of the EAFs answers questions like WHAT data and HOW i.e. the functionality of the data and system. The frameworks started to differ when comparing the technology and physical aspects of the system, with some providing detailed architectures whereas others were not as specific. In the people abstraction, the frameworks provide the organizational relationships related to implementation of the system. Also, Timelines and justification for the system, as can be represented in the Time and Motivation cells of abstractions respectively, which were found only in Zachman’s Framework.

DoDAF:

The Operations View is depicts activities performed as parts of DoD missions, i.e., the exchanges among organizations or personnel, and reveals the requirements for interoperability and capabilities.

The Systems View describes the actual existing and future systems that support the DoD and how they are physically interconnected.

The Technical View or Technical Standards View gives detailed information the to the points described by the Systems View i.e. by providing information on standard system parts or components that are currently available off the shelf, either commercially or government, and also provides technical detail.

The DoDAF defines more than 26 different architecture products that are organized at least into the four views.

FEAF: Currently, the FEAF corresponds to the first three columns of the Zachman Framework and the Spewak Enterprise Architecture Planning (EAP) methodology. The FEAF contains guidance and is oriented toward enterprise architectures as opposed to IT architectures. The rows of the FEAF matrix correspond to the Zachman Framework, but they do not prescribe the approach for developing the products for each of the cells.

TEAF: TEAF can be described in terms relative to the Zachman Framework, i.e., ‘perspectives’ and ‘views.’ The four perspectives are the same as in the Zachman Framework and FEAF matrix with the exception that TEAF combines the ‘Builder’ and ‘Subcontractor’ into one, named ‘Builder.’ Also, the

TEAF Information view corresponds to the FEAF Data Architecture; the TEAF Functional view corresponds to the FEAF Applications Architecture; and the TEAF Infrastructure view corresponds to the FEAF Technology Architecture. FEAF does not currently reflect the TEAF Organizational view. This view shows the types of workers and the organizational structures. TEAF allows the flexibility to define additional views and perspectives that focus uniquely on areas important to specific stakeholders.

TOGAF: Strong on the Business Architecture and Technical Architecture aspects. It does not provide as much detail from the planning and maintenance aspects. TOGAF is one of the most comprehensive with regards to the actual process involved. This framework provides guidance towards principles for decision making, guidance of IT resources, and architecture principles. The framework is gauged towards open systems development.

Evolution of Zachman Framework [] 

1984

On June of 1984, John A. Zachman showed the world Information Systems Architecture – A Framework which is referred as The Zachman Frameworkâ„¢ in later years. Though it was represented as 3 columns and 6 rows chart, originally it was 6 by 6 matrix by size. As Enterprise Architecture (also this was a Framework for INFORMATION SYSTEMS architecture) was still not in picture, and was never proposed or used in past; he was thinking that people will not appreciate his work fully so instead of 6X6 matrix- he proposed 3 columns and 6 rows chart. To note, Column 1, Row 2 the Chen Diagram, Row 3 contains a Bachman Diagram and Row 4 has an IMS Root-Segment Diagram. John used this chart until he retired from IBM in 1990.

1987

Enterprise Architectures was a outcome of an article published in the IBM Systems Journal in 1987, titled “A framework for information systems architecture” by Zachman. The original Framework for Information Systems Architecture. The Framework was originally published for Information System, and there was no precedent set for thoughts about Organization (Column 4), Timing (Column 5) or Motivation (Column 6).

1992

It was now 6X6 matrix, but in his 1992 IBM Systems Journal article, Zachman still referred it as A Framework for Information Systems Architecture. Now, people started calling This Framework as The Zachman Frameworkâ„¢. Zachman also added words- “Owner,” “Designer,” and “Builder” for clarification to the Rows 2, 3 and 4. John Sowa (co-author of the 1992 article) said, “Oh, we can call Row 1 ‘Planner,’ and Row 5 ‘Sub-Contractor.'” At that time, people did not have much experience or notations for enterprise architecture in other words they were not aware of the cell used in Columns 4, 5 & 6, thus all are kept same down the columns.

1993

This model was in fact a minor carry-over from the 1987 and it was also of 3 columns. Because of the dominant I/S perspective that existed at that time, John used only the first three columns. ‘Zachman Frameworkâ„¢’ is now the official name that now John has decided to go with for his Enterprise Architecture Framework. Also, here he came up with the adjectives like Contextual, Conceptual, Logical, Physical and Out-of Context for defining the Rows of the framework. From the US map (Column 3, Row 1); Zachman made a transition to a World map because of John’s first seminar was in Australia.

2001

Now, Chen Diagram from Column 1, Row 2 is no longer there. Model is also now primitive- the “diamond,” or process (verb) was also removed. Also, the controls and mechanisms (vertical arrows) were removed from the process models in Column 2, Rows 2 & 3. Zachman also added the Functioning Enterprise of Row6, it was never discussed before. In addition, to John’s regret, he named Column 1 “Data,” which he feels inaccurately continued to classify The Zachman Frameworkâ„¢ as a Framework for Information Systems despite having “Enterprise Architecture” titled across the top. In fact, most of the terminology in this Framework is I/S related while also containing quite a few adjectives which makes its directive less precise. Thus, few times he had referred Data Cell as Thing Cell also.

2002

First graphical view of framework was developed by Intervista Institute in Canada. Information Systems terminology was still there in use. Row 6 was once again minimized and the IDEF0 notation in Column 2, Row 2 was also reentered. Intervista Institute had made some significant changes in the framework; one of it was the use of the black to white gradient between the cells – down the columns. This gradient significantly showed that there is more than just a matrix in the framework. This Framework illustration helped to emphasize the Columns.

2003

This framework copy was launched during the existence of ZIFA, and is said that this copy of framework is distributed maximum till now [as per Zachman International]. Other than John, few other ZIFA partners, were unsatisfied with the Intervista version (above) which showed Transformation black-to-white gradient banding down the Columns. Also, Intervista was advertising its logo on the framework copy. Therefore, they commissioned this version, and reverted to the earlier graphic framework with only ZIFA’s reference on it. This new version had I/S terminology, not the current Enterprise terminology, and used many times the less-precise adjectives and also Row 6 was again minimized. Along with this all, the IDEF0 notation made its way back into Column 2, Rows 2 & 3- violating the fundamental rule of The Framework which says that no cell containing composite constructs. Due to the vertical arrows the primitive idea of framework was destroyed making those processes dependent on some control or mechanism. In short, it was not a good decision to revert back. In addition, the colors of Rows 2 and 3 became inverted. Because of the colors of each Row, this Framework illustration emphasizes the Rows.

2003- Graphical view

Developed by Intervista Institute in Canada- This graphical view was a minor variation from 2002. But, this one still had I/S terminology, adjectives and a minimized Row 6.Once again, there was the use of the gradient color banding across the Rows and down the Columns showing the integration (across the Rows) and Transformations (down the Columns) in The Framework. IDEF0 notation was changed in Column 2, Row 2.Circular icons of Column 5- Row 2 were changed as there was no clear idea message conveyed through it. This Framework illustration emphasized both the Rows and Columns.

 2004

Now, this was the time when the framework made the transformation from I/S terminology to Enterprise Architecture terminology. Also, due to this version, the Enterprise is now for business domain and not specifically I/T domain. It clearly defines that the top three Rows deal with the business ideas, while the bottom three Rows deal with operations reality. The main concern now was with the globe in Column 3, Row 1 (Network Identification) because the globe is a physical place, which is an instantiation (Row 6) of the scope (Row 1), whereas the Row 1 models are all lists, not instances. This was corrected in the next version of the framework.

2008

This is the latest version of the Zachman Framework. The globe was moved from Column 3- Row 1 to row 6. From this version of the Zachman Framework, the EA Ontology (theory of existence equal to the Periodic Table of Elements) was expressed very briefly along with this EA Standards were also defined more appropriately. This is said to be the most primitive, generic and normalized model of the Zachman Framework.

Structure of Zachman Framework

The Zachman Framework is composed of 6 rows by 6 columns matrix. The columns are structured as:

Data/Thing/WHAT: Each of the rows in this column address understanding of and dealing with any enterprise’s data. This begins with a list of the things that concern any company in this industry, affecting its direction and purpose.

As per John Zachman, calling Column 1 the Data Column is a misnomer. It should be called the Thing Column because all the cells are descriptive of the Things of the Enterprise. It is only at Row 3 that they become Data Models. However, if I labeled Column 1 the Thing Column, no one would have a sense of what kind of models to expect, as common usage does not include Thing Models, at least, not at the present time. What the entity uses to operate—- Data (Thing) Organization. What it is made of – the material composition of the object, the bill-of materials- for Enterprises, the Thing (Data) Models (Column 1).

Function/HOW: The rows in the function column describe the process of translating the mission of the enterprise into successively more detailed definitions of its operations. HOW the entity operates— Control Flow. How it works – the functional specification, the transformations – for Enterprises, the Process (or Function) Models (Column 2).

Network/WHERE: This column is concerned with the geographical distribution of the enterprise’s activities. This ranges from a simple a listing of the places where the enterprise does business and how they communicate with each other to the specifications of the particular computers, protocols, and communications facilities at each location. where the entity operates—- System Location. Where the components are located relative to one another – the geometry, the connectivity – for Enterprises, the Logistics (or Network) Models (Column 3).

People/WHO: The fourth column describes who is involved in the business and in the introduction of new technology. who operates the entity—- People and Departments Involved. Who does what work – the manuals, the operating instructions – for Enterprises, the People (or, Work Flow) Models (Column 4).

Time/WHEN: The fifth column describes the effects of time on the enterprise. It is difficult to describe or address this column in isolation from the others, especially column two. when entity operations occur—- Duration of the Business Process. When do things happen relative to one another – the life cycles, the timing diagrams – for Enterprises, the Time (or, Dynamics) Models (Column 5).

Motivation/WHY: As originally described, this column translates business goals and strategies into specific ends and means. why the entity operates—- Motivation Of The Enterprise via Objectives and Strategies.

In a nutshell, per John Zachman, the columns can be inter-related as:

“Some THINGS transformed by

Some PROCESSES in

Some LOCATIONS by

Some PEOPLE at

Some TIME for

Some REASONS”

The rows of Zachman Framework are structured as follows:

Strategic Planner:

System Owner:

System Designer:

System Developer:

Sub-Contractor:

System Itself:

Rules of Zachman Framework

The following rules apply to the Zachman Framework:

RULE 1: Do Not Add Rows or Columns to the Framework: By doing so, the framework would introduce redundancies or discontinuities, thus in true sense, it would de-normalize the classification scheme. In fact, we have studied in past that the Framework- with no modifications in it, classifies all of the primitive descriptive representations (the total knowledgebase) as far it is used for describing an object, any object.

RULE 2: Each Column Has a Simple Generic Model: For the framework, any column within its analytical courage or target is descriptive of a single, independent variable, here, it’s the Enterprise. In short, the variable (abstraction) in any column, it represents is as related to itself; thus the basic generic model of any one Column is very simple.

RULE 3: Each Cell Model Specializes Its Column’s Generic Model: The specific model for any given Cell will have to be customized to the constraints, the semantics, the vocabulary, the terms and facts of the Row’s perspective. Furthermore, considering that the Cell description forms the baseline for managing change, the (meta) model will have to express all of the concepts affected by changes to that Cell model. Therefore, the specific (meta) model for a given Cell will start with the generic, columnar model, be adjusted it for the Row’s semantic constraints and then it might have to be extended to accommodate all of the relevant concepts for expressing the constraints of the Cell’s Row Perspective as well as for managing change to the Cell model, itself.

RULE 3 Corollary (a): Level of Detail Is a Function of a Cell, Not a Column: Because transformation is taking place from Cell to Cell through application of a different set of constraints, and not simply addition of detail. Therefore, what is making a lower Row Cell different from a higher Row Cell in the same Column is NOT the level of detail. The Cells in different Rows of the same Column are different because they are actually models of different things. Level of detail does not necessarily increase from Cell to Cell down a Column. Level of detail increases within a Cell.

RULE 4: No Meta Concept Can Be Classified Into More than One Cell: The Framework is normalized. Also, we know that each of the Rows is unique and each of the Columns is unique. Therefore, each of the Cells is unique. There is no redundancy. This is the one fundamental factor that makes the Framework a good analytical tool. The logic of the Framework is never going to change. Although the instantiation of the models of the Framework (the CONTENTS of the models) may change as per the future requirement. The Framework is not going to change.

RULE 5: Do not Create Diagonal Relationships Between Cells: This will just add confusion and make the analysis complex, as there can be a large number of diagonal relationships.

RULE 6: Do Not Change the Names of the Rows or Columns: Zachman says, “The most critical, reason not to change the name of the Rows and Columns. If you happen to change not only the name but the meaning of the Row or Column, now you have changed the basic logic structure of the Framework. It would no longer be the (quote) Zachman Framework. For example, if you change the meaning of one of the primitive interrogatives (What, How, Where, Who, When, Why), you no longer have the complete set nor do you have a normalized set. You have de-normalized the Framework and at the same time made it less than complete. It would no longer be comprehensive.”

RULE 7: The Logic is Generic, Recursive: The logic of the Framework is generic. As discussed above, the classification scheme of both axes was established quite independently of their application in the Framework. I learned about the Framework classification logic by empirically observing physical objects like airplanes, buildings, battleships, locomotives, computers, etc. Therefore, clearly, the Framework logic can be used to classify descriptive representations of physical objects, any physical objects. The Framework is generic. It can be used to classify the descriptive representations of anything and therefore to analyze anything relative to its architectural composition. It is recursive. It can be used to analyze the architectural composition of itself. The Framework is inert. It doesn’t know what it is being used to analyze. Only the analyst knows the analytical target and establishes the boundaries of the analysis. The analytical boundaries selected for analysis have far-reaching implications and these issues are discussed in subsequent sections of this work.

Row details of Zachman Framework [] 

Row I: What – Technology Specification

Framework Definition:

Technology constrained, or physical representation of the “Things of the Enterprise

Attributes:

Use of Model – How to physically arrange the Things

Modeling techniques

Content Owners

DB Admins (Programmer)

Definition Owners

Exec. VP of Change Management (CIO)

Custodian

Exec. VP of Change Management (CIO)

Primary Users

DB Admins, Ex. VP of change mgmt, Application Developers

Development Consultant

DB Admin

Examples:

Material Storage Facilities

Warehouse storage

Document storage systems

Check sorters (QA)

Shredders

(Physical Security)

Automated data surrogate handling equipment

Computers (Servers/Workstations)

DB/Web/File Servers

AD/LDAP Servers (Control Access)

Disk/Tape storage devices (Data redundancy)

VTL/SAN/NAS solutions

DVD/CD/BD/HD

Database

Relational (Integrity)

Hierarchical (Classification)

Flat files

Network

Hardware

Networking (Connectivity)

Encryption (Confidentiality)

Software

Manual data surrogate handling equipment

Scanners

RFID Card scanners

Document scanners

Biometric scanners

Handwriting tools

Papers

Files

Cabinets

Copiers/Printers

Recommended Technologies:

Database Management System (DBMS)

DB Server – MySQL (Open Source)

Relational Database Schema (Integrity)

Mirrored Data Servers (Data availability)

W3/XML standards for data exchange

QA/Compatibility

Virtual Machines

VMWare/VirtualBox/XEN

Storage management – NetApp/EMC

NAS/SAN solutions (Data Redundancy)

Data encryption (Data Security/Integrity)

AES/Blowfish/TLS/RSA

Link to Link encryption

Certificate Management Services – PKI

Logistic Management Applications

Enterprise Transportation Software (TMW Sys)

3PL Warehouse Manager (3PL Central)

Roadnet Transportation Suite (UPS Logistics)

QoS

ATM networks

Data Audit Model (Oxford Case Study) [] 

* Usage of standard audit forms in step 3

Physical Security

Provision of security personnel.

Closed circuit television monitoring

Creating physical barricades/fences

Using combinatorial biometric security

Row II: How – Process Specification

Framework Definition:

This cell addresses the disaster recovery plans of the organization. The restoration activities include identifying the internal and external resources to handle damaged equipment and media in order to minimize the loss.

Attributes

Use of Model

Defining the physical sequence of execution of the system components

Modeling techniques – Dynamic models, no standard yet

Content Owners

Systems Analyst

Definition Owners

Exec. VP of Change Management (CIO)

Custodian

Exec. VP of Change Management (CIO)

Primary Users

Systems Analyst, Systems Engineer, EVP Change Management

Development Consultant

Systems Analyst

Note: For Automated System

Here, data surrogate implementation, the Row 4 Model would not likely be considered a model, but a design, as you likely would no longer be able to see the Enterprise in the representation.

Recommended Processes:

Security Process (Have to Change this slide)

IDS

Encryption

Authentication

Authorization

Confidentiality

Access Control

Disaster Recovery Process

Status of physical infrastructure

Inventory and functional status of the most important equipment

Type of damage to equipment

Items to be replaced

Asset management Insurance policy

A physical inventory of equipment is performed at least once every two years at appropriately scheduled times.

Routine checkup and up gradation of all Security appliances of company including those of any software as and when required.

Documentation of all Implemented Processes:

For backup

For referral – as and when needed for implementation or for checkup.

. Few Other Major Processes:

Archival Process

Marketing Process

Hiring/ Recruiting Process

training

recruitment

processing of salaries

Customer Support Process

acceptance of the order

issue of invoices,

Complaint Registration

Management Process (e.g.: drawing up of the budget)

Product Manufacturing Process

Supply of Raw Materials

Supply of Hardware/ Software

Power Supply

Transportation Process

Row III: Where – Network Specification

Framework Definition:

Physical depiction of the technology environment for the Enterprise showing the actual hardware and systems software at the nodes and the lines. And their “systems” software including operations systems and middleware

Attributes:

Use of Model

Making hardware and systems software acquisition decisions

Performance

Maintenance

Modeling techniques – Physical connectivity

Content Owners

Technology Architect

Definition Owners

Exec. VP of Change Management (CIO)

Custodian

Exec. VP of Change Management (CIO)

Primary Users

Technology Architect, N/W Admin, N/W Architect

Development Consultant

Technology Architect

Recommended Technologies:

Specification of network devices

Network Links (main/failover)

T1/T2

Optical/Satellite

Routers/Switches/Cables/Gateways

N-Port, Layer 2/3

WiFi – 802.11 b/g/n

Switch – Controlled/Uncontrolled

Servers – Web/File/DB/Application

Web: Apache2

File: NetApp

DB: MySQL/ORACLE/MS Server

Application: IBM Websphere, Tomcat, J2EE

Firewalls

Hardware

Software

2 Way/1 Way

Authentication Server

LDAP / MS AD

Data Link Security

Link Encryption

L2 Cisco TrustSec FC Link Encryption

L1 Encryptors

Wireless (802.11) Encryption – AES/WPA

End-to-end Encryption

VPN

SSH

TLS

Voice Link Security

Intrusion Detection System

SNORT

OSSEC HIDS

Operating Systems

Windows, Linux, UNIX, Mac Os X

Row IV: Who – Organization Specification

Framework Definition:

This is the physical expression of work flow of the Enterprise including the specific individual and their ergonomic requirement and the presentation format of the work product.

Attributes

Use of Model for designing the screen and report format and technology.

Modeling techniques

Content Owners

User Subject Matter Expert

Definition Owners

Exec. VP of Change Management (CIO)

Custodian

Exec. VP of Change Management (CIO)

Primary Users

System Analyst, System Engineer, Programmer, Ex. VP of change mgmt

Development Consultant

System Analyst

Specification of Access Privileges:

Physical Access

Sensors

Alarms

Cameras

IDs

Electronic Access

Firewall/ Routers

Access-lists

Defining Security Level

IDs- Smart / Access Cards

Changing passwords on regular basis

Preparation of Work Flow Model:

QA Department

Security Department

IT Security Department

Software Engineers/ Programmers

System Engineers

Note: Work flow can be designed as per the requirement, availability and the output result needed.

Client Interface Requirements

Customer Support and Satisfaction

Surveys

Advertising

Decide no. of hours for Call Center operation

Roaming user support

Metrics

Performance

Survey

Bonuses

Row V: When – Time Specification

Framework Definition:

This is the physical expression of system events and physical processing cycles, expressed as control structure, passing “control” from one to another processing module.

Attributes:

Use of Model

This model is used for defining the physical sequence of execution of the system Components.

Modeling techniques – These models are dynamics models and although there are several possible notations, as an industry, we haven’t had sufficient experience to settle in on the most appropriate style or most expressive or rigorous model.

Content Owners

Systems Analyst (or, Dynamics Analyst)

Definition Owners

Exec. VP of Change Management (CIO)

Custodian

Exec. VP of Change Management (CIO)

Primary Users

System Analyst or Dynamics Engineer

Development Consultant

System Analyst or Dynamics Engineer

Time/When – Mostly Applicable to White Collar System

Specification Of Triggers

Product Life Cycle

Corporate Calendar – MS Project

Sales & Marketing

Corporate Calendar

Strategic meetings

Demand Cycle

Sales, market analysis reports – MS Graph, iXpress Neilsen

Timely backups

Corporate policies – Storage devices ƒ  NetApp, EMC

Information lifecycle management

SAP

Budget

Corporate Calendar

Market Analysis

Row VI: Why – Constraints

Framework Definition:

This cell particularly deals with the constraints implied due to technological limitations and with the availability of resources and product construction.

Attributes

Use of Model for Constraints

Content Owners

Business Rule Designer

Definition Owners

Exec. VP of Change Management (CIO)

Custodian

Exec. VP of Change Management (CIO)

Primary Users

Business Rule Designer, Business Rule Engineer, Ex. VP of change mgmt

Development Consultant

Business Rule Designer

Few Major Constraints- as per builders prospective:

EA Business Constrained Rules (Compliance Standards)

Availability of Hardware and Software

Budget

Construction

Technological

Government Polocies

Legal Changes

Environment

Strikes

Other Resources

Conclusion

The Information Age demands knowledge to complexity and respond to the dynamically changing marketplace. Reusability, interoperability, flexibility, adaptability, reduced time-to-market are the by-words of today’s “agile” enterprise”, John Zachman.

The EA framework can help attain this goal in systematic, timely and less painful manner

Appendix 1

Benefits of EA: Improves interoperability and integration

In the example above, department A from a large company is trying to gather some census data, which either can be created from scratch or can be borrowed from someone else. Incidentally department B from the same company has the census data, but they call it by some other names. Enterprise Architecture can link these two departments well enough such that they can share each others data and thus save a lot if money in this process.

John Zachman – Photo