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 (?)
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
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 (FEAPMO.gov)
Facilitates alignment of business and technology
Consistent with Industry Best Practices
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
Revised Solution Development Lifecycle focused on COTS acquisition/integration
Mechanism for Sharing and Managing Software Assets Is Key
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
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