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:

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