Requirement Specification Example



Enterprise Architecture Document

[Client Name]

February 12, 2001

|NOTE: This document is intended to serve as a template and set of guidelines to be used in constructing an Enterprise Architecture Document. |

|It is a working draft and subject to change, based upon review by the GEN 3 Partners CTO and System Architecture Team. |

|It is not intended that users of the document follow the rigid format contained herein. While the document is a template, along with |

|suggested guidelines for content, it is up to the user to decide which sections are most appropriate for the need. |

Revision 0.2

[ Template & Guidelines ]

REVISION HISTORY

|Version |Date |Authors |Description of Revision |

|0.1 |02-07-01 |Allen Berglund |First Draft |

|0.2 |02-11-01 |Allen Berglund |Incorporated Les McMonagle’s review comments |

| | | |Added section on B2B Application Integration |

| | | |Expanded section on High Availability |

| | | |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.

Author’s Comment & Recommendation

|It is recommended that all GEN 3 Partners System Architects upgrade their current version of Visio 2000 Standard to Visio 2000 Professional. |

|The standard version has little or no support for business process modeling, UML, database modeling, broader networking diagramming, project |

|scheduling, PERT charts, etc. Of particular note, the professional version modeling support includes the following: |

|Booch OOD |Shlaer-Mellor |

|COM and OLE |SSADM |

|Connectors |UML Activity Diagram |

|Gane-Sarson |UML Collaboration Diagram |

|Jackson |UML Component Diagram |

|Jacobson Use Cases |UML Deployment Diagram |

|Language Level Shapes |UML Sequence Diagram |

|Memory Objects |UML Statechart Diagram |

|Nassi-Schneiderman |UML Static Structure (Class Diagramming) |

|Office User Interface |UML Use Case Diagram |

|ROOM |Windows User Interface Diagram |

|Rumbaugh OMT |Yourdon and Coad |

Table of Contents

1. introduction 7

1.1. Purpose 7

1.2. Scope 7

1.3. Definitions, Acronyms, and Abbreviations 7

1.4. References 7

1.5. Overview 7

2. Current Architectural Representation 7

2.1. Logical Architecture 7

2.2. Physical Architecture 8

3. Future Architectural Representation 8

3.1. Planned Infrastructure 8

3.2. Reference Architecture 8

3.3. Architectural Goals and Constraints 8

3.4. Logical View 8

3.5. Standards-Compliance-Requirements Overview 9

3.5.1. Application Standards Compliance And Requirements 9

3.5.2. System Standards Compliance Requirements 9

3.5.3. Security Model Standards Compliance Requirements 9

3.6. Performance Requirements 9

3.6.1. Environmental Requirements 10

3.6.2. Legacy Code Wrapping Requirements 10

3.7. Use Case view 10

3.8. Process View 10

3.9. Use Case Realizations 10

3.10. Interfaces 10

3.10.1. User Interfaces 10

3.10.2. Hardware Interfaces 11

3.10.3. Software Interfaces 11

3.10.4. Communications Interfaces 11

3.11. Frameworks 11

3.11.1. Java 2 Enterprise Edition – Object Framework 11

3.11.2. RosettaNet – Service Framework 11

3.11.3. BizTalk – Service Framework 11

3.11.4. SAP & PeopleSoft – Procedural Frameworks 12

3.12. Middleware & Messaging 12

3.12.1. Middleware Models 12

3.12.2. Types of Middleware 13

3.13. Information Architecture View 13

3.13.1. Data Model 13

3.13.2. Data Interchange 13

3.13.3. Persistent Storage Strategy 13

3.14. External facing systems 14

4. Systems Integration Strategy & Goals 14

4.1. Types of B2B Application Integration 16

4.1.1. Data-Oriented Integration 16

4.1.2. Application Interface Oriented-Integration 16

4.1.3. Method-Oriented Integration 17

4.1.4. Portal-Oriented Integration 17

4.1.5. Process-Oriented Integration 17

5. deployment view 17

6. Implementation View 17

6.1. Subsystem Layers 17

6.2. PURCHASED COMPONENTS 17

7. SIZing AND PERFORMANCE 18

8. system resiliency & High availability 18

8.1. Measuring Availability 19

8.2. Reliability 19

8.3. Identification of Failure Modes 20

9. QUALITY 20

10. SUPPORTABILITY 20

Description of Appendicies 21

Appendix A – sample Layered Architecture View 22

Appendix B – sample Functional Subsystems Overview 23

Appendix C – sample logical component overview 24

appendix d – sample detail component overview 25

Appendix E – sample physical architecture overview 26

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 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. |

2 Scope

|CONTENT: This subsection provides a brief description of what the EAD applies to; what is affected or influenced by this document.|

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. |

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. |

5 Overview

|CONTENT: This subsection describes what the rest of the EAD contains and explains how the document is organized. |

Current Architectural Representation

