570 likes | 1.07k Views
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”.
E N D
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... 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
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
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
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, FAROMB Circulars A119 & A130, 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 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
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
Many Stake HolderSolution Framework must support many views Product Vendors Composability Integrators Business Fit SolutionExperience End User Organizations Openness DomainKnowledge Relevancy Industry Groups
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
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
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
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
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
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
Current Implementation • MySQL-based (for now) • PHP and HTML accessed (for now) • DreamWeaver Developed • Next Phases
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
Live Demonstration http://members.ICHnet.org (Click Link to Open Web Page)
Interoperability Validation ProcessIndustry Indirectly Validates Vendor Claims