Enterprise Architecture Document
[Client Name]
March 3, 2016
NOTE: This document is intended to serve as a template and set of guidelines to be used in constructing
an Enterprise Architecture Document. It is a working draft and subject to change, based upon review by
the GEN 3 Partners CTO and System Architecture Team.
It is not intended that users of the document follow the rigid format contained herein. While the document
is a template, along with suggested guidelines for content, it is up to the user to decide which sections are
most appropriate for the need.
Revision 0.2
[ Template & Guidelines ]
GEN 3 Partners Proprietary & Confidential
REVISION HISTORY
Version
0.1
0.2
Date
02-07-01
02-11-01
Authors
Allen Berglund
Allen Berglund
Description of Revision
First Draft
1. Incorporated Les McMonagle’s review comments
2. Added section on B2B Application Integration
3. Expanded section on High Availability
4. Major reorganization of sections to improve flow
COPYRIGHT
Copyright ©2001 GEN 3 Partners. Affixed is the foregoing notice to protect GEN 3 Partners in case of
inadvertent publication. This document is unpublished.
PROPRIETARY NOTICE
This document contains information that is Proprietary to GEN 3 Partners, Inc. and may not be disclosed
to any person who is not a GEN 3 Partners employee without the prior written consent of GEN 3 Partners.
In consideration of receipt of this document, the recipient agrees to treat this information as confidential
and not reproduce or otherwise disclose this information to any persons not specifically authorized to
receive it. GEN 3 Partners reserves the right to request that all copies of this document be returned by the
recipient.
GEN 3 Partners Proprietary & Confidential
WORKING DRAFT – Enterprise Architecture Document Template
Author’s Comment & Recommendation
It is recommended that all GEN 3 Partners System Architects upgrade their current version of
Visio 2000 Standard to Visio 2000 Professional. The standard version has little or no support for
business process modeling, UML, database modeling, broader networking diagramming, project
scheduling, PERT charts, etc. Of particular note, the professional version modeling support
includes the following:
Booch OOD
Shlaer-Mellor
COM and OLE
SSADM
Connectors
UML Activity Diagram
Gane-Sarson
UML Collaboration Diagram
Jackson
UML Component Diagram
Jacobson Use Cases
UML Deployment Diagram
Language Level Shapes
UML Sequence Diagram
Memory Objects
UML Statechart Diagram
Nassi-Schneiderman
UML Static Structure (Class Diagramming)
Office User Interface
UML Use Case Diagram
ROOM
Windows User Interface Diagram
Rumbaugh OMT
Yourdon and Coad
GEN 3 Partners Proprietary & Confidential
Table of Contents
1.
INTRODUCTION ................................................................................................................................... 7
1.1. PURPOSE ........................................................................................................................................ 7
1.2. SCOPE ............................................................................................................................................ 7
1.3. DEFINITIONS, ACRONYMS, AND ABBREVIATIONS .......................................................................... 7
1.4. REFERENCES ................................................................................................................................. 7
1.5. OVERVIEW ...................................................................................................................................... 7
2.
CURRENT ARCHITECTURAL REPRESENTATION........................................................................... 7
2.1. LOGICAL ARCHITECTURE ............................................................................................................... 7
2.2. PHYSICAL ARCHITECTURE ............................................................................................................. 8
3.
FUTURE ARCHITECTURAL REPRESENTATION............................................................................... 8
3.1. PLANNED INFRASTRUCTURE.......................................................................................................... 8
3.2. REFERENCE ARCHITECTURE ......................................................................................................... 8
3.3. ARCHITECTURAL GOALS AND CONSTRAINTS ................................................................................ 8
3.4. LOGICAL VIEW ................................................................................................................................ 8
3.5. STANDARDS-COMPLIANCE-REQUIREMENTS OVERVIEW .............................................................. 9
3.5.1.
Application Standards Compliance And Requirements ........................................................... 9
3.5.2.
System Standards Compliance Requirements ........................................................................ 9
3.5.3.
Security Model Standards Compliance Requirements ............................................................ 9
3.6. PERFORMANCE REQUIREMENTS ................................................................................................... 9
3.6.1.
Environmental Requirements ................................................................................................ 10
3.6.2.
Legacy Code Wrapping Requirements.................................................................................. 10
3.7. USE CASE VIEW ............................................................................................................................ 10
3.8. PROCESS VIEW ............................................................................................................................ 10
3.9. USE CASE REALIZATIONS ............................................................................................................ 10
3.10.
INTERFACES.............................................................................................................................. 10
3.10.1. User Interfaces ...................................................................................................................... 10
3.10.2. Hardware Interfaces .............................................................................................................. 11
3.10.3. Software Interfaces ................................................................................................................ 11
3.10.4. Communications Interfaces ................................................................................................... 11
3.11.
FRAMEWORKS .......................................................................................................................... 11
3.11.1. Java 2 Enterprise Edition – Object Framework ..................................................................... 11
3.11.2. RosettaNet – Service Framework.......................................................................................... 11
3.11.3. BizTalk – Service Framework ................................................................................................ 11
3.11.4. SAP & PeopleSoft – Procedural Frameworks ....................................................................... 12
3.12.
MIDDLEWARE & MESSAGING.................................................................................................... 12
3.12.1. Middleware Models ................................................................................................................ 12
3.12.2. Types of Middleware ............................................................................................................. 13
3.13.
INFORMATION ARCHITECTURE VIEW ....................................................................................... 13
3.13.1. Data Model ............................................................................................................................ 13
3.13.2. Data Interchange ................................................................................................................... 13
3.13.3. Persistent Storage Strategy ................................................................................................... 13
3.14.
EXTERNAL FACING SYSTEMS ................................................................................................... 14
4.
SYSTEMS INTEGRATION STRATEGY & GOALS ............................................................................ 14
4.1. TYPES OF B2B APPLICATION INTEGRATION ................................................................................ 16
4.1.1.
Data-Oriented Integration ...................................................................................................... 16
4.1.2.
Application Interface Oriented-Integration ............................................................................. 16
4.1.3.
Method-Oriented Integration .................................................................................................. 17
4.1.4.
Portal-Oriented Integration .................................................................................................... 17
GEN 3 Partners Proprietary & Confidential
WORKING DRAFT – Enterprise Architecture Document Template
4.1.5.
Process-Oriented Integration................................................................................................. 17
5.
DEPLOYMENT VIEW .......................................................................................................................... 17
6.
IMPLEMENTATION VIEW .................................................................................................................. 17
6.1. SUBSYSTEM LAYERS .................................................................................................................... 17
6.2. PURCHASED COMPONENTS..................................................................................................... 17
7.
SIZING AND PERFORMANCE ........................................................................................................... 18
8.
SYSTEM RESILIENCY & HIGH AVAILABILITY ................................................................................ 18
8.1. MEASURING AVAILABILITY ........................................................................................................... 19
8.2. RELIABILITY .................................................................................................................................. 19
8.3. IDENTIFICATION OF FAILURE MODES........................................................................................... 20
9.
QUALITY ............................................................................................................................................. 20
10.
SUPPORTABILITY .......................................................................................................................... 20
DESCRIPTION OF APPENDICIES ............................................................................................................ 21
APPENDIX A – SAMPLE LAYERED ARCHITECTURE VIEW .................................................................. 22
APPENDIX B – SAMPLE FUNCTIONAL SUBSYSTEMS OVERVIEW ..................................................... 23
APPENDIX C – SAMPLE LOGICAL COMPONENT OVERVIEW ............................................................. 24
APPENDIX D – SAMPLE DETAIL COMPONENT OVERVIEW ................................................................. 25
APPENDIX E – SAMPLE PHYSICAL ARCHITECTURE OVERVIEW ....................................................... 26
03/03/16
GEN 3 Partners Proprietary & Confidential
WORKING DRAFT – Enterprise Architecture Document Template
1.
INTRODUCTION
CONTENT: The introduction of the Enterprise Architecture Document (EAD) provides an
overview of the entire EAD documentation process. It includes the purpose, scope, definitions,
acronyms, abbreviations, references, and overview of the EAD.
1.1.
Purpose
CONTENT: This subsection provides a comprehensive architectural overview of the system,
using a number of different architectural views to depict different aspects of the system. It is
intended to capture and convey the significant architectural decisions, which have been made
about the system.
1.2.
Scope
CONTENT: This subsection provides a brief description of what the EAD applies to; what is
affected or influenced by this document.
1.3.
Definitions, Acronyms, and Abbreviations
CONTENT: This subsection provides the definitions of all terms, acronyms, and abbreviations
required to properly interpret the EAD. This information may be provided by reference to the
project’s Glossary.
1.4.
References
CONTENT: This subsection provides a complete list of all documents referenced elsewhere in
the EAD Identify each document by title, report number (if applicable), date, and publishing
organization. Specify the sources from which the references can be obtained. This information
may be provided by reference to an appendix or to another document.
1.5.
Overview
CONTENT: This subsection describes what the rest of the EAD contains and explains how the
document is organized.
2.
CURRENT ARCHITECTURAL REPRESENTATION
CONTENT: This section describes what software architecture is for the current system, and how
it is represented.
2.1.
Logical Architecture
CONTENT: This subsection provides a description of current client logical architecture –
diagrams are preferred. See appendix
03/03/16
GEN 3 Partners Proprietary & Confidential
PAGE 7
WORKING DRAFT – Enterprise Architecture Document Template
2.2.
Physical Architecture
CONTENT: This subsection provides a description of current client physical architecture –
diagrams are preferred.
3.
FUTURE ARCHITECTURAL REPRESENTATION
CONTENT: This section describes what the software architecture is for the future system, and
how it is represented. Of the Use-Case, Logical, Process, Deployment, and Implementation
Views, it enumerates the views that are necessary, and for each view, explains what types of
model elements it contains.
3.1.
Planned Infrastructure
CONTENT: This subsection identifies the functionalities of the hardware and software
components, specifies the corresponding service level requirements, and describes the
management and operation of the planned system. The planned infrastructure is usually shared
by many applications that rely on components of the infrastructure and management procedures
(e.g., software distribution, backup, recovery, and capacity planning).
3.2.
Reference Architecture
CONTENT: While the infrastructure describes the characterizes the main components that
support the planned systems business needs, this subsection describes the reference
architecture covers not only the components, but the way those components are structured and
the way they interact with each other. In other words, an infrastructure model provides a static
description of resources and services, whereas the architecture includes the dynamics of the
system.
Diagrams showing the physical architecture as well as the logical architecture are encouraged
and desired.
[The importance of an architecture is emphasized by the following quotation: “If a project has not
achieved a system architecture, including its rationale, the project should not proceed to a fullscale development. Specifying the architecture as a deliverable enables its use throughout the
development and maintenance process.”  B. Boehm, “Engineering Context”, 1995]
3.3.
Architectural Goals and Constraints
CONTENT: This section needs to indicate any design constraints on the system being built.
Design constraints represent design decisions that have been mandated and must be adhered to.
Examples include eCommerce software packages, software languages, software process
requirements, prescribed use of developmental tools, architectural and design constraints,
purchased components, class libraries, etc.
3.4.
Logical View
CONTENT: This section describes the architecturally significant parts of the design model, such
as its decomposition into subsystems and packages; for each significant package, its
decomposition into classes and class utilities. One should introduce architecturally significant
classes and describe their responsibilities, as well as a few very important relationships,
operations, and attributes.
03/03/16
GEN 3 Partners Proprietary & Confidential
PAGE 8
WORKING DRAFT – Enterprise Architecture Document Template
3.5.
Standards-Compliance-Requirements Overview
CONTENT: This subsection describes the overall decomposition of the design model in terms of
its package hierarchy and layers.
3.5.1. Application Standards Compliance And Requirements
CONTENT: CONTENT: This subsection describes by reference any applicable standards and
the specific sections of any such standards that apply to the system being described. For
example, this could include legal, quality and regulatory standards, industry standards for
usability, interoperability, internationalization, operating system compliance, programming
language, middleware, etc.
3.5.2. System Standards Compliance Requirements
CONTENT: Define any system requirements necessary to support the application. These may
include the supported host operating systems and network platforms, configurations, memory,
peripherals, and companion software.
These can include legal and regulatory (FDA, UCC) communications standards (TCP/IP, ISDN),
platform compliance standards (Windows, UNIX, Lunux, and other OS platforms), and quality and
safety standards (ISO, CMM), etc.
3.5.3. Security Model Standards Compliance Requirements
CONTENT: This section covers two essential security models that must be addressed:
1. Enterprise systems security from outside intrusion
2. Network security for data communicated over the Web
3. Trust Model
4. Security Guidelines
5. Data Classification Scheme
Specify firewall implementation with the following: limited IP and Port addresses, limited protocols
allowed (http, https, IP), required user authentication at the firewall level, and abstracted IP Server
address. Outline relevant technologies that address the following security categories

