John B. will talk about current situation in many Agency’s and What it is & how it fits within FEA models John Weiler will discuss some of the hurdles with adopting CBA and What is moving us to CBA and what do we get from it? Dave will What helps us overcome these inhibitors and be successful with CBA? What do agencies/CIOs need to do to embark on CBA voyage?
We’re all familiar with the problems: Many, if not most, projects are failing – they don’t meet budget, they’re delayed, they don’t meet user expectation. Once the systems are deployed, if they ever get that far, they’re tough to change or evolve and difficult to integrate with other systems, A recent e-commerce project the system used at least 5 different integration techniques IT shops are spending a majority of their budget maintaining these systems as opposed to providing new functionality to support changing needs. As a result, many of the legacy systems don’t support the current Agency mission or won’t in the future. COTS/Component selection process is broken, and not driven by business nor interoperability requirements.
There is also a paradigm shift occurring in IT solutions. The focus in the past has been on custom software development and that was effective given the characteristics of the day. There weren’t a lot of components out there to use, the environment wasn’t changing that fast and technology was relatively stable. Today, we’re moving to much more of a focus on application assembly. This has been driven by the Internet and the need to evolve in “web-time”. The good news is that the technologies are here to support it and there are a wealth components available in the market. And if we’re moving to components that means CBA by definition. The question then becomes how do you lay the foundation? That’s were Service Oriented Architectures comes in. We’ll talk about SOA more on the following slides.
Before moving too far forward, let’s level set on two concepts Service Oriented Architecture (SOA) and Component-based Architecture (CBA). SOA is a way of thinking about systems (of any kind) or modules in terms of the services it provides. CBA can be used to realize or implement an SOA. CBA, on the other hand, is an approach for looking at architecture at all levels in terms of the groupings or “chunks” and the services or interfaces they provide. CBA has grown out of object oriented development and component-based development as an approach that answered questions around integration of non-OO systems or services.
Systems have evolved over time. In the 80s large systems were stove-piped which resulted in “islands of information”. In an effort to automate processes or make them more efficient, the focus shifted but the result was still systems that didn’t necessarily integrate. Collaboration between processes was still not effective. Today, the move is towards services. By enabling “Just-in-time” applications, organizations are much more agile and adaptable.
We’ve all seen the FEA models and work continues on these but we want to give a context for CBA. CBA is the mechanism for realizing the SRM.
Lack of common application infrastructure for sharing and plug & play
This slide needs to talk to vision of eGov, processes working across agencies and what that means: need data sharing,interoperability, etc. In order import a product into the country – need to involve Customs, and some large # of other agencies. Portals to blast info to all required folks. Components to minimize redundancy/maximize commonality
The FEA models are organized very much around Services but it is also business driven. The BRM describes business lines and the functions and sub-functions or segments that they comprise. These segments use services defined in the SRM that to support their mission. These services are often used by multiple business functions. CBA provides the mechanism for grouping and realizing these services in an effective manner. By driving the architecture in this manner, the CBA, like the FEA Models, is business driven and shows direct contribution of components to agency mission fulfillment.
Do a layered diagram
Update slide to have EA and SDLC processes together and use SDLC space for Define RM linkages – use FEA RM icon in back
This model is based on NASCIO National Software Component Exchange (NSCE). Repository should provide common view to architect: candidate components that meet the search criteria can come from agency, federal or commercial sources. Repository should also be able to manage the inventory of component licenses. Certification is important (like Underwriters Laboratory seal)
Traditional software development lifecycles have focused on custom software development. As such, little or no attention was paid to the specification, evaluation, acquisition and integration of components from third parties. The IAC is helping OMB to define a new solution development life cycle that is much more iterative than past life cycles and provides a greater focus on integration of COTS/GOTS components. In particular, activities need to be included as follows: Discovery: Identify potential components that may be useful in the solution, Requirements: Define requirements of components and the evaluation criteria to be used during acquisition, Architecture: Refining the initial architecture design based on available COTS/GOTS, Acquisition: Evaluating candidate components for applicability within the architecture Integration: Prototyping solutions and verifying that components provide the services as advertised, and Execution: Deployment and monitoring components for Service Level Agreement adherence.
SecurE-Biz Conf 4-1-..
Using the SRM to Succeed with Component-Based Architectures <ul><li>Dave Mayo Vice President Everware </li></ul><ul><li>[email_address] </li></ul><ul><li>John Weiler Executive Director Interoperability Clearinghouse </li></ul><ul><li>[email_address] </li></ul><ul><li>April 1, 2003 </li></ul>
Agenda <ul><li>Current IT Issues </li></ul><ul><li>CBA: Concepts & Context </li></ul><ul><li>Business Drivers & Benefits </li></ul><ul><li>FEA Service/Component Reference Model </li></ul><ul><li>Enablers & Critical Success Factors </li></ul><ul><li>Recommendations for Transformation </li></ul><ul><li>Discussion </li></ul>
Current Issues in Federal IT <ul><li>Most IT development projects fail or never deploy </li></ul><ul><li>Many Federal EA methods are neither business aligned nor actionable. </li></ul><ul><li>Legacy systems inflexible, stove-piped </li></ul><ul><li>Many systems not designed for interoperability </li></ul><ul><li>OMB seeks to establish a common EA framework </li></ul><ul><li>OMB has directed an Component Architecture Approach </li></ul>
New IT Solution Paradigm Custom Development gives way to Application Assembly Y e s t e r d a y Design, Code & Test <ul><li>Focus on Component Assembly & Integration </li></ul><ul><li>Model, Evaluate, & Acquire </li></ul><ul><li>Timeframes are 12-24 weeks! </li></ul><ul><li>Reliance on industry standards </li></ul><ul><li>Rate of change is high and accelerating </li></ul><ul><li>Increased Agility & Adaptability of Enterprise Systems </li></ul>T o d a y Architect, Acquire, Integrate Services Oriented Architecture dictates Component-Based SDLC process Software Components & Off the Shelf Products <ul><li>Focus is Software Development </li></ul><ul><li>Code everything to spec </li></ul><ul><li>Timeframes 12-24 months </li></ul><ul><li>Complexity and rate of </li></ul><ul><li>change manageable (CMM) </li></ul><ul><li>Technology base Stable </li></ul><ul><li>Driven by data model & </li></ul><ul><li>structured methods </li></ul>
Component-Based Architecture: Concepts <ul><li>Services Oriented Architecture </li></ul><ul><ul><li>Way of thinking about systems as set of modular services: business, data, infrastructure </li></ul></ul><ul><li>CBA </li></ul><ul><ul><li>Modular EA Process for Value Chain Alignment </li></ul></ul><ul><ul><li>Approach to structuring enterprise solutions </li></ul></ul><ul><ul><li>Focus on component assembly </li></ul></ul><ul><ul><li>Origins in OO and CBD </li></ul></ul><ul><ul><li>Fits within Federal Framework of Reference Models </li></ul></ul><ul><ul><li>Facilitates alignment of business with technology (via SRM) </li></ul></ul><ul><ul><li>A CSF for OMB FEA-PMO, and FEAMS </li></ul></ul>
Business Drivers & Benefits <ul><li>Increased Modularity, Adaptability & Flexibility </li></ul><ul><li>Capability Sharing = reduced redundancy </li></ul><ul><ul><li>Time to Market </li></ul></ul><ul><ul><li>Lifecycle Cost </li></ul></ul><ul><ul><li>Risk Mitigation </li></ul></ul><ul><li>Consistent application of policy & guidance </li></ul><ul><li>Interoperability and Information Sharing </li></ul><ul><li>IT Value Chain and Business stakeholder alignment </li></ul><ul><li>Enables establishment of common EA terms and specifications or “building codes” </li></ul>
Agile Organizations Require Adaptable Architectures 1980’s and earlier <ul><li>Organization Focus </li></ul><ul><li>Mainframe centric </li></ul><ul><li>Monolithic </li></ul><ul><li>Internal use </li></ul>1990’s <ul><li>Business Process Focus </li></ul><ul><li>Client/Server </li></ul><ul><li>Monolithic </li></ul><ul><li>Business-to-business via EDI - file transfer </li></ul><ul><li>Virtual organizations </li></ul><ul><li>Distributed Functions </li></ul><ul><li>Service oriented </li></ul><ul><li>Componentized </li></ul><ul><li>E-commerce </li></ul><ul><li>Real-time </li></ul>Source: Butler Group New Millennium 3rd party service providers Extranet Internet Customers
Federal Enterprise Architecture (FEA): Reference Models Business Reference Model (BRM) <ul><li>Lines of Business </li></ul><ul><li>Agencies, Customers, Partners </li></ul>Service Component Reference Model (SRM) <ul><li>Capabilities and Functionality </li></ul><ul><li>Services and Access Channels </li></ul>Technical Reference Model (TRM) <ul><li>IT Services </li></ul><ul><li>Standards </li></ul>Data Reference Model (DRM) <ul><li>Business-focused data standardization </li></ul><ul><li>Cross-Agency Information exchanges </li></ul>Business-Driven Approach Performance Reference Model (PRM) <ul><li>Government-wide Performance Measures & Outcomes </li></ul><ul><li>Line of Business-Specific Performance Measures & Outcomes </li></ul>
FEA Service Component Reference Model Customer Services Process Automation Services Business Management Services Digital Asset Services Business Analytical Services Back Office Services Common Services Cross-Cutting Service Areas (i.e., Search, Security) Service Types Service Layers Components Performance Measures Business Process Access and Delivery Channels Conceptual
Services/Components Reference Model <ul><li>Identify & Classify Horizontal & Vertical Service Components </li></ul><ul><li>Base of Common Terminology and Structure for Services & Components </li></ul><ul><li>Source of Information for Enterprise Architects to Align Service Oriented Architectures </li></ul><ul><li>Vehicle for Agencies to Collaborate on Service Definition and Development </li></ul><ul><li>Mechanism for Agencies to Locate Candidate Components for Use/Reuse </li></ul>
Exploiting Service/Component Reference Model Component Repository Identify Collaboration Partners Consume Service Component Align Service Definitions Register Service Component Enterprise Architect Application Designer CIO Council SAWG Set Up Classification & Mappings SRM / FEAMS
Common Components Enable Cross-agency Interoperability & Information Sharing Agency A Agency B Access Channel Agency C Office Bureau Office Business Community Citizen Dept. Business Segment 1 Business Segment 2 Business Segment 3 Business Segment 4 Gov. Analyst
CBA: Driven by BRM and Implements SRM BRM CBA CBA Layer 1 CBA Layer M BRM SRM Service Layer 1 Service Layer N BRM BRM Business Lines Sub-functions Contribution to Fulfillment Functional Traceability
Service Architecture Layering BRM Platform Components Business Subdomain Components Application Specific Components Common Business Components Infrastructure Components Business Infrastructure
Enablers and Critical Success Factors <ul><li>Enablers </li></ul><ul><ul><li>Technologies Exist to Enable CBA </li></ul></ul><ul><ul><li>Commercial components available </li></ul></ul><ul><ul><li>Standards & Best Practices Exist - Adopt them </li></ul></ul><ul><ul><li>BRM/SRM are the starting point </li></ul></ul><ul><li>Critical Success Factors </li></ul><ul><ul><li>Value Chain Driven EA Approach </li></ul></ul><ul><ul><li>Revised Solution Development Lifecycle focused on COTS/GOTS acquisition & integration </li></ul></ul><ul><ul><li>IT Portfolio Management </li></ul></ul><ul><ul><li>Mechanism for sharing and reusing software assets and components </li></ul></ul>
IAC Recommendations for Transformation to CBA Define Ref. Model Linkages Reform COTS Process Update Policy & Drive Cultural Change Update EA & SDLC Processes Adopt Common Infrastructure Establish Solution Center Interoperability Define Interop. Standards
Application Development Group Commercial Catalog Agency Specific Catalog Specify Find Evaluate Consume Publish Publish Federal-Wide Catalog User View Component Repository Repository: Sharing & Managing Software Assets Build Productize
OMB’s Draft SDLC needs to be vetted with industry Incorporates CBA in an Iterative Process Artifacts and Activities Performance Measures, Objectives, Outcomes (PRM) Business Objectives (BRM) Funding, Partnering Strategies Acquisition Integration Identify Best Practices, technology Enablers, and Components Existing Stakeholders, Business Processes, and Workflows Existing Delivery and Access Channels (Portfolio) Must Have Functions, Features, and Info Exchanges Short and Long-Term Requirements Assessment of As-is state: Gap Analysis Define/Align Service Components Component Common Criteria, SLA Select & Acquire GOTS/COTS Components Define Component Relationships to BRM/SRM Wiring & Activity Diagrams, Component Arch, Data Arch To-Be architecture ‘blueprints’ Prototype Solution Architecture Verify ROI, business fit Conduct Integration Testing Iterative Development Value-Based Releases Understanding the Business Knowing What’s Possible Model the Business Define the Gaps Develop the “ Blueprints” Obtain Components Assemble the Components Execution Deploy Manage re-Baseline Execute & Deploy Discovery Requirements Strategy Architecture
Establish CBA Solution Center <ul><li>Foster Use of Common Services/Components Across Agencies </li></ul>CBA Best Practices, Business Process Patterns, Linkages to Reference Models Build Consensus on Process & Data Factoring COTS/GOTS Evaluation, Common Components, Certification of Components
Contact Information <ul><li>For more information about IAC, go to </li></ul><ul><li>www.iaconline.org </li></ul><ul><li>For more information about the IAC EA SIG, please contact Kay Cederoth at: </li></ul><ul><li>[email_address] </li></ul><ul><li>For more information on each of the </li></ul><ul><li>IAC EA SIG White Papers, go to: </li></ul><ul><li>http://www.ichnet.org/IAC_EA.htm </li></ul>