introduction
Upcoming SlideShare
Loading in...5
×
 

introduction

on

  • 1,469 views

 

Statistics

Views

Total Views
1,469
Views on SlideShare
1,469
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    introduction introduction Document Transcript

    • Enterprise Architecture Document [Client Name] June 8, 2010 NOTE: This document is intended to serve as a template and set of guidelines to be used in constructing an Enterprise Architecture Document. It is a working draft and subject to change, based upon review by the GEN 3 Partners CTO and System Architecture Team. It is not intended that users of the document follow the rigid format contained herein. While the document is a template, along with suggested guidelines for content, it is up to the user to decide which sections are most appropriate for the need. Revision 0.2 [ Template & Guidelines ] GEN 3 Partners Proprietary & Confidential
    • REVISION HISTORY Version Date Authors Description of Revision 0.1 02-07-01 Allen Berglund First Draft 0.2 02-11-01 Allen Berglund 1. Incorporated Les McMonagle’s review comments 2. Added section on B2B Application Integration 3. Expanded section on High Availability 4. Major reorganization of sections to improve flow COPYRIGHT Copyright ©2001 GEN 3 Partners. Affixed is the foregoing notice to protect GEN 3 Partners in case of inadvertent publication. This document is unpublished. PROPRIETARY NOTICE This document contains information that is Proprietary to GEN 3 Partners, Inc. and may not be disclosed to any person who is not a GEN 3 Partners employee without the prior written consent of GEN 3 Partners. In consideration of receipt of this document, the recipient agrees to treat this information as confidential and not reproduce or otherwise disclose this information to any persons not specifically authorized to receive it. GEN 3 Partners reserves the right to request that all copies of this document be returned by the recipient. GEN 3 Partners Proprietary & Confidential
    • WORKING DRAFT – Enterprise Architecture Document Template Author’s Comment & Recommendation It is recommended that all GEN 3 Partners System Architects upgrade their current version of Visio 2000 Standard to Visio 2000 Professional. The standard version has little or no support for business process modeling, UML, database modeling, broader networking diagramming, project scheduling, PERT charts, etc. Of particular note, the professional version modeling support includes the following: Booch OOD Shlaer-Mellor COM and OLE SSADM Connectors UML Activity Diagram Gane-Sarson UML Collaboration Diagram Jackson UML Component Diagram Jacobson Use Cases UML Deployment Diagram Language Level Shapes UML Sequence Diagram Memory Objects UML Statechart Diagram Nassi-Schneiderman UML Static Structure (Class Diagramming) Office User Interface UML Use Case Diagram ROOM Windows User Interface Diagram Rumbaugh OMT Yourdon and Coad GEN 3 Partners Proprietary & Confidential
    • Table of Contents 1. INTRODUCTION.....................................................................................................................................6 1.1. PURPOSE .........................................................................................................................................6 1.2. SCOPE............................................................................................................................................6 1.3. DEFINITIONS , ACRONYMS , AND ABBREVIATIONS ..........................................................................................6 1.4. REFERENCES ....................................................................................................................................6 1.5. OVERVIEW.......................................................................................................................................6 2. CURRENT ARCHITECTURAL REPRESENTATION ...........................................................................6 2.1. LOGICAL ARCHITECTURE......................................................................................................................6 2.2. PHYSICAL ARCHITECTURE....................................................................................................................7 3. FUTURE ARCHITECTURAL REPRESENTATION................................................................................7 3.1. PLANNED INFRASTRUCTURE...................................................................................................................7 3.2. REFERENCE ARCHITECTURE..................................................................................................................7 3.3. ARCHITECTURAL GOALS AND CONSTRAINTS .............................................................................................7 3.4. LOGICAL VIEW..................................................................................................................................7 3.5. STANDARDS -COMPLIANCE -REQUIREMENTS OVERVIEW.................................................................................8 3.5.1. Application Standards Compliance And Requirements..............................................................8 3.5.2. System Standards Compliance Requirements...........................................................................8 3.5.3. Security Model Standards Compliance Requirements...............................................................8 Enterprise systems security from outside intrusion.............................................................................8 2. Network security for data communicated over the Web...................................................................8 3.6. PERFORMANCE REQUIREMENTS.............................................................................................................8 3.6.1. Environmental Requirements.....................................................................................................9 3.6.2. Legacy Code Wrapping Requirements.......................................................................................9 3.7. USE CASE VIEW................................................................................................................................9 3.8. PROCESS VIEW.................................................................................................................................9 3.9. USE CASE REALIZATIONS ....................................................................................................................9 3.10. INTERFACES....................................................................................................................................9 3.10.1. User Interfaces.........................................................................................................................9 3.10.2. Hardware Interfaces...............................................................................................................10 3.10.3. Software Interfaces................................................................................................................10 3.10.4. Communications Interfaces....................................................................................................10 3.11. FRAMEWORKS ...............................................................................................................................10 3.11.1. Java 2 Enterprise Edition – Object Framework......................................................................10 3.11.2. RosettaNet – Service Framework..........................................................................................10 3.11.3. BizTalk – Service Framework.................................................................................................10 3.11.4. SAP & PeopleSoft – Procedural Frameworks........................................................................11 3.12. MIDDLEWARE & MESSAGING.............................................................................................................11 3.12.1. Middleware Models.................................................................................................................11 3.12.2. Types of Middleware..............................................................................................................12 3.13. INFORMATION ARCHITECTURE VIEW.....................................................................................................12 3.13.1. Data Model.............................................................................................................................12 3.13.2. Data Interchange....................................................................................................................12 3.13.3. Persistent Storage Strategy...................................................................................................12 3.14. EXTERNAL FACING SYSTEMS ..............................................................................................................13 4. SYSTEMS INTEGRATION STRATEGY & GOALS.............................................................................13 4.1. TYPES OF B2B APPLICATION INTEGRATION............................................................................................15 4.1.1. Data-Oriented Integration.........................................................................................................15 4.1.2. Application Interface Oriented-Integration................................................................................15 4.1.3. Method-Oriented Integration....................................................................................................16 GEN 3 Partners Proprietary & Confidential
    • WORKING DRAFT – Enterprise Architecture Document Template 4.1.4. Portal-Oriented Integration.......................................................................................................16 4.1.5. Process-Oriented Integration...................................................................................................16 5. DEPLOYMENT VIEW...........................................................................................................................16 6. IMPLEMENTATION VIEW....................................................................................................................16 6.1. SUBSYSTEM LAYERS .........................................................................................................................16 6.2. PURCHASED COMPONENTS...................................................................................................16 7. SIZING AND PERFORMANCE.............................................................................................................17 8. SYSTEM RESILIENCY & HIGH AVAILABILITY..................................................................................17 8.1. MEASURING AVAILABILITY...................................................................................................................18 8.2. RELIABILITY ....................................................................................................................................18 8.3. IDENTIFICATION OF FAILURE MODES......................................................................................................19 9. QUALITY...............................................................................................................................................19 10. SUPPORTABILITY.............................................................................................................................19 DESCRIPTION OF APPENDICIES..........................................................................................................20 APPENDIX A – SAMPLE LAYERED ARCHITECTURE VIEW...............................................................21 APPENDIX B – SAMPLE FUNCTIONAL SUBSYSTEMS OVERVIEW..................................................22 APPENDIX C – SAMPLE LOGICAL COMPONENT OVERVIEW..........................................................23 APPENDIX D – SAMPLE DETAIL COMPONENT OVERVIEW..............................................................24 APPENDIX E – SAMPLE PHYSICAL ARCHITECTURE OVERVIEW....................................................25 06/08/10 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 06/08/10 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, operations, and attributes. 06/08/10 GEN 3 Partners Proprietary & Confidential PAGE 7
    • WORKING DRAFT – Enterprise Architecture Document Template 3.5.Standards-Compliance-Requirements Overview CONTENT: This subsection describes the overall decomposition of the design model in terms of its package hierarchy and layers. 3.5.1.Application Standards Compliance And Requirements CONTENT: CONTENT: This subsection describes by reference any applicable standards and the specific sections of any such standards that apply to the system being described. For example, this could include legal, quality and regulatory standards, industry standards for usability, interoperability, internationalization, operating system compliance, programming language, middleware, etc. 3.5.2.System Standards Compliance Requirements CONTENT: Define any system requirements necessary to support the application. These may include the supported host operating systems and network platforms, configurations, memory, peripherals, and companion software. These can include legal and regulatory (FDA, UCC) communications standards (TCP/IP, ISDN), platform compliance standards (Windows, UNIX, Lunux, and other OS platforms), and quality and safety standards (ISO, CMM), etc. 3.5.3.Security Model Standards Compliance Requirements CONTENT: This section covers two essential security models that must be addressed: 1. Enterprise systems security from outside intrusion 2. Network security for data communicated over the Web 3. Trust Model 4. Security Guidelines 5. Data Classification Scheme Specify firewall implementation with the following: limited IP and Port addresses, limited protocols allowed (http, https, IP), required user authentication at the firewall level, and abstracted IP Server address. Outline relevant technologies that address the following security categories • User Authentication/Authorization • Messaging Confidentiality • Data Integrity • Non-Repudiation Additionally, provide information and requirements for authentication at: front-office application layer, back-office application layer, operating system, authentication, authorization, and security transmission, etc. 3.6.Performance Requirements CONTENT: Use this subsection to detail performance requirements. Performance issues can include such items as user load factors, bandwidth or communication capacity, throughput, accuracy, and reliability or response times under a variety of loading conditions. 06/08/10 GEN 3 Partners Proprietary & Confidential PAGE 8
    • WORKING DRAFT – Enterprise Architecture Document Template 3.6.1.Environmental Requirements CONTENT: This subsection details environmental requirements as needed. For hardware-based systems, environmental issues include temperature, shock, humidity, radiation, and so on. For software applications, environmental factors include usage conditions, user environment, resource availability, maintenance issues, and error handling and recovery. 3.6.2.Legacy Code Wrapping Requirements CONTENT: This subsection addresses requirements for design techniques whereby existing (legacy) code (algorithms, function libraries, data structures, database interfaces, etc.) are wrapped, or encapsulated, inside classes. The goal of this requirement/design is a means of both insulating the users from the legacy code and improving the nature of the interface and functions provided by that code. 3.7.Use Case view CONTENT: This section lists use cases or scenarios from the use-case model if they represent some significant, central functionality of the final system, or if they have a large architectural coverage − they exercise many architectural elements or if they stress or illustrate a specific, delicate point of the architecture. 3.8.Process View CONTENT: This section describes the system's decomposition into lightweight processes (single threads of control) and heavyweight processes (groupings of lightweight processes). Organize the section by groups of processes that communicate or interact. Describe the main modes of communication between processes, such as message passing, interrupts, and rendezvous. 3.9.Use Case Realizations CONTENT: This section illustrates how the software actually works by giving a few selected 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 Interfaces CONTENT: This subsection describes the user interfaces that are to be implemented by the software. 06/08/10 GEN 3 Partners Proprietary & Confidential PAGE 9
    • WORKING DRAFT – Enterprise Architecture Document Template 3.10.2.Hardware Interfaces CONTENT: This subsection defines any hardware interfaces that are to be supported by the software, including logical structure, physical addresses, expected behavior, etc. 3.10.3.Software Interfaces CONTENT: This subsection describes software interfaces to other components of the software system. These may be purchased components, components reused from another application or components being developed for subsystems outside of the scope of this EAD, but with which this software application must interact. 3.10.4.Communications Interfaces CONTENT: This subsection defines any licensing enforcement requirements or other usage restriction requirements that are to be exhibited by the software. 3.11.Frameworks CONTENT: This subsection identifies relevant framework technology for the new enterprise. Typically, framework types include: • Object Frameworks • Service Frameworks • Procedural Frameworks Object Frameworks: are made up of both abstract and concrete classes. They provide abstraction services through the inheritance mechanism that most object-oriented languages and tools provide. Service Frameworks: in contrast to object frameworks, lack inheritance. In general, service frameworks are the best fit for most B 2B application integration domains. Procedural Frameworks: provide a good approach to method-oriented B2B application integration. They represent a “black box” perspective on frameworks in that they restrict developers from extending or modifying basic services. 3.11.1.Java 2 Enterprise Edition – Object Framework CONTENT: J2EE is an example of a robust object framework. List the business domains and relevant component elements embedded in the J2EE framework. (J2EE is an object framework.) 3.11.2.RosettaNet – Service Framework CONTENT: This subsection discusses RosettaNet from a logical B2B framework perspective. Even though it is considered more of a standard than a technical framework, for the purpose of this document we will use the analogy of RosettaNet as a framework. From a technical perspective, the end deliverable is RosettaNet’s PIP (Partner Integration Process) consisting of the Business Operational View (BOV), Functional Service View (FSV), and Implementation Framework View (IFV). In this subsection, list all of the relevant architectural requirements and integration design points for elements of RosettaNet, if required. (RosettaNet is a Service Framework.) 3.11.3.BizTalk – Service Framework CONTENT: [SERVICE FRAMEWORK] – This subsection discusses Microsoft’s BizTalk 06/08/10 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 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.) 3.12.Middleware & Messaging CONTENT: This section identifies any middleware layer of software required between heterogeneous operating system environments and applications. For distributed object-based middleware message support, specify use of CORBA, DCOM, OLE/COM, MQSeries, RMI or the emerging JMS specifying APIs to a message-oriented middleware (MOM) engine whose implementation is required for compliance with J2EE. Other JMS compliant interfaces include SonicMQ, FiroranoMQ, iBus, or SwitfMQ. Additionally, specify architecture requirements for “real-time” MOMs, such as TIBCO, Talarian, Mercator, NEON, etc. 3.12.1.Middleware Models CONTENT: This subsection identifies the types of middleware to be employed in the new architecture. Two types of middleware models exist: logical and physical. The logical middleware model depicts how the information moves around conceptually throughout the enterprise. In contrast, the physical model depicts both the actual method of information movement and the technology employed. The following are the types of middleware models available: 1. Point-to-Point: MOM products – MQSeries and RPCs (such as RMI and DCE) 2. Many-to-Many: Message Brokers, Transactional middleware (application servers and TP monitors), distributed objects (CORBA) Specify the connection-oriented and connectionless message exchange associated with the selected middleware product being used. For example: • Direct communications 06/08/10 GEN 3 Partners Proprietary & Confidential PAGE 11
    • WORKING DRAFT – Enterprise Architecture Document Template • Queued communications • Publish/Subscribe • Request/Response • Fire-and-forget 3.12.2.Types of Middleware CONTENT: In this subsection list the types of middleware employed in the current system and those planned for the future system architectures. The types include the following: • RPC • Message-Oriented (MOM) • Distributed Objects (CORBA RMI/IIOP) • Database Oriented (e.g., Oracle database-oriented middleware) • Transaction Oriented & TP Monitors • Application Servers • Message Brokers (Message Transformation, Intelligent Routing, Rules Processing, Message Warehousing, Flow Control, Repository Services, Directory Services, APIs and Adapters A system architect should make special effort to become well versed in this important IT area. 3.13.Information Architecture View CONTENT: This subsection describes the persistent data storage and data interchange perspectives of the system. This section is optional if there is little or no persistent data, or the translation between the Design Model and the Data Model is trivial. For persistent data storage, this section should describe both logical and physical data models. 3.13.1.Data Model CONTENT: This subsection provides a conceptual representation of the data structures that are required for the enterprise databases. The data structures include the data objects, the associations between data objects, and the rules, which govern operations on the objects. The data model should focus on what data is required and how it should be organized rather than what operations will be performed on the data. The data model should be independent of hardware or software constraints. Note: If enterprise requirements state extensive use of XML, then there should be a section included in this document highlighting the use of XML databases, or making use of XML-support with a standard relational databases, e.g., Oracle, IBM, etc. 3.13.2.Data Interchange CONTENT: This subsection defines the data interchange methods: ETL, XML, XSLT transformation engines required by the enterprise, etc. 3.13.3.Persistent Storage Strategy CONTENT: If applicable, this subsection discusses object-oriented enterprise architecture 06/08/10 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.. Company A Custom Apps Custom Apps text EAI SAP SAP EAI text text Middleware dSA dSA Legacy PeopleSoft PeopleSoft text dSA Company A Company A B2B EAI Company C Company C Middleware Company B Company B B2B Middleware In contrast, B2B application integration is the integration of systems between organizations to support any business requirement, such as sharing information with trading partners (see diagram above). Although EAI and e-Business exist in different problem domains, the technology and approaches applied to both can be similar or quite different. The term “Application Integration” applies to both environments (i.e., EAI and B2B). Application integration was low-level play, with developers working at the network protocol layer or just above, before advancing to true middleware solutions, such as RPCs, MOM, and transactional middleware. With B2B, the next generation of middleware has arrived, with new categories such as message brokers, B2Bi servers, application servers, distributed objects, and intelligent agents. It is critical that the system architect have a firm grasp on the differences of these technologies and able to specify/apply an appropriate technology solution. 4. SYSTEMS INTEGRATION STRATEGY & GOALS CONTENT: This subsection defines the landscape by which GEN 3 Partners views Systems Integrators and its internal needs for these services. A proper definition of SI itself ideally 06/08/10 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: Interconnectivity 2. State 2: Interoperability 3. State 3: Semantic consistency 4. State 4: Convergent integration Three of these are contingent on technology and its status; however, the fourth represents a convergence of technology and human performance, processes, and knowledge. This document does not deal with State 4. The main focus is on GEN 3’s ability to achieve system interconnectivity, interoperability, and semantic consistency related to the planned architecture. State1: Interconnectivity. This is the most elementary state of integration. If forms the baseline for all subsequent integration. Interconnectivity involves making various pieces of often-disparate equipment and technologies communicate together. State 2: Interoperability. Interoperability refers to the ability to make one application and technology function with another in a manner that exploits the capabilities of both. State 3: Semantic Consistency. The emphasis is on providing accessibility to data and minimizing the potential for errors in human interpretation through the creation of standard data definitions and formats. In achieving semantic integration, data must be rationalized and have significant meaning to the user State 4: Convergent Integration. Convergent integration involves the integration of technology with business processes, knowledge, and human performance. As mentioned above, this document is not intended to address this area. 06/08/10 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-oriented 2. Application interface-oriented 3. Method-oriented 4. Portal-oriented 5. Process integration-oriented The diagram below describes the layered integration aspect of Process Integration Process Integration Example: Process Integration Modeling Tool Transformation, Rules Processing, Example: Message Broker Intelligent Routing Messaging Services Example: MOM 4.1.1.Data-Oriented Integration CONTNET: This subsection specifies the type of databases utilized within the enterprise and the information flow between systems. Given the potential complexity of this area, specify the need for powerful many-to-many, B2B application integration data-movement and transformation tools and technologies. Specify any planned XML data interchange strategies. 4.1.2.Application Interface Oriented-Integration CONTENT: This subsection discusses application interface-oriented integration. Typically, there are several layers of interfaces within an enterprise that an architect must deal with. They include: 1. Application Interfaces include business logic, application component interfaces (e.g., Java RMI, CORBA, IIOP, and COM+) along with legacy wrapping technology. The system architect should provide a high level description of the requirements for this type of integration. 2. Packaged Applications are typically “stovepipe” type applications including SAP, PeopleSoft, Oracle, Baan, Lawson Software, JD Edwards, and Scopus are to name a few dominating the scene. 3. Other interfaces include: a. Vertical market application interfaces, e.g., SWIFT, FIX. HL7, etc. b. Custom applications c. Application wrapping Specify high-level technical requirements and interfaces required in the forthcoming system architecture. 06/08/10 GEN 3 Partners Proprietary & Confidential PAGE 15
    • WORKING DRAFT – Enterprise Architecture Document Template 4.1.3.Method-Oriented Integration CONTENT: This subsection specifies whether B2B traders plan to share common business logic and methods by hosting them on a central server (i.e., method warehousing) or by accessing them inter-application (e.g., through distributed objects). 4.1.4.Portal-Oriented Integration CONTENT: This subsection specifies the type of single-user interface integrating all participating systems through the browser, although the applications are not directly integrated within or between the enterprises. 4.1.5.Process-Oriented Integration CONTENT: This subsection specifies a set of processes that function above both business rules and information integration. Process integration is unlike traditional middleware. It is in actuality a process model that resides on top of middleware providing both logical and physical information flows over existing business/enterprise systems. The types of tools in this category (e.g., CrossWorlds, etc) enable the following types of capabilities. • 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. 06/08/10 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. 06/08/10 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 PERCENTAGE DOWNTIME PER DOWNTIME PER WEEK UPTIME DOWNTIME YEAR 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. 06/08/10 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. 06/08/10 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 06/08/10 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 C are Scripts Knowledge Base W ireless Payment Customer Customer Issues Kiosk O n-line H elp W orkflow Account Maintenance Business C ontent Passenger Monitoring R eservation Operations Registration Marketing Content Passenger Service Availability C heck Security C ustom er Content C SA Security C ustom er R elationship R eserv ation System Content Sy stem Field C SA System M anagem ent System Emergency R oadside Service Mapping/R outing D ynamic Flight Info Automatic H ighway T raffic Info Manifest Managem ent Automatic Vehicle Location C SA T racking Passenger T racking Fleet Dispatch Arrival N otification O D MA Infrastructure M onitoring System Fleet Dispatch Sy stem Look-up T ables Reporting System Site Customization D ata Mining System Partner Integration Data M aintenance System Data-M ining Sy stem External Integration System Electronic Fleet Logistics Error Logging C onfirmation Fleet Maintenance Historical Logging Alerts System Fleet M aintenance Sy stem Logging System Notification System Leasing C ertification / Licensing Purchasing Electronic Billing Benefits HR/Finance Payment System Recruiting / H iring C redit C heck Em ployment Payroll Financials G L/AR/AP/ W ork Schedules Forecasting HR Sy stem Financial System 06/08/10 GEN 3 Partners Proprietary & Confidential PAGE 21
    • WORKING DRAFT – Enterprise Architecture Document Template APPENDIX B – SAMPLE FUNCTIONAL SUBSYSTEMS OVERVIEW Uses Content System Customer Two-way integration Alerts Reservation System Uses Reserves Fleet System Data Maintenance External Integration (Maintenance/ System System Logistics) Customer Relationship Mgmt Registers Alerts/Confirmations System Manager Customer Arrival Notification Notification System Logging System * Uses Data Mining System Sends Alerts/Confirmation Sends Status Tracking System Manages / Maintains Registers Alerts/Receipts Gets Data Optimized Demand Management Registers Alerts Uses Application Field CSA System Dispatches Uses Field CSA Infrastructure Alerts Operations Manages Sends Status HR System Financial System Internal HR/Finance Credit Checks/Billing Payments * The Logging System logs data from customer info, reservations and tracking systems. 06/08/10 GEN 3 Partners Proprietary & Confidential PAGE 22
    • WORKING DRAFT – Enterprise Architecture Document Template APPENDIX C – SAMPLE LOGICAL COMPONENT OVERVIEW C ustom ers C lient Applications Business Partners, Financial Network C ontent P rov iders Logistics Prov iders Logistic Providers & Affiliates Networking W eb S erv ers Wireless C ontent S erv ers M iscellaneous Communication Serv ers & C om m unication S ecurity Controls S ecurity, M iddleware & e-business Integration Application Serv er D irectory S erv er (LDAP) Integration S erv er Application Application Logic Components Business Logic T ransactional CR M Financials and BackOffice Content M anagement D atabase Database D atabase Database Object R elational Databases Data Warehouse Database Business Operations & Back-Office Operations Front-Office Operations Customer Care C ustom er C are (Intranet / Extranet) Enterprise Data C enter C ollocation Serv ices and/or Hosting Provider S erv ers Network 06/08/10 GEN 3 Partners Proprietary & Confidential PAGE 23
    • WORKING DRAFT – Enterprise Architecture Document Template APPENDIX D – SAMPLE DETAIL COMPONENT OVERVIEW M ust Client Application S erv ices Client Application Serv ices W eb Wireless Should Business to Business to In-C ar W eb Customers Customers CSA-RAC CS A-S edan C ustom ers Affiliate Consumer Business Kiosk P DA W AP P hone PDA P DA Web S ites eCustomers eCustomers Could B usiness Partners Business Partners, Internet Serv ice Pay ment P rocessor Logistic Prov iders Content W ireless S erv ice Prov ider & T rav el Car Prov iders P rov ider Airlines Hotels & (ISP) Financial Network P rov iders Rental Affiliates Networking Web S erv ers Wireless Content S erv ers M iscellaneous Communication Serv ices & E xtensions S tatic HT T P / Content & Adapters Internet M essaging HT TP Fax S ite T raffic C omm unication & Page HT T PS Transaction SM T P / POP3 / & FTP & Voice Logging W eb DB Custom Services Plug-Ins Caching Listeners Engine IM AP4 IIOP Paging Security Access Controls Network and S y stem Serv ers e-business S ecurity Infrastructure Authorization Non-Repudiation Authentication S erv er Intrusion D etection Security Confidentiality Integrity LDAP Certificate S erv er Firewall Services Directory S erv ers E ncry ption Auditing e-W allet Serv er VP N Application Serv ers Integration Serv ers Business Process W orkflow S ession & Dy namic Database Internet M iddleware Request Data Transformation Web S erv er State Page Access Caching M anagement Adapters & Integration M anagement Generation M anagement Rules-based R outing e-business XM L / EDI / Other ISAPI / Dy namic Failure Application Integration Serv ices NS AP I / CGI Auditing & Load Recov ery & Programmatic M essage Broker / Queuing Logging Balancing Restart Env ironment M essage T ransport Customer S pecific Application Logic C omponents Customer P ay ment Reserv ation Sedan S erv ice- Rental Serv ice - Billing History Registration & S edan Rental Authorization S tatus and Pickup and Pickup and and Account Profile Reserv ations Reserv ations & History Return R eturn M anagement M anagement Settlement Content Create and Fleet Content Application M anagement & Fleet Dispatch M anagement & E xchange & Promotions M aintain M aster IV R Customer Online Web T ranslation M anagement Rental Care Customer Care Business Logic S cheduling (WM L) Collaboration Agreement & Dev elopment P ersonalization Personalization Application T ax C alculation Ad S erv ing S earch E ngine Customer Care E-mail and Fax M anagement& Issue (CS R) Services Basic Adv anced ( US ) Engine (DB, Docs) Notifications Reporting T racking W eb S ite Application Authoring Component In-Car Kiosk Partner GP S Operations GP S Integration 1:1 M arketing Alerts & User Design & W eb E nabled Integration M anagement Fleet Dispatch E xperience Dev elopment Object Relational D atabases Customer Care Data Store Analy sis & Reporting Content M anagement Object R elational T ransactional Data Store Back-Office Data S tore CRM Data Warehouse Sy stem Data S tore Database Infrastructure Services Oracle8i Enterprise S erv er Infrastructure Replication Partitioning Redundancy & Failov er Backup & Recov ery P arallel P rocessing Data M ining / Back-Office Operations Front-Office Operations Business Financials, Distribution & Procurement Customer R elationship M anagement Ideal Project Intelligence Business Operations (DSS ) & Human Resources Fleet M anagement Customer Care S erv ices General Ledger Fleet Dispatch & S cheduling C ustomer C are Receiv ables Purchasing Pay ables T ele / Field M arketing P ay roll Application Services Sales Administration Call Center Liv e Chat Serv ice (CS R) FAQs (Intranet / Extranet) & Operations Knowledge eM ail S upport Base M anagement Collocation / Hosting Backup Database Application Network Configuration Disaster Facilities & M onitoring & M onitoring & M onitoring & & R elease Recov ery Enterprise Data C enter Recov ery Administration Administration Administration M anagement Help Desk & Hosting Prov ider 24x7 M onitoring Serv er Hardware Services P hy sical High Av ailability R edundancy & Performance & Serv er (ISP / ASP) P ower NT P latform Clustering U NIX Platform S calability Hosting (Cages) Fire P rotection Network Security T raffic Analy sis & Reporting Bandwidth & Connectiv ity Firewall S ecurity 06/08/10 GEN 3 Partners Proprietary & Confidential PAGE 24
    • WORKING DRAFT – Enterprise Architecture Document Template APPENDIX E – SAMPLE PHYSICAL ARCHITECTURE OVERVIEW W ireless C arrier Network N etw ork Operations tp N OC C ente r (NOC) provide s W ireless /w h igh sp eed redu ndant w sp c onnec tion to the C arrier Internet b ackb one Network Ideal P roject C ustom ers R adio tower W ireles s Ne twork W ireless S ervic e P roviders Carrie rs exam p le - GoA m erica , A T&T, Internet Ideal P roje ct e xam ple - A T& T, B ell B ells outh, Om nis ky C ustom er S ervice S outh, M etrico m , Backbone Agents (C SA) M otient W ireless N etwork C arriers Ideal P roject e xam ple - A T& T, B ell So uth, C ustom ers IS P M etrico m , M otient Internet R outers [Re dundan t Pa ir] W ireless C ontent S erver Farm In ternet S w itche s [R edundan t P air] Firew all S ervers {w m l,sm s ,hdm l}/http exam ple- C hec kpoint Firew all-I [Red undant Pair] N ode1 N ode2 N ode n Load B alancin g Ro uters W irele ss C ontent S ervers exa m ple -F5 Labs B I/Gip exa m ple -S un2 50 -iA S /P ortal-to-Go [Load B alanced & R edu ndant] [L oad B ala nced] W eb S erv er Farm Gigabit E thernet html/http N ode1 N ode2 N ode n W eb S ervers exam ple -S un25 0 w / A pa che, N etsc ape B ackbone S witches Application Serv er Farm [Load B alanced] [Redu ndant P air] Nod e1 Nod e2 N ode n W eb Application S ervers D ev elopment & T esting C luster exam ple -Su n450 w / iA S , iP lane t, B EA [Load B alanced ] Hig h S peed H igh S peed Inte rconnec t Intercon nect exam ple- S un E 450 e xam p le- S un E 450 D atabase S ervers Oracle 8i D atabas e N ode 1 N ode 2 e xam ple S un E 4500 [Load B ala nced, R edu ndant & C lus tered] LDAP D irectory S ervers eM ail Se rvers D is k A rray e xam ple -S un E 450 w / OID [L oad B alan ced & C lus tered] D isk Array D LT T ape Library Nod e 1 No de 2 e xam p le - E M C , S un S ystem M onitoring S ervers B ackup S ervers e xam p le - S un E 250 [Clustered & R edu ndant] 06/08/10 GEN 3 Partners Proprietary & Confidential PAGE 25