Published in TDAN.com October 2001
Introduction
More and more, companies are recognizing that they need to integrate and pull together their data, information and knowledge and the various application systems, be they home-grown or purchased.
Enterprise Data and Application Integration has become a serious endeavor, instead of something discussed at the conferences. People are learning either through guidance from knowledgeable persons
or by hard earned experience that an Enterprise Architecture is a prerequisite for Enterprise Integration success. This paper discusses a methodology for developing an Enterprise Architecture (EA)
and the deliverables to be expected from such an activity. A Best Practices Assessment [1] may often be performed in conjunction with an Enterprise Architecture project.
As discussed in an earlier paper [2], Enterprise Architecture (EA) has been defined as the underlying framework, which defines and describes the platform(s) required by the enterprise to attain its
objectives and achieve its business vision.
The four architectural views were discussed:
- Data Architecture
- Process Architecture
- Application Architecture
- Technology Architecture
It was suggested how EA can be justified to Senior Business Management, to Information Technology Project Managers, and to System Developers.
Enterprise Architectural deliverables may be valuable in and of themselves but that they are most important as input to:
- Business Process Improvement projects
- Application Portfolio Analysis projects
- Technology Architecture Evaluation projects
- Major Information Technology Development projects.
Enterprise Architecture is an amalgam of engineering art and engineering science. Engineering has been defined as the design and manufacture of complex products. It implies that the architectural
engineer follows a methodology that generates a set of predefined deliverables. In this article, enterprise methodology steps and their resulting deliverables are defined.
The Architecture Development Methodology
An Enterprise Architecture Development project comprises the following activities:
- Develop Architecture Development project objectives and scope
- Develop one or more of:
-
- Information Architecture
- Process Architecture
- Application Architecture
- Technology Architecture
- Document Deliverables both graphically and in metadata
- Present Architecture to various communities.
Develop EA Project Infrastructure
Like any other project, an Enterprise Architecture project begins with organization of the EA project team that includes one or more Enterprise Architects, Enterprise Business Subject Matter
Experts, and Enterprise Technology Subject Matter Experts. The team develops the following project infrastructure deliverables:
- Project Plan
- Project Status Approach
- Issue Tracking Mechanism
- Change Management Mechanism
Develop EA Development Project Objectives and Scope
Fred Brooks classic article begins with following profound observation: “More software projects have gone awry for lack of calendar time than for all other causes combined.[3] Therefore it is
important to get a project off to a running start.”
John Zachman has stated that the beginning phase of any project is Scoping/Objectives.[5] We have found that, during the first week of an EA project, a Scoping Workshop is in order. In a Scoping
Workshop, a variety of business subject matter experts and Information Technology (IT) participants [6] meet, preferably out of the office, to develop a project Mission Statement. The scoping
workshop participants then develop a Context Diagram [7] that shows the suppliers of and recipients of information from the enterprise.
Next the scoping session identifies major Business Objects, Major Business Events, Major Business Processes, Major Business Rules, and Major Business Objectives. The participants then review and
set study priorities on major business events and processes. Typically, the events and processes will be designated as being a Primary Focus item, a Secondary Focus Item or Out of Scope. For
primary and secondary focus events and processes, stakeholders, and subject matter experts are identified.
Depending on the nature of the requirements, either Zachman Level 1 or 2 Deliverables may be developed.
Develop Information Architecture[8]
In developing an Information Architecture, the EA Information Architecture team will hold facilitated sessions and interviews for developing high level Use Cases, Business Rules, and information
needed to develop a Conceptual Data Model. The EA Information Architecture team will develop Information Architecture Policy and Practices, including an Information Vision, Information Best
Practices, Data Naming Conventions, Information Standards and Guidelines, and Information Design Review Guidelines. The EA Information Architecture team will develop Information Architecture
Diagrams and Cross Reference Matrices.
Information Architecture Deliverables
Information Vision Statement
“A vision statement asserts a common vision of the desired nature of enterprise domain.” [9] It is both a qualitative and quantitative statement that an enterprise can use repeatedly to
measure adherence to objectives, as a yardstick for measuring progress, and as a prod to keep improvement activities going. [10] The Information Vision Statement will state how the Information
Technology functions will avoid developing islands of databases and will develop a common, shared, distributed, accurate, and consistent data resource.
Information Best Practices
Consists of the architectural principles, strategies, and policies required to develop and implement data models, databases, and the infrastructure that support them.
Data Naming Conventions
Standards for assigning names to data constructs. It usually includes standard abbreviations and acronyms.
Information Standards and Guidelines
Standards and guidelines concerning procedures and methods of managing data, information and knowledge.
Information Design Review Guidelines
Guidelines for performing and participating in design reviews and modeling walkthroughs.
Business (Conceptual) Data Model
A Conceptual level Entity Relationship Diagram. The Business Data Model is different from the more detailed Information Systems Data Model in that the Business Data Model:
- Contains conceptual (not necessarily normalized) data entities
- May contain many to many data relationships
- May not contain information about the optionality of data relationships
- Should contain all supertype data entities but not necessarily all subtype data entities
- May not contain any data elements. Any included will be only those data elements that are easy to find and define, and are particularly interesting and will raise data issues and ambiguities,
early.
A UML Class Diagram can be used for this purpose.
Information System (Logical) Data Model
These may not be developed within an Enterprise Architecture project but should be stored and maintained in the Enterprise Architecture Knowledgebase.
Database Design Model
A graphical representation of tables and their logical relationship to each other. These may not be developed within an Enterprise Architecture project but should be stored and maintained in the
Enterprise Architecture Knowledgebase.
Data Distribution Diagram
A graphical representation of distributed data server nodes and the data required therein. These may or may not be developed within an Enterprise Architecture project but should be stored and
maintained in the Enterprise Architecture Knowledgebase.
Operational Data Sourcing Diagram
A graphical representation of legacy databases that are the sources of new or planned operational databases. These may or may not be developed within an Enterprise Architecture project but should
be stored and maintained in the Enterprise Architecture Knowledgebase.
Informational Data Sourcing Diagram
A graphical representation of legacy databases that are the sources of new or planned informational databases [11]. These may or may not be developed within an Enterprise Architecture project but
should be stored and maintained in the Enterprise Architecture Knowledgebase.
Major Business Object/Data Entity Matrix
A table structure that shows one or more data entity derived from a business object.
Major Business Objects/Major Business Process Matrix
A table structure that shows one or more business process related to a business object.
Data Entity/Major Business Process Matrix
A table structure that shows one or more business process related to a data entity.
Develop Process (Business) Architecture
The EA Process Architecture team will take the results of the Information Architecture analysis and use it as a starting point to derive Business Process Models and to define Business Process
Policy and Practices.
Process (Business) Architecture Deliverables
Business Vision Statement
The Business Vision Statement describes how business is to be done.
Business Architecture Best Practices
Consists of the architectural principles, strategies, and policies required to develop and implement business function and event/function models, and the infrastructure that support them.
Business Architecture Naming Conventions –
Standards for assigning names to business modeling constructs. Standard abbreviations and acronyms as part of Data Naming will be used here also.
Business Architecture Standards and Guidelines
Standards and guidelines concerning Business procedures and methods.
Business Architecture Design Review Guidelines
Guidelines for performing and participating in design reviews and modeling walkthroughs.
High Level (Conceptual) Use Case Diagram
A Use Case Diagram that shows major Actors and their relationship to one or more major Business Process. It may be the context diagram that is developed as part of the Scoping Workshop.
Business (Conceptual) Level Event/Process Model
A conceptual level diagram showing Main Events and the Business Processes that are triggered by them; processes that trigger Events or other Processes with the various functional areas of the
enterprise. It may be a UML Use Case and related Activity Diagrams using swim lanes.
Business (Conceptual) Level Event/Process Dependency Diagram
A conceptual level model diagram that shows which events or business processes are dependent upon the occurrence of an event or the beginning or end of a business process. It may be a UML Activity
and Collaboration Diagrams.
Location Connection Diagram
A conceptual level diagram that the nature of information connections between an enterprise’s various location types. It may be represented as a UML Deployment Diagram but is usually best
represented in a more graphical form.
Main Events/Major Business Process Matrix
A tabular representation that shows the relationship of main events to business processes.
Key Actor Roles/Major Business Process Matrix
A tabular representation that shows the relationship of actors to business processes.
Key Actor Roles/Use Case Matrix
A tabular representation that shows the relationship of actors to use cases.
Major Location Types/Major Business Process Matrix
A tabular representation that shows the relationship of location types to business processes.
Organization/Business Process
A tabular representation that shows the relationship of organizational units to business processes.
Develop Application Architecture
The EA Application Architecture team will take the results of the Information and Process Architecture analysis and use it as a starting point to develop cross references of existing and planned
applications to data and process architecture objects. (Often called an Application Portfolio.)
Business Processes will be classified as to whether they are operational, or informational, or both. Business Processes will be related to Location or Site types that define the nature of the work
being done at a given location. These relationships will aid in the development of an application distribution strategy.
The EA Application Architecture team will define Application Architecture Policy and Practices.
Application Architecture Deliverables
Application Architecture Vision
The Application Architecture Vision Statement describes how information system applications support the work activities of the business processes.
Application Architecture Best Practices
Consists of the architectural principles, strategies, and policies required to develop and implement information system applications and the infrastructure that support them.
Application Architecture Naming Conventions
Standards for assigning names to application modeling constructs. Standard abbreviations and acronyms used as part of Data Naming will be used here also.
Application Architecture Standards and Guidelines
Standards and guidelines concerning application procedures and methods.
Application Architecture Design Review Guidelines
Guidelines for performing and participating in application design reviews and modeling walkthroughs.
Location Connection Diagram
Same as discussed above.
Distributed Systems Diagram
A diagram that shows where the various systems are run. These may or may not be developed within an Enterprise Architecture project but should be stored and maintained in the Enterprise
Architecture Knowledgebase. UML Component and Deployment Diagrams may be used.
Mapping of Applications to Servers
A diagram similar to those above that is used in a Client/Server environment. These may or may not be developed within an Enterprise Architecture project but should be stored and maintained in the
Enterprise Architecture Knowledgebase.
Middleware Design Diagrams
Diagrams that represent the architectural levels and components that constitute the middleware solution requirements.
Application Systems / Main Events Matrix
A tabular representation of Application Systems to related Main Events.
Application Systems / Business Processes Matrix
A tabular representation of Application Systems to related Business Processes.
Application Systems / Servers Matrix
A tabular representation of Application Systems to the various Servers on which they run.
Servers/Location Types Matrix
A tabular representation of Servers to Location Types where they are located.
Packaged Application System Decision Matrix
A decision matrix that is used to compare weighted scores of various application packages against evaluation criteria based upon architecture models, principles and best practices.
Develop Technology Architecture
The EA Application Architecture team will take the results of the Information, Process, and Application Architecture analysis and use them as requirements to develop the Technology Architecture.
The Technology Architecture involves client hardware, client software, server(s) hardware, server(s) software, and network hardware and software.
The EA Technology Architecture team will define Technology Architecture Policy and Practices.
Technology Architecture Deliverables
Technology Architecture Vision
The Technology Architecture Vision Statement describes how to provide interoperable technology platforms that meet the needs of the various user roles (Actors) at identified work locations.
Technology Architecture Best Practices
Consists of the architectural principles, strategies, and policies to provide interoperable technology platforms that meet the needs of the various actors at identified work locations and the
infrastructure that support them.
Technology Architecture Naming Conventions
Standards for assigning names to technology architecture modeling constructs. Standard abbreviations and acronyms used as part of Data Naming will be used here also.
Technology Architecture Standards and Guidelines
Standards and guidelines concerning technology architecture procedures and methods.
Technology Architecture Design Review Guidelines
Guidelines for performing and participating in technology architecture design reviews and modeling walkthroughs.
Client Location Map/Diagram
A diagram that shows the location of various systems’ clients. These may or may not be developed within an Enterprise Architecture project but should be stored and maintained in the
Enterprise Architecture Knowledgebase. A UML Deployment Diagram may be used.
Server Location Map/Diagram
A diagram that shows the location of various systems’ servers. These may or may not be developed within an Enterprise Architecture project but should be stored and maintained in the
Enterprise Architecture Knowledgebase. A UML Deployment Diagram may be used.
Network Topology Diagram
A diagram that shows the network connections of the various enterprise nodes. These may or may not be developed within an Enterprise Architecture project but should be stored and maintained in the
Enterprise Architecture Knowledgebase. A UML Deployment Diagram may be used.
Object Volume Matrix
A spreadsheet showing the expected and maximum volumes of the various business objects used to estimate storage and network traffic requirements.
System Technology Decision Matrix
A decision matrix that is used to compare weighted scores of various technology architecture packages against evaluation criteria based upon architecture models, principles and best practices.
Document Deliverables in Metadata
Throughout the Enterprise Architecture Development project, the EA team will enter EA deliverable results into an EA Repository. The EA Repository should utilize an Enterprise Architecture Metadata
Model, similar to this.
EA Metadata Model Definitions
Application – Any of a class of programmed module that causes equipment to perform some useful function. There may be (sub)applications within a given application.
Business Motivation – A reason that a business function is significant to the enterprise. There may be (sub)motivations within a given motivation. For instance, there may be
objectives within a given goal.
Business Party – Any Person or Organization that is of interest to the enterprise
Business Rule – The criteria by which business decisions are made.
Change Request – A request for Initiative/Project Change
Data Attribute – A fact describing a Data Entity.
Data Entity – A person, place, thing, concept, or event of significance to the enterprise.
Data Relationship – An association of one Data Entity to another.
Event – A business happening at a point in time of significance to the enterprise.
Function – A business activity performed within the enterprise domain that furthers a business purpose. There may be (sub)functions within a given function.
Issue – A point of importance needed to be resolved.
Locator – A mechanism for locating a business party or a facility. There may be geographic-oriented locators (for example, street address, or a mailing address) and electronic
locators (for instance, a telephone number or a URL).
Organization – A type of Business Party that represents the combination of facilities, personnel, property, policies, patterns and capabilities that result in a functioning
enterprise, whether private or public, revenue-seeking or non-profit.
Person – Any human being that is of interest to the enterprise.
Platform – A hardware/software mechanism enabling computer processing
Initiative/Project – A plan for the completion of a group of tasks to achieve a specified goal over a limited period of time.
Responsibility – The nature of work performed with regards to enterprise functions.
Site – A place where the enterprise may operate.
Site Type – The nature of the work performed within a site.
Subject Area – A grouping of Data Entities with a business affinity
Architecture Prototyping
Many Enterprise Architecture projects utilize prototyping to evaluate various aspects of the potential architectural solution.
Architecture Prototype Deliverables
Proof of Concept Prototype
Within an Enterprise Architecture development project, a proof of concept prototype may be developed to test the feasibility of an Information, Business, Application, or Technology Architectural
concept.
Packaged Product Evaluation Prototype
With an evaluation project, the vendor may be asked to produce a prototype that shows that the enterprise’s requirements will be well satisfied by the package being evaluated.
Present Architecture to Various Communities
Enterprise Architecture can support Senior Management, IT Project Management, and IT Developers. Differing architecture presentations should be developed for each group with a focus upon things
that are of importance to each group. An architecture report analyzing the modeling findings and recommending short term, medium term, and long term architecture improvements should be developed.
The various architectural policies and best practices, diagrams and matrices, and their supporting metadata should be entered into a Enterprise Architecture repository which many leading companies
are making available on their intranet web site. Enterprise and business unit architects, and technology, and business subject matter experts are all potential users of the web site. At both a
large telecommunications company and at a large pharmaceutical company, such a web site has been developed, along with a marketing and communications plan to draw users to the site.
The Enterprise Architecture Presentation/Report will cover the following areas:
Executive Summary
A 2 page or less summary of the findings and recommendations of the architecture project.
Project Objective
The objective of the Enterprise Architecture project.
Project Scope
The scope of the Enterprise Architecture project.
Proof of Concept Prototype Results
The results of proof of concept prototyping.
Packaged Product Evaluation Prototype Results
The results of packaged product evaluation prototyping.
Architecture Development Results
Discusses in more detail the project activities and the project team’s findings.
Analysis of various deliverables
Explains the architectural information embodied in the various deliverables
Business Process Improvement Recommendations
In every architecture project, business process improvement opportunities will be found. Recommendations concerning these potential improvements will be made. Some recommendations will have
short-term impact. Some will have intermediate impact and some will have long term impact.
References
[1] A Best Practices Assessment – Tom Finneran, CIBER, Inc http://www.tdan.com/i012ht04.htm
[2]Enterprise Architecture: What And Why Tom Finneran – CIBER, Inc. http://www.tdan.com/i007ht03.htm
[3] F.B. Brooks, Jr., The Mythical Man-Month, Addison-Wesley Publishing Company, (1975), p. 14.
[4] Jean de La Fontaine, 1621-1695, Fables as quoted in L. D Eigen and J. P Siegel, The Manager’s Book of Quotations AMACOM, 1991.
[5] J.A. Zachman, “A Framework for Information Systems Architecture” Handbook of Data Management Auerbach Publications, Warren Gorham Lamont, Boston – 1993, pp3-22
[6] A mixure of user executives, managers, and workers along with knowledgable IT persons works best, but a less diverse group will be successful as long as the participants understand the
business.
[7] A UML Use Case Diagram may be used for this purpose.
[8] Depending on the accepted parlance of the enterprise, this may also be called Data Architecture.
[9] Tapscott & Caston, Paradigm Shift, McGraw Hill, 1993, p 187.
[10] Hammer & Champy, Reengineering the Corporation, Harper Business, 1993, p 154.
[11] These may be data marts or data warehouses.