User Authentication/Authorization

Messaging Confidentiality

Data Integrity

Non-Repudiation
Additionally, provide information and requirements for authentication at: front-office application
layer, back-office application layer, operating system, authentication, authorization, and security
transmission, etc.
3.6.
Performance Requirements
CONTENT: Use this subsection to detail performance requirements. Performance issues can
include such items as user load factors, bandwidth or communication capacity, throughput,
accuracy, and reliability or response times under a variety of loading conditions.
03/03/16
GEN 3 Partners Proprietary & Confidential
PAGE 9
WORKING DRAFT – Enterprise Architecture Document Template
3.6.1. Environmental Requirements
CONTENT: This subsection details environmental requirements as needed. For hardware-based
systems, environmental issues include temperature, shock, humidity, radiation, and so on. For
software applications, environmental factors include usage conditions, user environment,
resource availability, maintenance issues, and error handling and recovery.
3.6.2. Legacy Code Wrapping Requirements
CONTENT: This subsection addresses requirements for design techniques whereby existing
(legacy) code (algorithms, function libraries, data structures, database interfaces, etc.) are
wrapped, or encapsulated, inside classes. The goal of this requirement/design is a means of both
insulating the users from the legacy code and improving the nature of the interface and functions
provided by that code.
3.7.
Use Case view
CONTENT: This section lists use cases or scenarios from the use-case model if they represent
some significant, central functionality of the final system, or if they have a large architectural
coverage  they exercise many architectural elements or if they stress or illustrate a specific,
delicate point of the architecture.
3.8.
Process View
CONTENT: This section describes the system's decomposition into lightweight processes (single
threads of control) and heavyweight processes (groupings of lightweight processes). Organize the
section by groups of processes that communicate or interact. Describe the main modes of
communication between processes, such as message passing, interrupts, and rendezvous.
3.9.
Use Case Realizations
CONTENT: This section illustrates how the software actually works by giving a few selected usecase (or scenario) realizations, and explains how the various design model elements contribute to
their functionality.
(Note, the term “realization” is a UML semantic relationship between classifiers, wherein one
classifier specifies a contract that another classifier guarantees to carry out. You encounter
realization relationships between interfaces and the classes or components that realize them, and
between use cases and the collaborations that realize them.)
3.10. Interfaces
CONTENT: This section defines the interfaces that must be supported by the applications. It
should contain adequate specificity, protocols, ports and logical addresses, and so forth, so that
the software can be developed and verified against the interface requirements.
3.10.1.
User Interfaces
CONTENT: This subsection describes the user interfaces that are to be implemented by the
software.
03/03/16
GEN 3 Partners Proprietary & Confidential
PAGE 10
WORKING DRAFT – Enterprise Architecture Document Template
3.10.2.
Hardware Interfaces
CONTENT: This subsection defines any hardware interfaces that are to be supported by the
software, including logical structure, physical addresses, expected behavior, etc.
3.10.3.
Software Interfaces
CONTENT: This subsection describes software interfaces to other components of the software
system. These may be purchased components, components reused from another application or
components being developed for subsystems outside of the scope of this EAD, but with which this
software application must interact.
3.10.4.
Communications Interfaces
CONTENT: This subsection defines any licensing enforcement requirements or other usage
restriction requirements that are to be exhibited by the software.
3.11. Frameworks
CONTENT: This subsection identifies relevant framework technology for the new enterprise.
Typically, framework types include:

Object Frameworks

Service Frameworks

Procedural Frameworks
Object Frameworks: are made up of both abstract and concrete classes. They provide
abstraction services through the inheritance mechanism that most object-oriented languages and
tools provide.
Service Frameworks: in contrast to object frameworks, lack inheritance. In general, service
frameworks are the best fit for most B 2B application integration domains.
Procedural Frameworks: provide a good approach to method-oriented B2B application
integration. They represent a “black box” perspective on frameworks in that they restrict
developers from extending or modifying basic services.
3.11.1.
Java 2 Enterprise Edition – Object Framework
CONTENT: J2EE is an example of a robust object framework. List the business domains and
relevant component elements embedded in the J2EE framework. (J2EE is an object framework.)
3.11.2.
RosettaNet – Service Framework
CONTENT: This subsection discusses RosettaNet from a logical B2B framework perspective.
Even though it is considered more of a standard than a technical framework, for the purpose of
this document we will use the analogy of RosettaNet as a framework. From a technical
perspective, the end deliverable is RosettaNet’s PIP (Partner Integration Process) consisting of
the Business Operational View (BOV), Functional Service View (FSV), and Implementation
Framework View (IFV).
In this subsection, list all of the relevant architectural requirements and integration design points
for elements of RosettaNet, if required. (RosettaNet is a Service Framework.)
3.11.3.
BizTalk – Service Framework
CONTENT: [SERVICE FRAMEWORK] – This subsection discusses Microsoft’s BizTalk
03/03/16
GEN 3 Partners Proprietary & Confidential
PAGE 11
WORKING DRAFT – Enterprise Architecture Document Template
framework as compared to similar standards, such as RosettaNet and ebXML. BizTalk is much
more information oriented and not at all process aware. At its core, BizTalk seeks to solve
several B2B application integration problems, including the following:

Creating a common message format based on XML that many organizations can agree
upon

Accounting for differences in application semantics between applications and companies

Creating a common technology infrastructure that will become the standard B2B
application integration
In this subsection, list all of the relevant architectural requirements and integration design points
for employing elements of BizTalk, if required. (BizTalk is a Service Framework.)
SAP & PeopleSoft – Procedural Frameworks
3.11.4.
CONTENT: [PROCEDURAL FRAMEWORK] – SAP/R3 is a procedural framework most popular
in the ERP space. As with most things, connecting to SAP has an upside and a downside. SAP,
like most other packaged applications, was build as a monolithic solution never intended to
communicate with the outside world. SAP’s challenges are the lack of open interfaces. In this
subsection, discuss how the new architecture will interface with SAP/R3
PeopleSoft is the most open of all ERP procedural frameworks. Unlike SAP, the PeopleSoft
application server is based on open technology – BEA’s Tuexedo. In this subsection, discuss how
the new architecture will interface with PeopleSoft. (SAP and PeopleSoft are Procedural
Frameworks.)
3.12. Middleware & Messaging
CONTENT: This section identifies any middleware layer of software required between
heterogeneous operating system environments and applications. For distributed object-based
middleware message support, specify use of CORBA, DCOM, OLE/COM, MQSeries, RMI or the
emerging JMS specifying APIs to a message-oriented middleware (MOM) engine whose
implementation is required for compliance with J2EE. Other JMS compliant interfaces include
SonicMQ, FiroranoMQ, iBus, or SwitfMQ.
Additionally, specify architecture requirements for “real-time” MOMs, such as TIBCO, Talarian,
Mercator, NEON, etc.
3.12.1.
Middleware Models
CONTENT: This subsection identifies the types of middleware to be employed in the new
architecture.
Two types of middleware models exist: logical and physical. The logical middleware model
depicts how the information moves around conceptually throughout the enterprise. In contrast,
the physical model depicts both the actual method of information movement and the technology
employed.
The following are the types of middleware models available:
1. Point-to-Point: MOM products – MQSeries and RPCs (such as RMI and DCE)
2. Many-to-Many: Message Brokers, Transactional middleware (application servers and TP
monitors), distributed objects (CORBA)
Specify the connection-oriented and connectionless message exchange associated with the
selected middleware product being used. For example:

