Creating Solution Architecture Templates

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

2. 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... No body of knowledge from which to leverage lessons learned Overwhelmed? Ill-equipped? Behind the market? Over-sold? At risk? No architecture modeling tools for assessing risks or composability

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

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

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

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

7. 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, FAROMB Circulars A119 & A130, S.803, FEAPMO • Provide “clearinghouse” of reusable artifacts and supporting research

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

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

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

11. ICH EA Alignment Framework Enterprise Architecture Drivers /Inhibiters Missions, Goals and Objectives Revenue Enhancement/Cost Reduction Industry Shifts, Obsolescence,Recent Investments Organizational Change Considerations Budget Legislative Directives Mandates, Regulations Enterprise Architecture Business Driver – Process Mapping Business Process Layer: 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: 1. Function/Feature, 2. Performance Characteristic 3. Performance Measure Application Standards & Policies 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

12. Many Stake HolderSolution Framework must support many views Product Vendors Composability Integrators Business Fit SolutionExperience End User Organizations Openness DomainKnowledge Relevancy Industry Groups

13. Canonicalizing the Views Best Practices & Past Performance COTS Specifications Solution Profile Scale, Industry Solution Suite Product A Product B v6.1 Product C v2 Platform S 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 Lexicon Solutions Map • Distributed Org • Mobile Force • non-fixed locations • secure communications • concurrent updates • complex data types • unstructured data • central data collection • Open Systems Business Drivers Fulfillment Infrastructure Bus. Drivers External Influences Common Criteria • Two Phase Commit • Object Storage • Relational Constructs • Row Level Locking • Referential Integrity • ODBC Interface • SQL Interface • JDBC Interface • IDL Interface DB Standard X, v2 Two Phase Commit • Relational Constructs • Row Level Locking • Referential Integrity • ODBC Interface • SQL Interface • IDL Interface IT Standards

14. High Cost/time Delta ICH Risk Delta Confidence Level Trade Studies Testing Alone Low Resources (cost & time) Traditional approach ICH advantage Why a standardized viewReducing the time, cost, and risk of validating proposed solutions “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

15. Collaborative Vetting Acceptable outcome of the model? Strength of Evidence Decision Basis 85% 50% Strength of Evidence 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

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

17. 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 Implementation Objectives

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

19. Current Implementation • MySQL-based (for now) • PHP and HTML accessed (for now) • DreamWeaver Developed • Next Phases

20. Knowledge Base Data Model

21. Repository Architecture: Technology Areas

22. Repository Architecture: Criteria

23. Repository Architecture: Products

24. Repository Architecture: Documents

25. Repository Architecture: Evidence

26. Repository Architecture: Orgs

27. Repository Architecture: HR

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

29. Example: OnLine Documents

30. Example: OnLine Documents

31. Example 2: Technology Area Criteria Selection

32. Example 2: Technology Area Criteria Management

33. Example 2: Technology Area Viewing

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

35. Product Information Entry Workflow

36. Functional Validation Process

37. Interoperability Validation ProcessIndustry Indirectly Validates Vendor Claims