Practice: Component Based Software Architecture |
This practice defines a system's functional architecture by breaking the system up into a number of collaborating components. It focuses on identifying the major abstractions of the system and making decisions on how the system will be built to ensure resilience and maintainability.
Purpose
This practice improves productivity by accelerating the team's comprehension of the system and improving team communication. It decreases the amount of time a team member needs to find the correct location in the system to make a change. It increases quality by clarifying which system elements need to be retested after a change is made. This practice reduces time to market by identifying components with well defined interfaces that can be developed in parallel, reused, and outsourced. Since the required functionality of each part of the system is clear, you are able to assign the best possible resources to design and develop each architectural element. Adopting this practice improves predictability and project oversight. A component based architecture helps a project manager scope the work needed and properly plan, coordinate and track the efforts of team members. This practice results in a consistent system design, as it helps bring similar design needs to the surface.
Main Description
The component based architecture practice helps teams developing large or complex systems manage the complexity of the design and produce a system that is maintainable in the future. This practice is most beneficial on projects where the team or system is large or complex. It is useful in companies where systems live for decades, or where you expect new team members to participate in the development or maintenance of the system over time. This practice is especially useful when there are many variants of the system. For example, this practice helps in the design a system for multiple target environments that require separate design architectures. Distributed, outsourced, or globally dispersed teams benefit from this practice. These teams require a more formal means of communicating the dependencies between the parts of the system each location is developing.
How to read this practice
Before reading this practice, you should familiarize yourself with the enablement materials. Begin reading this practice by reviewing these key concepts: Software Architecture Component Next, review the work products and tasks. When a work product or task refers to a key concept or more detailed guidance, review those elements at that time, or save the detailed reading for last. Use templates and checklists associated with the work products to guide you as you complete and evaluate them. Use measurements to guide you on assessing how well you are following the practice.
Additional Information
For more information on this practice, see the practice resource page on IBM® DeveloperWorks®.
Relationships
Content References | How to Adopt the Component Software Architecture Practice Key Concepts Architecturally Significant Requirements Architectural Views and Viewpoints Component Executable Architecture Software Architecture Architectural Mechanism Work Products Architectural Decisions Component Model Component Specification [Technical Architecture] Architecture Overview Tasks Detail Component Model Outline Component Model Envision the Architecture Guidance Tool Mentors Defining the Implementation Model Using Rational Software Development Platform Identifying Design Mechanisms Using Rational Software Development Platform Outlining the Component Model Using Rational Software Development Platform. Guidelines Abstract Away Complexity Entity-Control-Boundary Pattern Layering Representing Interfaces to External Systems Developing a Good Architecture
Inputs | [Technical Design] [Technical Specification]
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.