03/03/16
Direct communications
GEN 3 Partners Proprietary & Confidential
PAGE 12
WORKING DRAFT – Enterprise Architecture Document Template

Queued communications

Publish/Subscribe

Request/Response

Fire-and-forget
3.12.2.
Types of Middleware
CONTENT: In this subsection list the types of middleware employed in the current system and
those planned for the future system architectures. The types include the following:

RPC

Message-Oriented (MOM)

Distributed Objects (CORBA RMI/IIOP)

Database Oriented (e.g., Oracle database-oriented middleware)

Transaction Oriented & TP Monitors

Application Servers

Message Brokers (Message Transformation, Intelligent Routing, Rules
Processing, Message Warehousing, Flow Control, Repository Services, Directory
Services, APIs and Adapters
A system architect should make special effort to become well versed in this important IT area.
3.13. Information Architecture View
CONTENT: This subsection describes the persistent data storage and data interchange
perspectives of the system. This section is optional if there is little or no persistent data, or the
translation between the Design Model and the Data Model is trivial.
For persistent data storage, this section should describe both logical and physical data models.
3.13.1.
Data Model
CONTENT: This subsection provides a conceptual representation of the data structures that are
required for the enterprise databases. The data structures include the data objects, the
associations between data objects, and the rules, which govern operations on the objects. The
data model should focus on what data is required and how it should be organized rather than
what operations will be performed on the data. The data model should be independent of
hardware or software constraints.
Note: If enterprise requirements state extensive use of XML, then there should be a section
included in this document highlighting the use of XML databases, or making use of XML-support
with a standard relational databases, e.g., Oracle, IBM, etc.
3.13.2.
Data Interchange
CONTENT: This subsection defines the data interchange methods: ETL, XML, XSLT
transformation engines required by the enterprise, etc.
3.13.3.
Persistent Storage Strategy
CONTENT: If applicable, this subsection discusses object-oriented enterprise architecture
03/03/16
GEN 3 Partners Proprietary & Confidential
PAGE 13
WORKING DRAFT – Enterprise Architecture Document Template
persistence model.
3.14. External facing systems
CONTENT: This section specifies how certain B2B eCommerce application/subsystem packages
fit into the overall architecture.
There are two important points to keep in mind when architecturally assessing an existing, or
future, enterprise design.
EAI (Enterprise Application Integration) typically deals with the integration of applications and data
sources within an existing enterprise to solve a local problem – see diagram below..
Company A
Custom Apps
text
EAI
SAP
SAP
text
EAI
Middleware
dSA
text
dSA
Legacy
Legacy
PeopleSoft
text
dSA
B2B
Company
Company A
A
Company
Company C
C
EAI
Middleware
Company
Company B
B
B2B
Middleware
In contrast, B2B application integration is the integration of systems between organizations to
support any business requirement, such as sharing information with trading partners (see
diagram above). Although EAI and e-Business exist in different problem domains, the technology
and approaches applied to both can be similar or quite different.
The term “Application Integration” applies to both environments (i.e., EAI and B2B). Application
integration was low-level play, with developers working at the network protocol layer or just above,
before advancing to true middleware solutions, such as RPCs, MOM, and transactional
middleware.
With B2B, the next generation of middleware has arrived, with new categories such as message
brokers, B2Bi servers, application servers, distributed objects, and intelligent agents.
It is critical that the system architect have a firm grasp on the differences of these technologies
and able to specify/apply an appropriate technology solution.
4.
SYSTEMS INTEGRATION STRATEGY & GOALS
CONTENT: This subsection defines the landscape by which GEN 3 Partners views Systems
Integrators and its internal needs for these services. A proper definition of SI itself ideally
03/03/16
GEN 3 Partners Proprietary & Confidential
PAGE 14
WORKING DRAFT – Enterprise Architecture Document Template
conforms to a top-level architecture, which deals with certain states of SI. Each state of
integration has its own unique definition, properties, aspects, and complexities
There are four states of system integration:
1. State 1: Interconnectivity
2. State 2: Interoperability
3. State 3: Semantic consistency
4. State 4: Convergent integration
Three of these are contingent on technology and its status; however, the fourth represents a
convergence of technology and human performance, processes, and knowledge. This document
does not deal with State 4. The main focus is on GEN 3’s ability to achieve system
interconnectivity, interoperability, and semantic consistency related to the planned architecture.
State1: Interconnectivity. This is the most elementary state of integration. If forms the
baseline for all subsequent integration. Interconnectivity involves making various pieces
of often-disparate equipment and technologies communicate together.
State 2: Interoperability. Interoperability refers to the ability to make one application
and technology function with another in a manner that exploits the capabilities of both.
State 3: Semantic Consistency. The emphasis is on providing accessibility to data and
minimizing the potential for errors in human interpretation through the creation of
standard data definitions and formats. In achieving semantic integration, data must be
rationalized and have significant meaning to the user
State 4: Convergent Integration. Convergent integration involves the integration of
technology with business processes, knowledge, and human performance. As
mentioned above, this document is not intended to address this area.
03/03/16
GEN 3 Partners Proprietary & Confidential
PAGE 15
WORKING DRAFT – Enterprise Architecture Document Template
4.1.
Types of B2B Application Integration
CONTENT: This subsection specifies the type of B2B integration is required. Often, the role of
the system architect is one of system and/or B2B integration design versus system and
application design. Given this, the dimensions of B2B integration include:
1. Data-oriented
2. Application interface-oriented
3. Method-oriented
4. Portal-oriented
5. Process integration-oriented
The diagram below describes the layered integration aspect of Process Integration
Process Integration
Transformation,
Rules Processing,
Intelligent Routing
Messaging Services
Example: Process Integration Modeling Tool
Example: Message Broker
Example: MOM
4.1.1. Data-Oriented Integration
CONTNET: This subsection specifies the type of databases utilized within the enterprise and the
information flow between systems. Given the potential complexity of this area, specify the need
for powerful many-to-many, B2B application integration data-movement and transformation tools
and technologies. Specify any planned XML data interchange strategies.
4.1.2. Application Interface Oriented-Integration
CONTENT: This subsection discusses application interface-oriented integration. Typically, there
are several layers of interfaces within an enterprise that an architect must deal with. They
include:
1. Application Interfaces include business logic, application component interfaces (e.g., Java
RMI, CORBA, IIOP, and COM+) along with legacy wrapping technology. The system
architect should provide a high level description of the requirements for this type of
integration.
2. Packaged Applications are typically “stovepipe” type applications including SAP,
PeopleSoft, Oracle, Baan, Lawson Software, JD Edwards, and Scopus are to name a few
dominating the scene.
3. Other interfaces include:
a. Vertical market application interfaces, e.g., SWIFT, FIX. HL7, etc.
b. Custom applications
c. Application wrapping
Specify high-level technical requirements and interfaces required in the forthcoming system
architecture.
03/03/16
GEN 3 Partners Proprietary & Confidential
PAGE 16
WORKING DRAFT – Enterprise Architecture Document Template
4.1.3. Method-Oriented Integration
CONTENT: This subsection specifies whether B2B traders plan to share common business logic
and methods by hosting them on a central server (i.e., method warehousing) or by accessing
them inter-application (e.g., through distributed objects).
4.1.4. Portal-Oriented Integration
CONTENT: This subsection specifies the type of single-user interface integrating all participating
systems through the browser, although the applications are not directly integrated within or
between the enterprises.
4.1.5. Process-Oriented Integration
CONTENT: This subsection specifies a set of processes that function above both business rules
and information integration. Process integration is unlike traditional middleware. It is in actuality a
process model that resides on top of middleware providing both logical and physical information
flows over existing business/enterprise systems. The types of tools in this category (e.g.,
CrossWorlds, etc) enable the following types of capabilities.
5.

Business Process Modeling (BPM) – graphical design and simulation of business
processes

Business Process Automation (BPA) – automation of business processes without
end user interaction; classical EAI types of tools

Workflow – automation of business process with end user interaction

Business Process Integration – aggregation of the items listed above
DEPLOYMENT VIEW
CONTENT: This section describes one or more physical network (hardware) configurations on
which the software is deployed and run. It is a view of the Deployment Model. At a minimum for
each configuration it should indicate the physical nodes (computers, CPUs) that execute the
software and their interconnections (bus, LAN, point-to-point, and so on.) Also include a mapping
of the processes of the Process View onto the physical nodes.
6.
IMPLEMENTATION VIEW
CONTENT: This section describes the overall structure of the implementation model, the
decomposition of the software into layers and subsystems in the implementation model, and any
architecturally significant components.
6.1.
Subsystem Layers
CONTENT: For each layer, include a subsection with its name, an enumeration of the
subsystems located in the layer, and a component diagram.
6.2.
PURCHASED COMPONENTS
CONTENT: This section describes any purchased components to be used with the system, any
applicable licensing or usage restrictions, and any associated compatibility/interoperability or
interface standards.
03/03/16
GEN 3 Partners Proprietary & Confidential
PAGE 17
WORKING DRAFT – Enterprise Architecture Document Template
7.
SIZING AND PERFORMANCE
CONTENT: This section discusses the major dimensioning characteristics (i.e., system sizing) of
the software that impact the architecture, as well as the target performance constraints.
The performance characteristics of the system should be outlined in this section. Include specific
response times. Where applicable, reference related Use Cases by name.
8.

Response time for a transaction (average, maximum)

Throughput (for example, transactions per second)

Capacity (for example, the number of customers or transactions the system can
accommodate)

Degradation modes (what is the acceptable mode of operation when the system has
been degraded in some manner)

Resource use: memory, disk, communications, and so forth]
SYSTEM RESILIENCY & HIGH AVAILABILITY
CONTENT: This section discusses system resiliency and high availability requirements and
architecture. This is a particularly important area of system architecture and cost. It is critical that
the system architecture has a good handle on the important issues in this area.
The term “system resiliency” and “high availability” mean that all of a system’s failure modes are
known and well-defined, including networks and applications. They mean that the recovery times
for all known failures have an upper bound; we know how long a particular failure will have the
system down. While there may be certain failures that we cannot cope with very well, we know
what they are and how to recover from them.
A resilient system is one that can take a hit to a critical component, and recover and come back
for more in a known, bounded, and generally acceptable period of time.
It is the system architect’s role to have a good understanding of the issues here and to factor
them into the deliverables to the client. Ideally, some of these issues should be raised in the
system requirements process and, perhaps, be factored into a risk management plan.
03/03/16
GEN 3 Partners Proprietary & Confidential
PAGE 18
WORKING DRAFT – Enterprise Architecture Document Template
8.1.
Measuring Availability
CONTENT: This subsection outlines how one measures system availability. When one
discusses system availability requirements with a user or project leader, he or she will invariably
reply that 100 percent availability is required: “Our project is so important that we can’t have any
downtime at all.” But the tune usually changes when the project leader finds out how much 100
percent availability costs. Then it becomes a matter of money, and more of a negotiation
process. As one can see from the table below, for many enterprises, 99 percent uptime is
(usually) adequate.
PERCENTAGE
UPTIME
PERCENTAGE
DOWNTIME
DOWNTIME PER
YEAR
DOWNTIME PER WEEK
98%
2%
7.3 days
3 hours, 22 minutes
99%
1%
3.65 days
1 hour, 41 minutes
99.8%
0.2%
17 hours, 30 minutes
20 minutes, 10 seconds
99.9%
0.1%
8 hours, 45 minutes
10 minutes, 5 seconds
99.99%
0.01%
52 minutes
1 minute
99.999%
0.001%
5.25 minutes
6 seconds
99.9999%
0.0001%
31.5 seconds
0.6 seconds
If the systems average an hour-and-a-half of downtime per week that may be satisfactory. Of
course, a lot of that depends on when the hour-and-a-half occurs. If it falls between 3:00 and
4:30 Sunday morning that is going to be a lot more tolerable on many systems that if it occurs
between 10:00 and 11:30 Thursday morning, or every weekday afternoon at 2:00 for 15 or 20
minutes.
These potential stringent requirements may necessitate fault-tolerant, or cluster failover
architectures adding to the overall cost to the customer. Be sure and address these issues early
on with the customers.
8.2.
Reliability
CONTENT: This subsection outlines technical requirements and architectural design for reliability
of the system. Suggestions are as follows:
03/03/16