|CONTENT: This section describes what software architecture is for the current system, and how it is represented. |

1 Logical Architecture

|CONTENT: This subsection provides a description of current client logical architecture – diagrams are preferred. See appendix |

2 Physical Architecture

|CONTENT: This subsection provides a description of current client physical architecture – diagrams are preferred. |

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. |

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). |

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 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. |

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. |

5 Standards-Compliance-Requirements Overview

|CONTENT: This subsection describes the overall decomposition of the design model in terms of its package hierarchy and layers. |

1 Application Standards Compliance And Requirements

|CONTENT: CONTENT: This subsection describes by reference any applicable standards and the specific sections of any such standards |

|that apply to the system being described. For example, this could include legal, quality and regulatory standards, industry |

|standards for usability, interoperability, internationalization, operating system compliance, programming language, middleware, |

|etc. |

2 System Standards Compliance Requirements

|CONTENT: Define any system requirements necessary to support the application. These may include the supported host operating |

|systems and network platforms, configurations, memory, peripherals, and companion software. |

|These can include legal and regulatory (FDA, UCC) communications standards (TCP/IP, ISDN), platform compliance standards (Windows, |

|UNIX, Lunux, and other OS platforms), and quality and safety standards (ISO, CMM), etc. |

3 Security Model Standards Compliance Requirements

|CONTENT: This section covers two essential security models that must be addressed: |

|Enterprise systems security from outside intrusion |

|Network security for data communicated over the Web |

|Trust Model |

|Security Guidelines |

|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. |

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.|

1 Environmental Requirements

|CONTENT: This subsection details environmental requirements as needed. For hardware-based systems, environmental issues include |

|temperature, shock, humidity, radiation, and so on. For software applications, environmental factors include usage conditions, user|

|environment, resource availability, maintenance issues, and error handling and recovery. |

2 Legacy Code Wrapping Requirements

|CONTENT: This subsection addresses requirements for design techniques whereby existing (legacy) code (algorithms, function |

|libraries, data structures, database interfaces, etc.) are wrapped, or encapsulated, inside classes. The goal of this |

|requirement/design is a means of both insulating the users from the legacy code and improving the nature of the interface and |

|functions provided by that code. |

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. |

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. |

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.) |

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. |

1 User Interfaces

|CONTENT: This subsection describes the user interfaces that are to be implemented by the software. |

2 Hardware Interfaces

|CONTENT: This subsection defines any hardware interfaces that are to be supported by the software, including logical structure, |

|physical addresses, expected behavior, etc. |

3 Software Interfaces

|CONTENT: This subsection describes software interfaces to other components of the software system. These may be purchased |

|components, components reused from another application or components being developed for subsystems outside of the scope of this |

|EAD, but with which this software application must interact. |

4 Communications Interfaces

|CONTENT: This subsection defines any licensing enforcement requirements or other usage restriction requirements that are to be |

|exhibited by the software. |

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. |

1 Java 2 Enterprise Edition – Object Framework

|CONTENT: J2EE is an example of a robust object framework. List the business domains and relevant component elements embedded in |

|the J2EE framework. (J2EE is an object framework.) |

2 RosettaNet – Service Framework

|CONTENT: This subsection discusses RosettaNet from a logical B2B framework perspective. Even though it is considered more of a |

|standard than a technical framework, for the purpose of this document we will use the analogy of RosettaNet as a framework. From a|

|technical perspective, the end deliverable is RosettaNet’s PIP (Partner Integration Process) consisting of the Business Operational|

|View (BOV), Functional Service View (FSV), and Implementation Framework View (IFV). |

|In this subsection, list all of the relevant architectural requirements and integration design points for elements of RosettaNet, |

|if required. (RosettaNet is a Service Framework.) |

3 BizTalk – Service Framework

|CONTENT: [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.) |

4 SAP & PeopleSoft – Procedural Frameworks

|CONTENT: [PROCEDURAL FRAMEWORK] – SAP/R3 is a procedural framework most popular in the ERP space. As with most things, connecting|

|to SAP has an upside and a downside. SAP, like most other packaged applications, was build as a monolithic solution never intended|

|to communicate with the outside world. SAP’s challenges are the lack of open interfaces. In this subsection, discuss how the new |

|architecture will interface with SAP/R3 |

|PeopleSoft is the most open of all ERP procedural frameworks. Unlike SAP, the PeopleSoft application server is based on open |

|technology – BEA’s Tuexedo. In this subsection, discuss how the new architecture will interface with PeopleSoft. (SAP and |

|PeopleSoft are Procedural Frameworks.) |

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. |

1 Middleware Models

|CONTENT: This subsection identifies the types of middleware to be employed in the new architecture. |

|TWO TYPES OF MIDDLEWARE MODELS EXIST: LOGICAL AND PHYSICAL. THE LOGICAL MIDDLEWARE MODEL DEPICTS HOW THE INFORMATION MOVES AROUND |

