Creating Solution Architecture Templates That align with Business

Creating Solution Architecture Templates That align with Business Drivers and reflect real world best practices John Weiler CTO www. ICHnet. org 703 768 0400

Challenges to implementing Component Architectures • No formal XML DTDs to represent architecture “blueprints” • No formalisms (lexicons) to describe component feature interactions and dependencies • No evaluation techniques to assess COTS solutions interoperability or usability CIOs Feel. . . Overwhelmed? Ill-equipped? Behind the market? Over-sold? At risk? • No body of knowledge from which to leverage lessons learned • No architecture modeling tools for assessing risks or composability

Solution Framework… Drivers & Objectives Architectural Views < Presidential Agenda < Policy Support & Regulatory Contextual Business Model Compliance < Business Requirements & Functions < Organizational Considerations Conceptual Process Model Logical System Model < Business Process Improvement < TCO & Business Case < Priority Refinement < Solution Enablement Component Model < Governance < Best Practices < Stakeholder Acceptance < Trade-offs & Alternatives < System Requirements < Standards & Constraints Products & Results < Change Management < Benefit / Risk Identification < Partnerships & Collaboration A component model is only part of business solution enablement… < Advocacy Operational Lifecycle Mgmt. < Congruent Methodologies Traceability & Interdependence

How Component-Based Architectures will be used… Solution Architects Working Group (SAWG) - Led by the Chief Architect (CTO) - Facilitate communication, integration, and partnership across the EGov initiatives Identify Common Requirements & Standards Component Architectures - Guide the identification of solutions that leverage common components of the architecture Best Practices Build / Buy reusable common component framework Support the sourcing additional implementation options

A Normalized Solution Framework; · Provide a formal methodology, collaboration tools and information for transformation of business drivers into proven and interoperable solution sets · Propagate a knowledge base of EA artifacts · Provide means of sharing best practices and lessons learned · Increase the integrity, timeliness, and contextual relevance of architecture communications between buyers and suppliers

Supporting Evidence and Research · ECCWG (DEPSECDEF) established Software Quality and Interoperability Working Group; finding on www. ICHnet. org · AF Scientific Advisory Board Report on Integrating Commercial items into mission systems, April 2000. · December 99 report published in Information Week: “Why IT Fails” · Results of DARPA Distributed Component-based Architecture Modeling Project · Proceeding from Secure E-Business Executive Summit · Domain Working Groups within OMB, IEEE, and ICH.

Solution Framework Objectives • Reduce uncertainty and risk of mapping solutions to common business requirements • Improve visibility of key technical features, interfaces, functions • Provide consistent approach for evolving solution paradigms for COTS product usage • Generate Industry approval and consensus • Facilitate compliance with Clinger-Cohen, FAR OMB Circulars A 119 & A 130, S. 803, FEAPMO • Provide “clearinghouse” of reusable artifacts and supporting research

Solution Architecture Framework Methodology Origins and Inputs • OSI Reference Model for Open Distributed Processing (views) • OMG Model Driven Architectures (MDA/UML) • IEEE 1471 • DARPA DCAM

Align Validate Integrate Critical Success Factors • Community Based • Comprehensive: “Exerprise” • Alignment Driven • Metric Justified • Adaptive • Normative • Non Prescriptive

Layered Approach Enables separation of concerns Functional Traceability BRM Business Core Business Drivers & Mission Objectives Metrics Associated Metrics Performance Metrics Business Processes & Infrastructure BRM Service Elements & Metrics (SRM) Appl Service Components Layer 1 Infrastructure Service Components Layer N BRM Technical Application Solution & Layer 1 Metrics Common Infrastructure Layer M Effectiveness/Efficiency Interoperability/Security Solution Repository Contribution to Fulfillment Reference Models

ICH EA Alignment Framework Enterprise Architecture Drivers /Inhibiters Missions, Goals and Objectives Revenue Enhancement/C ost Reduction Industry Shifts, Obsolescence, Recent Investments Organizational Change Considerations Budget Legislative Directives Mandates, Regulations Business Driver – Process Mapping Business Process Layer: Enterprise Architecture Functional Hierarchies, Location Mappings Process Maps Process Descriptions, Performance Metrics Security and other Policies Business Process Patterns Technology Enabler – Process Mapping Technology Enablement Layer: (Application) Solution Set: Application Standards & Policies 1. Function/Feature, 2. Performance Characteristic 3. Performance Measure Solution Set Patterns Solution Set – Information & Infrastructure Mapping Information Layer: Data Dictionary Key Information Classes Data Standards & Policies Data Movement Req. Data Patterns Solution Set & Information - Infrastructure Mapping Infrastructure Service Layer: Infrastructure Enabler Description Topology Mappings, High Level Protocol Stacks IT Mgmt Architecture, Standards & Policies Infrastructure Patterns Domain discipline Architectures Component Security Networking Platform Data Infrast. Mgmt