Availability – Specify percentage of time available ( xx.xx%), hours of use,
maintenance access, degraded mode operations, and the like.

Mean Time Between Failures (MTBF) – This is usually specified in hours but it could
also be specified in terms of days, months or years.

Mean Time To Repair (MTTR) – How long is the system allowed to be out of
operation after it has failed?

Accuracy – Specify precision (resolution) and accuracy (by some known standard)
that is required in the systems output.

Maximum bugs or defect rate – Usually expressed in terms of bugs/KLOC (thousands
of lines of code), or bugs/function-point.

Bugs or defect rate – Categorized in terms of minor, significant, and critical bugs: the
requirement(s) must define what is meant by a “critical” bug; for example, complete
loss of data or complete inability to use certain parts of the functionality of the system.
GEN 3 Partners Proprietary & Confidential
PAGE 19
WORKING DRAFT – Enterprise Architecture Document Template
8.3.
Identification of Failure Modes
CONTENT: This subsection outlines all modes of system failure, and recovery processes, that
can potentially affect an operational system. They include:

Hardware

Environmental and Physical Failures – e.g., power failure/brownouts, cooling, etc.

Network Failures – e.g., several routers connecting networks at multiple points and
one failure, denial of service, etc.

Database System Failures

Web Server Failures

Application Server Failures