|CONCEPTUALLY THROUGHOUT THE ENTERPRISE. IN CONTRAST, THE PHYSICAL MODEL DEPICTS BOTH THE ACTUAL METHOD OF INFORMATION MOVEMENT AND|

|THE TECHNOLOGY EMPLOYED. |

|The following are the types of middleware models available: |

|Point-to-Point: MOM products – MQSeries and RPCs (such as RMI and DCE) |

|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 |

2 Types of Middleware

|CONTENT: In this subsection list the types of middleware employed in the current system and those planned for the future system |

|architectures. The types include the following: |

|RPC |

|Message-Oriented (MOM) |

|Distributed Objects (CORBA RMI/IIOP) |

|Database Oriented (e.g., Oracle database-oriented middleware) |

|Transaction Oriented & TP Monitors |

|Application Servers |

|Message Brokers (Message Transformation, Intelligent Routing, Rules Processing, Message Warehousing, Flow Control, Repository |

|Services, Directory Services, APIs and Adapters |

|A system architect should make special effort to become well versed in this important IT area. |

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. |

1 Data Model

|CONTENT: This subsection provides a conceptual representation of the data structures that are required for the enterprise |

|databases. The data structures include the data objects, the associations between data objects, and the rules, which govern |

|operations on the objects. The data model should focus on what data is required and how it should be organized rather than what |

|operations will be performed on the data. The data model should be independent of hardware or software constraints. |

| |

|Note: If enterprise requirements state extensive use of XML, then there should be a section included in this document highlighting |

|the use of XML databases, or making use of XML-support with a standard relational databases, e.g., Oracle, IBM, etc. |

2 Data Interchange

|CONTENT: This subsection defines the data interchange methods: ETL, XML, XSLT transformation engines required by the enterprise, |

|etc. |

3 Persistent Storage Strategy

|CONTENT: If applicable, this subsection discusses object-oriented enterprise architecture persistence model. |

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.. |

[pic]

|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. |

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: |

|State 1: Interconnectivity |

|State 2: Interoperability |

|State 3: Semantic consistency |

|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. |

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: |

|Data-oriented |

|Application interface-oriented |

|Method-oriented |

|Portal-oriented |

|Process integration-oriented |

|The diagram below describes the layered integration aspect of Process Integration |

|[pic] |

1 Data-Oriented Integration

|CONTNET: This subsection specifies the type of databases utilized within the enterprise and the information flow between systems. |

|Given the potential complexity of this area, specify the need for powerful many-to-many, B2B application integration data-movement |

|and transformation tools and technologies. Specify any planned XML data interchange strategies. |

2 Application Interface Oriented-Integration

|CONTENT: This subsection discusses application interface-oriented integration. Typically, there are several layers of interfaces |

|within an enterprise that an architect must deal with. They include: |

|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. |

|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. |

|Other interfaces include: |

|Vertical market application interfaces, e.g., SWIFT, FIX. HL7, etc. |

|Custom applications |

|Application wrapping |

|Specify high-level technical requirements and interfaces required in the forthcoming system architecture. |

3 Method-Oriented Integration

|CONTENT: This subsection specifies whether B2B traders plan to share common business logic and methods by hosting them on a |

|central server (i.e., method warehousing) or by accessing them inter-application (e.g., through distributed objects). |

4 Portal-Oriented Integration

|CONTENT: This subsection specifies the type of single-user interface integrating all participating systems through the browser, |

|although the applications are not directly integrated within or between the enterprises. |

5 Process-Oriented Integration

|CONTENT: This subsection specifies a set of processes that function above both business rules and information integration. |

|Process integration is unlike traditional middleware. It is in actuality a process model that resides on top of middleware |

|providing both logical and physical information flows over existing business/enterprise systems. The types of tools in this |

|category (e.g., CrossWorlds, etc) enable the following types of capabilities. |

|Business Process Modeling (BPM) – graphical design and simulation of business processes |

|Business Process Automation (BPA) – automation of business processes without end user interaction; classical EAI types of tools |

|Workflow – automation of business process with end user interaction |

|Business Process Integration – aggregation of the items listed above |

deployment view

|CONTENT: This section describes one or more physical network (hardware) configurations on which the software is deployed and run. |

|It is a view of the Deployment Model. At a minimum for each configuration it should indicate the physical nodes (computers, CPUs) |

|that execute the software and their interconnections (bus, LAN, point-to-point, and so on.) Also include a mapping of the processes|

|of the Process View onto the physical nodes. |

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. |

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. |

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. |

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] |

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. |

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. |

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. |

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. |

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. |

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. |

[pic]

Appendix B – sample Functional Subsystems Overview

[pic]

Appendix C – sample logical component overview

[pic]

appendix d – sample detail component overview

[pic]

Appendix E – sample physical architecture overview

[pic]

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download