"Creating a Systems Architecture for an SOA-based IT System as Part of"
Creating a Systems Architecture for an SOA-based IT System as Part of a Systems Engineering Process Robert S. Ellinger, Ph.D. Enterprise Architect Gabriel Hoffman Senior System Engineer October 2008 Agenda • Service Oriented Architecture? • Service Oriented Architecture and Investment-Driven SOA (ID- SOA™) • Creating a System Architecture for an SOA-based IT System 2 Services-Oriented Architecture? The Problem • IT organizations often focus on implementing technology yet not enough on helping a customer organization accomplish its mission • Today's IT solutions tend to be based on COTS architectures that often enforce specific business processes and lack open technology upgrade paths – Flexibility: Large-scale COTS applications have limits on their configurability, so the application does not readily support the organization’s continuously changing processes – Technology Upgrade: Upgrading or replacing technology is often very difficult, that hinders the organization in achieving its mission with the current IT technology • Therefore, too often the organization conforms to the IT needs, instead of IT conforming to what the organization requires 4 SOA as a Solution • Service Oriented Architecture (SOA) assists the organization with focusing its IT on solving business problems – Measurably links the applications to the organization’s processes to enable the organization to understand the contribution of each application within the process. This enables the organization to determine whether its investment is worthwhile – Provides ―line-of-sight‖ • From the Organization’s Mission through its Strategies to its Processes to determine the optimal place for the next investment • To support the intent of the Federal Enterprise Architecture (FEA), a concept which is being incorporated into the DoD Architecture Framework version 2 5 SOA as a Solution (Continued) • The SOA enables the organization’s IT to support continuous process change – Existing ―composite‖ applications can be reassembled to support a change in the organization’s processes in a Continuous Operational and Development Environment (CODE) – The ―Composite‖ applications are the Services and are assemble from Service Components, each of which is a separate application (which may be a Web Service) • Each Service Component may be upgraded to new technology or replaced independently • These Service Components are assembled using a process flow which may be redesigned independently of the components being used 6 ID-SOA™ • A good SOA process will help management to: – Identify processes and IT systems that are producing minimal or no value for the organization, that is, IT systems that are good candidates for investment – Recommend deletion or investment (by updates/upgrades or replacement) – Execute projects that the customer has approved as IT investments – Evolve toward a service-based business vision/model with the agility to successfully respond to unexpected challenges and opportunities • In other words, a good SOA process allows the organization to use an IT investment process to optimize its processes and the supporting IT systems and applications in a CODE • Northrop Grumman’s Investment-Driven Service-Oriented Architecture (ID-SOA™) is such a process 7 The ID-SOA™ Process Enterprise SOA Business Process Service Modeling and Development Engineering Composite Composite Application Composite Application Modeling and Application Assembly Development: Composite ServiceService Management Lifecycle Application Lifecycle: Infrastructure: Service Development Composite Application The Service provides activities and Infrastructure provides functions that support Lifecycle (CAL) is the Business Process and functions that enable the creation and testing Composite Composite CompositeComponents of Service Application and support the use of Composite Applications Modeling, Assembly, Application Application and Deployment in production and the Operation Deployment governance functions process Execution Context (Services Infrastructure) 9 ID-SOA™ Simplified High-level Flow Enterprise SOA Created Here 10 Creating a System Architecture for an SOA- based IT System The Composite Application Lifecycle • Composite Application Creating SystemsApplication Composite Architecture– Business Process Modeling and Assembly: Operation: Using thethe This activity: andFunctions Modeling Management: Deployment: Using Business Assembly functions and • DecomposesInfrastructure to Services the The Engineering: Business and Service Components Governance functions Service Components that Process support theand ProcesssupportComposite to that Model thefunctions Services Infrastructure processesassembly of support the Modeling and Create • Derives the IT Functions associated withproduction Applications in Business deployment of Composite measure the performance Composite Applications Engineering Systems required to enable and support • Process Modeling Applications to production, of the business processes the Compositeidentical with & that Application Modeling: • This is and Service Components process—creating the including Verification to ensure meeting SLAs (BPM)/(BIOS is Business Architecture Functions support the requirements” “functionalevaluateofprocesses current software and to conversion Innovationtestinga business Validation and Composite process model into a model Composite • Structures identical with Service • Optimizationfunctions, to deploymenta repository or This is the IT Functions for future revisions of Application using Composite Application current the details may though software supports optimize communications Services).of service upgrades BIOS Components. Analysis of the Composite Application model, based on the business Application Modeling and vary somewhat. the the functions and among as-is and to-be components deployment functions, process model enables minimize the number of though the details Business Process may Management Assembly • Composite Application Assembly: • Functions functions redundantand Service Components that Modeling activities This somewhat. vary set of functions • Allocates theB-SLAs, which enable the assembly of Composite Functions to requiredfrom build Components supports to Service Applications Components—creating the are new in Applications Composite SOA • These are entirely new functions “Component Requirements” • BPM has been used, Composite Composite standalone in the past; it is Application Application integrated in the SOA CAL Operation Deployment 12 The Overall IT System Architecture Process Identify the Customer’s Requirements The System Architecture Decomposition Process • Decomposition includes: Process Modeling Functional Modeling • Derivation Includes: Determining the IT Functions Required Derivation • Structuring/Allocation Includes: Structuring and grouping the Functions to support the Process Structuring/ Assigning the Grouped Functions to Allocation Components 13 The Overall System Architecture Process (More Detail) 14 The System Requirements Document (SRD) Used as Inputs (Table of Contents) 1 Introduction 4 Design Constraints 1.1 Purpose 4.1.1 Size and Location of User Community 1.2 Scope 4.1.2 Interfaces 1.3 Background 4.1.3 Customer Furnished or Identified Components 1.4 Identification 4.1.4 Data Base 1.5 Rapid Implementation Approach 4.1.5 System Transition 1.6 Document Change Management 4.1.6 Training 1.7 Referenced Documents 4.1.7 General Computing Controls & Security 2 System Context 4.1.8 Business Continuity (COOP) 2.1 Organizational Mission, and Strategies 4.1.9 Performance and Availability 2.2 System Scope 4.1.10 Information Retention/Purging/Archiving 2.2.1 In Scope 4.1.11 Other Constraints 2.2.2 Out of Scope 4.1.12 Hardware and Software Standards 2.3 Business Processes 4.1.13 Communications and Network 2.3.1 BP1 4.2 Customer IT Standards Constraining the Design 2.3.2 BP2 4.2.1 Architectural Constraints 2.3.3 BP3 4.2.2 Scalability 2.3.4 BPi 4.2.3 Reliability/Availability 2.3.5 BPn 4.2.4 Service Infrastructure 3 Use Cases 4.3 Outside Standards and Specifications Constraining the Design 3.1 Actors 5 System Validation 3.2 Use Cases Identified by Actor, Business Process, and Release Appendix A: Acronyms, and Abbreviations 3.3 Use Cases Appendix B: Glossary 15 The Decomposition Activity : Submitter : APO Administrator : POA : Submitter : APO Administrator : POA detail / Objective: To define processes and activities in sufficient Submission to allow the Send Re-send to support the process derivation of IT functions Submission Send IAFIS Response Re-send Submission / Submission IAFIS Response [ SPO Mode ] Level 1 – Example: Parallel Operations [ SPO Mode ] [ APO Mode ] : Submitter : APO Administrator : POA : IAFIS : Primary : Secondary Receive & Process Submission Send Re-send Submission / Receive & Process [ APO Mode ] Submission Submission IAFIS Response [ SPO Mode ] Initiate APO Stage Submission [ APO Mode ] Initiatefor APO APO Stage Submission Initiate APO Stage Submission for APO Receive & Process Submission for APO Receive Response(s) Receive Re-send IAFIS Sent to other agencies as well Response(s) [ APO Mode ] Receive Submission [ APO Mode ] Store Responses Response(s) Store IAFIS Submissions Analyze Analyze Performance Re-send IAFIS Sent to other Comparative Data Data (from pTM logs) [ APO Mode ] Submission Re-sen agencies as well Sent to other [ APO Mode ] Subm agencies as well Comparative & Performance Analysis [ APO Mode ] Complete [ APO Store Responses Store IAFIS Store Responses Submissions Store Level 2 – Example: Stage APO Level 2 – Example: Resend Submission Subm : APO Administrator : POA NG-ABIS 1.0 : Secondary : Primary : Secondary : POA : Submitter : NGIC-AIMS Launch APO Initialize Controller Display GUI Send Analyze Receive Response Send Analyze Performance Receive Response Select Data Select Load Response Comparative Data Response Data (from pTM logs) Analyze P AnalyzeReceive Response Factor Send Response Receive Secondary Response Comparative Data Data (fro Initiate Asynchronous Pre-Process Operations Queue Systems have a response [ APO Mode ] Response Process to return to the Submitter Store Received Queue Send Receive Process Response Submission Submission Submission Exit APO Display [ records = 0 ] [ records > 0 ] [ SPO Mode ] Controller Results Send IAFIS Receive IAFIS Process IAFIS Response Response Response Store IAFIS Receive IAFIS Send IAFIS Submission Submission Submission Response Response Selected data processed by NG-ABIS 1.0 Store Match Response Receive Match Response Send Match Response Comparative & Performance Analysis Discarded Stored Flow may overlap with Send IAFIS Submission Flow may overlap with Complete Comparative & Performance A AD starting here Send Response AD starting here Complete 16 Derivation Objective: To determine what IT Functions are required to enable and support the processes and activities determined in decomposition IT Classes (Services and Service Components) are derived from objects in the process : NistCompare source : target : : : POA : JNistpack JNistpack Discrepancy DiscrepancyCollection ctor(Source, Target) ctor( ) Initialize: readVerification(filename) readTransaction(filename) ctor( ) readVerification(filename) readTransaction(filename) compareNist( ) For each compareImage(Source, Target, RecordNum, Index) image: getImage( ) If discrepency: ctor( ) compareText(Source, Target, RecordNum, Index) For each Text Field: findItem( ) If discrepency: ctor( ) storeDiscrepencies( ) 17 Structuring and Allocation: Step 1 Objective: To Structure and group IT functions into Services to: • Minimize the number of redundant functions • Optimize the grouping of IT functions for allocation • And to Allocate the grouped functions to actual service components Step 1: Structure Classes with Communications Diagrams Objective: Determine tightly and loosely coupled classes (and functions) • Step 1.1 Create Communications Diagram − Initiate by Duplicating IT portions of Activity Diagrams as Communication Diagrams − Two Top-level Classes: Service Process Flow 18 Structuring and Allocation: Step 1 Level 2 – Seq. Dia.: Stage APO* Diagrams Class Diagram : APO Administrator : POA NG-ABIS 1.0 : Secondary Launch APO Initialize Controller Display GUI Select Data Select Load Factor Initiate Asynchronous Pre-Process POS Operations Queue Process Queue Send Receive Process Submission Submission Submission Exit APO Display [ records = 0 ] [ records > 0 ] Candidate Controller Results Send IAFIS Receive IAFIS Process IAFIS Response Response Response Store IAFIS Receive IAFIS Send IAFIS Submission Submission Submission Selected data processed by NG-ABIS 1.0 Store Match Receive Match Send Match Response Response Response Flow may overlap with Send IAFIS Submission AD starting here Flow may overlap with Send Response AD starting here Inputs to Communications Diagram The POS Communications Diagram *Asynchronous Parallel Operations 19 Structuring and Allocation: Step 2 Objective: To Structure and group IT functions into Services to: • Minimize the number of redundant functions • Optimize the grouping of IT functions for allocation • And to Allocate the grouped functions to actual service components Step 2: QFD and Graph Analysis Objective: Determine the minimum number of Logical Service Components Required • Step 2.1 Graph Analysis—Analysis of Communications Diagrams • Analysis Principles Include: −Noting where one class communicates only with one other class or a small group of classes −Noting where there is one or two links between groups of classes • Step 2.2 Quality Functional Deployment Analysis 20 Structuring and Allocation: Graph Analysis : APO Administrator : POA NG-ABIS 1.0 : Secondary Service Candidates are Launch APO Initialize Controller identified by base Display GUI grouping or clustering Select Data Select Load Factor Initiate Asynchronous Operations Pre-Process Queue of functions and Process communications POS Queue Send Receive Process Secondary interfaces Submission Submission Submission Exit APO Display [ records = 0 ] [ records > 0 ] Controller Results Send IAFIS Receive IAFIS Process IAFIS Response Response Response Selected data processed Candidate Store IAFIS Submission Receive IAFIS Submission Service Send IAFIS Submission Interface used here by NG-ABIS 1.0 Store Match Receive Match Send Match Response Response Response Candidate Flow may overlap with Send IAFIS Submission AD starting here Flow may overlap with Send Response AD starting here 21 Structuring and Allocation: QFD Analysis ―The House of Quality‖ Quality Functional Deployment analysis ―Roof‖ added to is common sense with determine level of a template service (functional) redundancy Note: QFD analysis is Service* Submission Submission Send IAFIS Operations Papa. Ops generally used to etc. Service Service Service determine + or – Async. Send correlations between Activity+ two phenomena, but Send used here to Submission + + ++ determine: Send IAFIS • If all activities have Response + + ++ associated services • Where services are Rec. IAFIS Response highly correlated leading to redundant Rec. Match services Response Store IAFIS Response etc. + = some correlation ++ = high correlation +Activity from Activity Diagram *Service from Communications Diagram 22 Structuring and Allocation: Step 3 Objective: To Structure and group IT functions into Services to: • Minimize the number of redundant functions • Optimize the grouping of IT functions for allocation • And to Allocate the grouped functions to actual service components Step 3: Dynamic Service/functional Modeling Objective: Use simulation to verify, within a confidence interval, that the functional model will meet the customer’s system requirements • Currently, the SOA and SA tools suppliers do not support this activity to the degree required by SOA 23 Structuring and Allocation: Step 4 Objective: To Structure and group IT functions into Services to: • Minimize the number of redundant functions • Optimize the grouping of IT functions for allocation • And to Allocate the grouped functions to actual service components Step 4: Allocation of Services/Functions to Actual Components Objective: Allocate the services/functions to components using a make/buy/use tradeoff study procedure • Step 4.1: Assign Design Constraints to Proposed Components • Step 4.2: Perform Tradeoff Study − Make—the team develops the service component − Buy—the service component is purchased from a software supplier − Use—the team discovers and uses a service component in the SOA Ecosystem (across the Internet 24 Results to Date • The team has completed the Systems Requirements Document (SRD) to establish the requirements baseline with the customer. This includes: – Identifying the processes and activities (in the form of use cases) – Identifying the design constraints • The team has decomposed the requirements in the SRD into two levels of Activity Diagrams to define the ―detailed what‖ with the customer. This was delivered as the System Design Document • The team derived the IT functions by translating the detailed Activity Diagrams into Sequence and Class diagrams • The team then allocated these into the specific components (COTS, existing software, new software, server scripts, hardware, and networks) to create the detailed design. This was integrated into the Detailed Design Document and presented to the customer for a very successful Critical Design Review 25 Questions? Contact Information • Robert S. Ellinger, Ph.D. – firstname.lastname@example.org • Gabriel Hoffman – email@example.com 27 28