File and Print Server Failures
The only way to convince the people who control the purse strings (i.e., the customer) that there is
value in protecting uptime is to approach the problem from a dollars-and-cents perspective. In
short, quality costs money.
9.
QUALITY
CONTENT: This section describes how the overall software architecture contributes to all
capabilities (other than functionality) of the system: extensibility, reliability, portability, and so on. If
these characteristics have special significance, such as safety, security or privacy implications,
they must be clearly delineated.
10.
SUPPORTABILITY
CONTENT: This section indicates any requirements that will enhance the supportability or
maintainability of the system being built, including coding standards, naming conventions, class
libraries, maintenance access, maintenance utilities.
03/03/16
GEN 3 Partners Proprietary & Confidential
PAGE 20
WORKING DRAFT – Enterprise Architecture Document Template
DESCRIPTION OF APPENDICIES
The following appendices are provided as samples of diagrams that are appropriate for the EAD. The
diagrams are excerpts from an architecture involving a ground transportation system.
APPENDIX A – Layered Architecture View
APPENDIX B – Functional Subsystem View – using a combination of UML Use Case and
Deployment notations
APPENDIX C – Logical Component Overview
APPENDIX D – Detailed Component Overview
Note: Legend in upper right hand corner is color coated to reflect prioritization of
requirements – yellow = “must have”; green = “should have”; red = “could have”
APPENDIX E – Physical Architecture Overview
03/03/16
GEN 3 Partners Proprietary & Confidential
PAGE 21
WORKING DRAFT – Enterprise Architecture Document Template
APPENDIX A – SAMPLE LAYERED ARCHITECTURE VIEW
The diagram below represents a layered (hierarchical) decomposition of a proposed system
architecture. The diagram was produced with Visio 2000 Professional Edition and can be modified to
suit the needs of any system architecture.
Customer Care
Scripts
Knowledge Base
Customer
Wireless Payment
Kiosk
Customer Issues
On-line Help
Workflow
Account Maintenance
Passenger Monitoring
Business Content
Operations
Reservation
Registration
Marketing Content
Passenger Service
Availability Check
Security
CSA Security
Customer Content
Customer Relationship
Management System
Reservation System
Content System
Field CSA System
Emergency
Roadside Service
Mapping/Routing
Dynamic Flight Info
Automatic Highway
Traffic Info
Manifest Management
Automatic Vehicle
Location
CSA Tracking
Passenger Tracking
Fleet Dispatch
ODMA
Arrival Notification
Infrastructure
Monitoring System
Look-up Tables
Fleet Dispatch System
Reporting System
Site Customization
Data Mining System
Data Maintenance System
Data-Mining System
Historical Logging
Fleet Maintenance
Fleet Maintenance System
Logging System
External Integration System
Electronic
Confirmation
Error Logging
Fleet Logistics
Partner Integration
Alerts System
Notification System
Leasing
Certification / Licensing
Purchasing
Electronic Billing
Benefits
HR/Finance
Payment System
Credit Check
Recruiting / Hiring
Payroll
Employment
Work Schedules
HR System
03/03/16
Financials GL/AR/AP/
Forecasting
Financial System
GEN 3 Partners Proprietary & Confidential
PAGE 22
WORKING DRAFT – Enterprise Architecture Document Template
APPENDIX B – SAMPLE FUNCTIONAL SUBSYSTEMS OVERVIEW
Uses
Content System
Customer
Two-way integration
Alerts
Uses
Reservation System
Reserves
Customer
Relationship Mgmt
System
Data Maintenance
System
Notification System
Logging System *
External Integration
System
Registers Alerts/Confirmations
Arrival Notification
Customer
Manager
Fleet System
(Maintenance/
Logistics)
Uses
Data Mining System
Sends Alerts/Confirmation
Manages / Maintains
Sends Status
Tracking System
Registers Alerts/Receipts
Gets Data
Optimized Demand
Management
Application
Uses
Field CSA System
Field CSA
Registers Alerts
Uses
Dispatches
Infrastructure
Alerts
Operations
Manages
Sends Status
HR System
HR/Finance
Financial System
Internal
Credit Checks/Billing
Payments
03/03/16
GEN 3 Partners Proprietary & Confidential
* The Logging System logs data
from customer info, reservations
and tracking systems.
PAGE 23
WORKING DRAFT – Enterprise Architecture Document Template
APPENDIX C – SAMPLE LOGICAL COMPONENT OVERVIEW
Customers
Client Applications
Business Partners,
Logistic Providers &
Affiliates
Networking
&
Communication
Financial Network
Web Servers
Content Providers
Wireless Content Servers
Logistics Providers
Miscellaneous Communication Servers
Security Controls
Security,
Middleware &
e-business Integration
Application Server
Directory Server (LDAP)
Integration Server
Application Logic Components
Application
Business Logic
Transactional
Database
CRM
Database
Financials and BackOffice
Database
Content Management
Database
Object Relational
Databases
Data Warehouse
Database
Business Operations
&
Customer Care
(Intranet / Extranet)
Back-Office Operations
Front-Office Operations
Enterprise Data Center
and/or
Hosting Provider
Collocation Services
Servers
03/03/16
Customer Care
Network
GEN 3 Partners Proprietary & Confidential
PAGE 24
WORKING DRAFT – Enterprise Architecture Document Template
APPENDIX D – SAMPLE DETAIL COMPONENT OVERVIEW
03/03/16
GEN 3 Partners Proprietary & Confidential
PAGE 25
WORKING DRAFT – Enterprise Architecture Document Template
APPENDIX E – SAMPLE PHYSICAL ARCHITECTURE OVERVIEW
03/03/16
GEN 3 Partners Proprietary & Confidential
PAGE 26