Many Stake Holder Solution Framework must support many views Composability ion ce t lu n So erie p Ex sin es s Integrators Fit n en Op End User Organizations s es Industry Groups D Kn om ow ai led n ge Bu Relevancy Product Vendors

Canonicalizing the Views Best Practices & Past Performance COTS Specifications DB Product Y Two Phase Commit Relational Constructs � Row Level Locking � Referential Integrity � ODBC Interface � SQL Interface � JDBC Interface � Triggers � OLE DB Interface � Multiphase converter � Common Criteria Two Phase Commit � Object Storage � Relational Constructs � Row Level Locking � Referential Integrity � ODBC Interface � SQL Interface � JDBC Interface � IDL Interface � Lexicon t en llm i f l Solutions Map Distributed Org � Mobile Force � non-fixed locations � secure communications � concurrent updates � complex data types � unstructured data � central data collection � Open Systems � Fu Solution Profile Scale, Industry Solution Suite Product A Product B v 6. 1 Product C v 2 Platform S Business Drivers Infrastructure Bus. Drivers External Influences DB Standard X, v 2 Two Phase Commit Relational Constructs � Row Level Locking � Referential Integrity � ODBC Interface � SQL Interface � IDL Interface � IT Standards

Why a standardized view Reducing the time, cost, and risk of validating proposed solutions Confidence Level High Cost/time Delta ICH Risk Delta Trade Studies Testing Alone Low Resources (cost & time) “The ICH repository data and analysis methodologies was very helpful in supporting a quick turn around for [Information Assurance] section of COTS security products. Highly detailed ICH technology domain and product evaluation data comprised over 60% of this urgently needed [architecture] report”. Mike Luby, Program Manager, Logicon/PRC Traditional approach ICH advantage

Collaborative Vetting Acceptable outcome of the model? Strength of Evidence 85% Strength of Evidence Decision Basis 50% • Confirm acceptability of the solutions model • Or, if necessary, repropose technical solution and reassess 25% Bi-directional Vendor Claim Functional Testing Integration Testing Implementation Successes Evidence Factors

Purpose of a Shared Repository • To share interoperability knowledge – Features – Functions – Interfaces – Standards – Experiential, 3 rd-party, testing, marketing, benchmarks, etc. • To support the ICH mission • To collaboratively support ICH methodology for ICH members

Implementation Objectives • To facilitate the dynamic storage, management, access and maintenance of ICH repository knowledge • To keep the ICH repository open and extensible • To provide for continual improvement without constant interruption

Component Technologies Addressed • Internet and Network Technologies • Information Assurance Technologies and Secure Information Infrastructure Components • PKI/X 509, PGP, VPN, Firewalls, Digital Signature, Intrusion Detection, Encryption…. . . • DBMSs, XML/XMI, UDDI, Portals, Data Warehousing…. • Development Tools, Application Servers, B 2 B, B 2 C, . . . • Web Servers, COM+, CORBA, EJB, Messaging, JINI, …. • Enterprise Directory: x 5000, LDAP, Active Directory, NDS…. . • Switches, Routers, Wireless, VOIP…. .

Current Implementation • My. SQL-based (for now) • PHP and HTML accessed (for now) • Dream. Weaver Developed • Next Phases

Knowledge Base Data Model

Repository Architecture: Technology Areas

Repository Architecture: Criteria

Repository Architecture: Products

Repository Architecture: Documents

Repository Architecture: Evidence

Repository Architecture: Orgs

Repository Architecture: HR

Implemented Repository Features • Manage, index, search, share documents, reports, other electronic information (“Card Catalogable” information) • Manage ICH “Common Criteria”, – Technology Areas – Criteria – Default Weightings (per Criterion and by Technology Area) • Manage Organizations and Points of Contact

Example: On. Line Documents

Example: On. Line Documents

Example 2: Technology Area Criteria Selection

Example 2: Technology Area Criteria Management

Example 2: Technology Area Viewing

Live Demonstration http: //members. ICHnet. org (Click Link to Open Web Page)

Product Information Entry Workflow

Functional Validation Process

Interoperability Validation Process Industry Indirectly Validates Vendor Claims