Your SlideShare is downloading. ×
Succeeding with Component-Based Architectures: Summary ...
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Succeeding with Component-Based Architectures: Summary ...


Published on

Published in: Technology, Business

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • This paper represents an industry perspective on component-base architecture and the factors that facilitate successful implementation. It complements the paper written by the SAWG on component technologies by focusing on the cultural and process issues surrounding this topic.
  • 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?
  • 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.
  • 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.
  • Lack of common application infrastructure for sharing and plug & play
  • Current enterprise architecture frameworks and lifecycle processes defined in the Federal Government such as FEAF, C4ISR, and TEAF have proven difficult to implement and, as such, have been less effective than originally intended for the reasons given. In addition, because these processes are focused on custom software develop, they do not adequately address the activities necessary to identify potential reuse opportunities nor do they provide guidance on evaluation and acquisition of third party components. Similarly, software development lifecycles, also focused on custom software, do not address activities necessary to effectively identify and incorporate third party components into the solutions being developed for end users. This will be discussed in more detail in the next slide.
  • 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.
  • 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.
  • Update slide to have EA and SDLC processes together and use SDLC space for Define RM linkages – use FEA RM icon in back
  • Agency: New Roles & Responsibilities: Business analysts, Architects New Processes: Evaluation, Assembly/Integration, Control Logic CBD/Provisioning (?)
  • Transcript

    • 1. Succeeding with Component-Based Architectures: Summary & Recommendations An ICH/IAC Enterprise Architecture Out Brief to OMB SAWG and Federal CIO Council AIC John Weiler Executive Director ICH Architecture Resource Center [email_address] 703.768.0400 ICH Architecture Resource Center
    • 2. Agenda
      • Current Issues
      • Concepts & Context
      • Implementation Challenges
      • Business Drivers & Benefits
      • Enablers & Critical Success Factors
      • Recommendations for Transformation
      • Discussion
    • 3. New IT Solution Paradigm Custom Development gives way to Application Assembly Y e s t e r d a y Design, Code & Test
      • Focus on Component Assembly & Integration
      • Model, Evaluate, & Acquire
      • Timeframes are 12-24 weeks!
      • Reliance on industry standards
      • Rate of change is high and accelerating
      • Increased Agility & Adaptability of Enterprise Systems
      T o d a y Architect, Acquire, Integrate Services Oriented Architecture dictates Component-Based SDLC process Software Components & Off the Shelf Products
      • Focus is Software Development
      • Code everything to spec
      • Timeframes 12-24 months
      • Complexity and rate of
      • change manageable (CMM)
      • Technology base Stable
      • Driven by data model &
      • structured methods
    • 4. Component-Based Architecture: Concepts
      • Services Oriented Architecture
        • Way of thinking about systems as set of modular services: business, data, infrastructure
      • Component-based Architectures (CBA)
        • Approach to structuring enterprise solutions that increases modularity and adaptability
        • Focus on component assembly
        • Origins in OO and Component-based Development
        • Required by Federal Enterprise Architecture Program Management Office (
        • Facilitates alignment of business and technology
        • Consistent with Industry Best Practices
    • 5. CBA: Driven by BRM and Implements SRM BRM CBA Application Layer 1 Infrastructure Layer M BRM SRM Appl Service Components Layer 1 Infrastructure Service Components Layer N BRM BRM Business Lines Sub-functions Contribution to Fulfillment Functional Traceability
    • 6. Challenges to EA Transformation
      • Current EA, SDLC & funding processes are not attuned to CBA, and encourage monolithic stove pipes.
      • No consistent COTS evaluation & acquisition process
      • Bureaucracy & culture protect against change
      • The “Legacy Hurdle”
    • 7. Current EA and SDLC Processes Ineffective
      • Based on technology and standards (IDEF, UML)
      • Poor alignment of stakeholder views
      • No cross-agency or cross-application business process refactoring
      • Assume custom S/W development
      • No consistency enforcement of EA artifacts (inter- and intra-agency)
      • Does not produce actionable or comparable output
      • Typically waterfall – not iterative
      • Produces monolithic apps – not modular
      • No consistent COTS evaluation and acquisition process
      • Inhibits use of commercial best practices & SW artifacts
      • Encourage stove-pipe development
      Traditional EA Methods Traditional SDLC Process
    • 8. Business Drivers & Benefits
      • Increased Adaptability & Flexibility
      • Capability Sharing = reduced redundancy
        • Time to Market
        • Lifecycle Cost
        • Risk Mitigation
      • Consistent application of policy & guidance
      • Interoperability and Information Sharing
      • IT Value Chain and Business stakeholder alignment
    • 9. Agile Organizations Require Adaptable Architectures 1980’s and earlier
      • Organization Focus
      • Mainframe centric
      • Monolithic
      • Internal use
      • Business Process Focus
      • Client/Server
      • Monolithic
      • Business-to-business via EDI - file transfer
      • Virtual organizations
      • Distributed Functions
      • Service oriented
      • Componentized
      • E-commerce
      • Real-time
      New Millennium 3rd party service providers Extranet Internet Customers
    • 10. Enablers and Critical Success Factors
      • Enablers
        • Technologies Exist to Enable CBA
        • Commercial components available
        • Standards & Best Practices Exist - Adopt them
        • BRM is the starting point
      • Critical Success Factors
        • Business Driven EA Approach
        • Revised Solution Development Lifecycle focused on COTS acquisition/integration
        • Mechanism for Sharing and Managing Software Assets Is Key
    • 11. OMB’s New SDLC 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 Stake Holders, 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 COTS based on normalized EA vendor submissions.  Define Component Relationships to BRM  Wiring & Activity Diagrams, Component Arch, Data Arch  To-Be architecture ‘blueprints’  Prototype Solution Architecture  Verify ROI, business fit  Validate Sequencing Plan 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
    • 12. Phasing of Recommendations
    • 13. Recommendations for Transformation of EA 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
    • 14. Update EA & SDLC Processes
      • Integrate CBA into Enterprise Architecture & Solutions Development Framework
      Initiation Ongoing OMB Agency
    • 15. Define Reference Model Linkages
      • Agencies Need Assistance in Building Service & Data Architectures from BRM, SRM and DRM
      Initiation Ongoing OMB Agency
    • 16. Adopt Common Information Infrastructure
      • Establish Technical Infrastructure (TRM), Acquire Appropriate Tools, Implement Component Repository
      Initiation Ongoing OMB Agency
    • 17. Define Interoperability Standards
      • Establish Policies, Procedures, Technology Options for Interoperability & Information Sharing Across Agencies
      Initiation Ongoing OMB Agency
    • 18. Reform COTS Selection/Integration Process
      • Establish Common Process for Evaluating & Acquiring COTS/GOTS; Mechanism for Development of Common Components; Certification Process & Repository
      Initiation Ongoing OMB Agency
    • 19. Update Policy & Drive Organizational Change
      • Organizational Change is Difficult: Treat Transformation as Change Management Project
      Initiation Ongoing OMB Agency
    • 20. Establish Solution Architecture and Component Integration Lab
      • Mission
      • Foster Use of Common Services/Components Across Agencies
      CBA Best Practices, Business Process Patterns, Linkages to Reference Models Build consensus on Process & Data Factoring COTS/GOTS Evaluation, Common Components, Certification of Components
    • 21. ICH – Federal Engagements
      • DARPA*
      • DEA**
      • Education *
      • EPA**
      • HUD***
      • OSD Health Affairs***
      • Intel Community *
      • OSD DUSD ***
      • DISA**
      • BEP **
      • INS ***
      • TSA *
      • AF XI **
      • Navy **
      • NIMA *
      • US Mint **
      • FEMA **
      • GSA ***
      • Federal CIO Council *
      • Treasury HQ *
      • State Dept.**
      • ITIPs **
      • VA **
      * Developing Proposal for Client ** Proposal submitted, awaiting funds *** Proposal Accepted, In Contracts
    • 22. ICH – The Offerings Govt Certified, on GSA Schedule
      • Enterprise Architecture Focus
        • Component-Base Architecture Frameworks (aligns business with technology)
        • ICH Performance Metric Solutions
        • Readiness Assessment
        • EA Process Remediation
      • Capital Planning Focus
        • A 11 – 300 Advisory and Assistance
      • Reference Model Management
        • EA as the Integrator
      • EA Repository
        • FEAMS Open Source
        • DARPA DCAM
    • 23. ICH GSA Schedule Architecture Assurance Services Deliverables