requirement specification example - userland...

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.


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


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



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


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


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,



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.



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.



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



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:



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



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



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.



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.



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.



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.



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.



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.



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



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



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



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



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



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)


requirement specification example - userland...

Documents