Enterprise Architecture DocumentEnterprise Architecture Document[Client Name]
May 24, 2023
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.2Revision 0.2
[ Template & Guidelines ]
GEN 3 Partners Proprietary & Confidential
REVISION HISTORY
Version Date Authors Description of Revision0.1 02-07-01 Allen Berglund First Draft0.2 02-11-01 Allen Berglund 1. Incorporated Les McMonagle’s review comments
2. Added section on B2B Application Integration3. Expanded section on High Availability4. 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 & RecommendationIt 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................................................................................................................................... 71.1. PURPOSE................................................................................................................................... 71.2. SCOPE....................................................................................................................................... 71.3. DEFINITIONS, ACRONYMS, AND ABBREVIATIONS..............................................................................71.4. REFERENCES.............................................................................................................................. 71.5. OVERVIEW.................................................................................................................................. 7
2. CURRENT ARCHITECTURAL REPRESENTATION......................................................................72.1. LOGICAL ARCHITECTURE..............................................................................................................72.2. PHYSICAL ARCHITECTURE............................................................................................................8
3. FUTURE ARCHITECTURAL REPRESENTATION..........................................................................83.1. PLANNED INFRASTRUCTURE.........................................................................................................83.2. REFERENCE ARCHITECTURE.........................................................................................................83.3. ARCHITECTURAL GOALS AND CONSTRAINTS...................................................................................83.4. LOGICAL VIEW............................................................................................................................ 83.5. STANDARDS-COMPLIANCE-REQUIREMENTS OVERVIEW....................................................................9
3.5.1. Application Standards Compliance And Requirements........................................................93.5.2. System Standards Compliance Requirements....................................................................93.5.3. Security Model Standards Compliance Requirements.........................................................9
3.6. PERFORMANCE REQUIREMENTS....................................................................................................93.6.1. Environmental Requirements............................................................................................103.6.2. Legacy Code Wrapping Requirements..............................................................................10
3.7. USE CASE VIEW........................................................................................................................ 103.8. PROCESS VIEW......................................................................................................................... 103.9. USE CASE REALIZATIONS...........................................................................................................103.10. INTERFACES.......................................................................................................................... 10
3.10.1. User Interfaces................................................................................................................. 103.10.2. Hardware Interfaces.........................................................................................................113.10.3. Software Interfaces..........................................................................................................113.10.4. Communications Interfaces..............................................................................................11
3.11. FRAMEWORKS....................................................................................................................... 113.11.1. Java 2 Enterprise Edition – Object Framework..................................................................113.11.2. RosettaNet – Service Framework.....................................................................................113.11.3. BizTalk – Service Framework...........................................................................................113.11.4. SAP & PeopleSoft – Procedural Frameworks....................................................................12
3.12. MIDDLEWARE & MESSAGING...................................................................................................123.12.1. Middleware Models...........................................................................................................123.12.2. Types of Middleware........................................................................................................13
3.13. INFORMATION ARCHITECTURE VIEW.........................................................................................133.13.1. Data Model....................................................................................................................... 133.13.2. Data Interchange..............................................................................................................133.13.3. Persistent Storage Strategy..............................................................................................13
3.14. EXTERNAL FACING SYSTEMS...................................................................................................14
4. SYSTEMS INTEGRATION STRATEGY & GOALS........................................................................144.1. TYPES OF B2B APPLICATION INTEGRATION..................................................................................16
4.1.1. Data-Oriented Integration.................................................................................................164.1.2. Application Interface Oriented-Integration.........................................................................164.1.3. Method-Oriented Integration.............................................................................................17
GEN 3 Partners Proprietary & Confidential
WORKING DRAFT – Enterprise Architecture Document Template
4.1.4. Portal-Oriented Integration...............................................................................................174.1.5. Process-Oriented Integration............................................................................................17
5. DEPLOYMENT VIEW.................................................................................................................... 17
6. IMPLEMENTATION VIEW.............................................................................................................176.1. SUBSYSTEM LAYERS.................................................................................................................. 176.2. PURCHASED COMPONENTS................................................................................................17
7. SIZING AND PERFORMANCE......................................................................................................18
8. SYSTEM RESILIENCY & HIGH AVAILABILITY............................................................................188.1. MEASURING AVAILABILITY...........................................................................................................198.2. RELIABILITY.............................................................................................................................. 198.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
05/24/23 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
05/24/23 GEN 3 Partners Proprietary & Confidential PAGE 6
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 full-scale 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,
05/24/23 GEN 3 Partners Proprietary & Confidential PAGE 7
WORKING DRAFT – Enterprise Architecture Document Template
operations, and attributes.
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 RequirementsCONTENT: 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 RequirementsCONTENT: 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 RequirementsCONTENT: 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.
05/24/23 GEN 3 Partners Proprietary & Confidential PAGE 8
WORKING DRAFT – Enterprise Architecture Document Template
3.6.1. Environmental RequirementsCONTENT: 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 RequirementsCONTENT: 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 use-case (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 InterfacesCONTENT: This subsection describes the user interfaces that are to be implemented by the software.
05/24/23 GEN 3 Partners Proprietary & Confidential PAGE 9
WORKING DRAFT – Enterprise Architecture Document Template
3.10.2. Hardware InterfacesCONTENT: 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 InterfacesCONTENT: 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 InterfacesCONTENT: 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 FrameworkCONTENT: 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 FrameworkCONTENT: 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 FrameworkCONTENT: [SERVICE FRAMEWORK] – This subsection discusses Microsoft’s BizTalk
05/24/23 GEN 3 Partners Proprietary & Confidential PAGE 10
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.)
3.11.4. SAP & PeopleSoft – Procedural FrameworksCONTENT: [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 ModelsCONTENT: 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:
05/24/23 GEN 3 Partners Proprietary & Confidential PAGE 11
WORKING DRAFT – Enterprise Architecture Document Template
Direct communications Queued communications Publish/Subscribe Request/Response Fire-and-forget
3.12.2. Types of MiddlewareCONTENT: 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 ModelCONTENT: 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 InterchangeCONTENT: This subsection defines the data interchange methods: ETL, XML, XSLT transformation engines required by the enterprise, etc.
3.13.3. Persistent Storage StrategyCONTENT: If applicable, this subsection discusses object-oriented enterprise architecture
05/24/23 GEN 3 Partners Proprietary & Confidential PAGE 12
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..
text
text
text
dSA
dSA
text
dSA
EAIMiddleware
EAIMiddleware
B2BMiddleware
Company ACompany A
Company ACompany A
Company BCompany B
Company CCompany C
EAIEAI
B2BB2B
Custom AppsCustom Apps
SAPSAP
PeopleSoftPeopleSoft
LegacyLegacy
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
05/24/23 GEN 3 Partners Proprietary & Confidential PAGE 13
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: Interconnectivity2. State 2: Interoperability3. State 3: Semantic consistency4. 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.
05/24/23 GEN 3 Partners Proprietary & Confidential PAGE 14
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-oriented2. Application interface-oriented3. Method-oriented4. Portal-oriented5. Process integration-oriented
The diagram below describes the layered integration aspect of Process Integration
Messaging Services
Transformation,Rules Processing,Intelligent Routing
Process Integration
Example: MOM
Example: Message Broker
Example: Process Integration Modeling Tool
4.1.1. Data-Oriented IntegrationCONTNET: 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-IntegrationCONTENT: 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 applicationsc. Application wrapping
Specify high-level technical requirements and interfaces required in the forthcoming system architecture.
05/24/23 GEN 3 Partners Proprietary & Confidential PAGE 15
WORKING DRAFT – Enterprise Architecture Document Template
4.1.3. Method-Oriented IntegrationCONTENT: 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 IntegrationCONTENT: 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 IntegrationCONTENT: 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.
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
5. 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.
05/24/23 GEN 3 Partners Proprietary & Confidential PAGE 16
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.
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]
8. 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.
05/24/23 GEN 3 Partners Proprietary & Confidential PAGE 17
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:
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.
05/24/23 GEN 3 Partners Proprietary & Confidential PAGE 18
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.
05/24/23 GEN 3 Partners Proprietary & Confidential PAGE 19
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
05/24/23 GEN 3 Partners Proprietary & Confidential PAGE 20
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
Infrastructure
HR/Finance
Operations
Customer RelationshipManagement System
Reservation System Content System Field CSA System
Monitoring System Fleet Dispatch System
Data Maintenance System Data-Mining System External Integration System
Fleet Maintenance System Logging System Notification System
HR System Financial System
Security
Registration
Account Maintenance
Customer CareScripts
Knowledge Base
Customer Issues
On-line Help
Availability Check
Reservation
Customer Content
Marketing Content
Kiosk
Business Content
Passenger Service
CSA Security
Passenger Monitoring
Workflow
Wireless Payment
Mapping/Routing
Automatic HighwayTraffic Info
Automatic VehicleLocation
Fleet Dispatch
ODMA
Look-up Tables
Site Customization Data Mining System
Reporting System
Partner Integration
Fleet Maintenance
Fleet Logistics
Historical Logging
Error Logging
Alerts System
ElectronicConfirmation
Employment
Certification / Licensing
Benefits
Recruiting / Hiring
Work Schedules
Leasing
Purchasing
Electronic Billing
Payment System
Credit Check
Payroll
Financials GL/AR/AP/Forecasting
EmergencyRoadside Service
Dynamic Flight Info
Manifest Management
CSA Tracking
Passenger Tracking
Arrival Notification
05/24/23 GEN 3 Partners Proprietary & Confidential PAGE 21
WORKING DRAFT – Enterprise Architecture Document Template
APPENDIX B – SAMPLE FUNCTIONAL SUBSYSTEMS OVERVIEW
External IntegrationSystem
Data Mining System
Data MaintenanceSystem
Notification System Logging System *
Fleet System(Maintenance/
Logistics)
Optimized DemandManagementApplication
Tracking System
Field CSA System
Content System
Reservation System
CustomerRelationship Mgmt
System
Customer
Customer
Field CSA
Uses
Sends Status
Gets Data
Uses
Reserves
Registers Alerts
Uses
Uses
Infrastructure
PaymentsCredit Checks/Billing
Registers Alerts/Receipts
Sends Status
HR/Finance
* The Logging System logs datafrom customer info, reservationsand tracking systems.
Two-way integration
Uses
Alerts
Sends Alerts/Confirmation
Alerts
Arrival Notification
Operations
Registers Alerts/Confirmations
Dispatches
Internal
Manager
Manages / M
aintains
Manages
Financial SystemHR System
05/24/23 GEN 3 Partners Proprietary & Confidential PAGE 22
WORKING DRAFT – Enterprise Architecture Document Template
APPENDIX C – SAMPLE LOGICAL COMPONENT OVERVIEW
Business Partners,Logistic Providers &
Affiliates
Customers
Networking&
Communication
Application Business Logic
Security,Middleware &
e-business Integration
Object RelationalDatabases
Enterprise Data Centerand/or
Hosting Provider
Business Operations&
Customer Care(Intranet / Extranet)
Application Server Integration ServerDirectory Server (LDAP)
Web Servers Miscellaneous Communication Servers
Client Applications
TransactionalDatabase
CRMDatabase
Financials and BackOfficeDatabase
Content ManagementDatabase
Data WarehouseDatabase
Back-Office Operations Front-Office Operations Customer Care
Servers
Collocation Services
Network
Financial Network Content Providers Logistics Providers
Security Controls
Application Logic Components
Wireless Content Servers
05/24/23 GEN 3 Partners Proprietary & Confidential PAGE 23
WORKING DRAFT – Enterprise Architecture Document Template
APPENDIX D – SAMPLE DETAIL COMPONENT OVERVIEW
Enterprise Data Center&
Hosting ProviderServices
(ISP / ASP)
Customer Specific Application Logic Components
Fleet Dispatch
Content Management &
Translation(WML)
ContentExchange &
Collaboration
Online WebCustomer Care
Create andMaintain Master
RentalAgreement
IVR CustomerCare
FleetManagement &
Scheduling
Promotions Management
PersonalizationBasic
Ad ServingEngine
ApplicationManagement&
Reporting
Tax Calculation( US )
Search Engine(DB, Docs)
E-mail and FaxNotifications
Customer CareIssue (CSR)
Tracking
PersonalizationAdvanced
Web SiteAuthoring
& UserExperience
GPS OperationsManagement
ApplicationComponent
Design &Development
In-Car KioskWeb Enabled
PartnerIntegration
GPS IntegrationFleet Dispatch 1:1 Marketing Alerts
PaymentAuthorization
&Settlement
RentalReservations
ReservationStatus and
History
Sedan Service-Pickup and
Return
Rental Service -Pickup and
Return
Billing Historyand AccountManagement
CustomerRegistration &
ProfileManagement
SedanReservations
Business Partners,Logistic Providers
&Affiliates
Customers
Networking&
CommunicationServices
Application Servers
RequestManagement
Session &State
ManagementWeb ServerIntegration
ISAPI /NSAPI / CGI
DatabaseAccess
Management
DynamicPage
Generation
DynamicLoad
Balancing
Auditing &Logging
FailureRecovery &
Restart
ApplicationProgrammaticEnvironment
CachingInternet Middleware&
e-businessIntegration Services
ApplicationBusiness Logic
&Development
Services
Object RelationalDatabase Infrastructure
Services
Ideal ProjectBusiness Operations
&Customer Care
Services(Intranet / Extranet)
Object Relational Databases
Oracle8i Enterprise Server Infrastructure
Analysis & ReportingData Warehouse SystemTransactional Data Store Customer Care Data Store
CRM Back-Office Data Store Content ManagementData Store
Backup & RecoveryReplication Partitioning Parallel ProcessingRedundancy & Failover
SecurityServices
Collocation / HostingFacilities
PhysicalServerHosting(Cages)
Help Desk
Fire Protection
Security
Power
24x7 Monitoring
ApplicationMonitoring &
Administration
DatabaseMonitoring &
Administration
NetworkMonitoring &Administration
Configuration& Release
Management
Backup&
Recovery
DisasterRecovery
Network
Server Hardware
Traffic Analysis & Reporting Firewall SecurityBandwidth & Connectivity
NT Platform Clustering UNIX Platform
Redundancy &
High AvailabilityPe
rfor
man
ce &
Scal
abili
ty
Integration ServersBusiness Process Workflow
Data Transformation
Rules-based Routing
XML / EDI / Other
Message Broker / Queuing
Message Transport
Adap
ters
e-business Security InfrastructureSecurity Access ControlsAuthorization
Encryption
Confidentiality
Auditing
Non-Repudiation
Integrity
Network and System ServersAuthentication Server
e-Wallet Server
Certificate Server
VPN
Intrusion Detection
FirewallLDAPDirectory Servers
Miscellaneous Communication Services
Internet MessagingSMTP / POP3 /
IMAP4FTP
HTTP&
IIOP
Fax&
PagingVoice
Web Servers
Extensions&
Plug-Ins
Site TrafficLogging
StaticPage
Caching
HTTP /HTTPS
Listeners
Wireless Content Servers
Content &Transaction
Engine
AdaptersWeb DB Custom
Should
ApplicationAdministration
&Operations
Data Mining /Business
Intelligence(DSS)
Must
Could
Client Application ServicesWeb
Business toConsumer
eCustomers
Business toBusiness
eCustomers
AffiliateWeb Sites
Client Application ServicesWireless
CustomersPDA
CSA-RAC PDA
CustomersWAP Phone
CSA-Sedan PDA
In-Car WebKiosk
ContentProviders
Wireless ServiceProvider
Payment Processor&
Financial Network
Internet ServiceProvider
(ISP)
Business Partners
TravelProviders AirlinesCar
Rental Hotels
Back-Office OperationsFinancials, Distribution & Procurement
Flee
t Man
agem
ent
& S
ched
ulin
g
Hum
an R
esou
rces
Purc
hasi
ng
Paya
bles
Rec
eiva
bles
Gen
eral
Led
ger
Payr
oll
Flee
t Dis
patc
h
Front-Office OperationsCustomer Relationship Management
Mar
ketin
g
Tele
/ Fi
eld
Sale
s
Customer Care Services
Support eMailManagement
KnowledgeBase
Call Center Service (CSR)Live Chat FAQs
05/24/23 GEN 3 Partners Proprietary & Confidential PAGE 24
WORKING DRAFT – Enterprise Architecture Document Template
APPENDIX E – SAMPLE PHYSICAL ARCHITECTURE OVERVIEW
High SpeedInterconnect
LDAP Directory ServerseMail Servers
example -Sun E450 w/ OID[Load Balanced & Clustered]
Node 1 Node 2
System Monitoring ServersBackup Servers
example - Sun E250[Clustered & Redundant]
GigabitEthernet
Database ServersOracle8i Database
example Sun E4500[Load Balanced, Redundant & Clustered]
Disk Arrayexample - EMC, Sun
DLT Tape Library
InternetBackbone
html/http
Wireless Content Serversexample -Sun250 -iAS/Portal-to-Go
[Load Balanced]
Node1 Node2 Node n
Web Server Farm
Node1 Node2 Node n
Application Server Farm
Node 1 Node 2
Web Application Serversexample -Sun450 w/ iAS, iPlanet, BEA
[Load Balanced]
Node1 Node2 Node n
Wireless Content Server Farm
Web Serversexample -Sun250 w/ Apache, Netscape
[Load Balanced]
High SpeedInterconnect
Disk Array
example- Sun E450
Development & Testing Cluster
example- Sun E450
Backbone Switches[Redundant Pair]
{wml,sms,hdml}/http
ISP
Internet Switches[Redundant Pair]
Internet Routers[Redundant Pair]
Firewall Serversexample- Checkpoint
Firewall-I[Redundant Pair]
Load Balancing Routersexample -F5 Labs BI/Gip
[Load Balanced & Redundant]
Network OperationsCenter (NOC) provideshigh speed redundantconnection to theInternet backbone
Wireless Network Carriers example - AT&T, Bell South,
Metricom, Motient
Radio towerIdeal ProjectCustomers
Ideal ProjectCustomers
WirelessCarrier
Networkwsp / w
tp
Wireless NetworkCarriers
example - AT&T, BellSouth, Metricom,
Motient
Wireless Service Providers example - GoAmerica, AT&T,
Bellsouth, Omnisky
WirelessCarrier
Network
NOC
Ideal ProjectCustomer Service
Agents (CSA)
05/24/23 GEN 3 Partners Proprietary & Confidential PAGE 25