Roadmap: How to Adopt the Component Software Architecture Practice
This roadmap describes how to adopt the Component Software Architecture Practice
Main Description

Getting Started

Educate your team about the Component Base Software Architecture practice. Have the team review the material in this practice. See ‘How to read this practice' in Component Based Software Architecture. Ensure that key stakeholders know how to create or understand how to read component models.

Perform a gap analysis between your current practices and the newly proposed one. See Task: Envision the Architecture, Task: Outline Component Model, and Task: Detail Component Model. Prioritize the adoption of elements of the new practice based on which elements provide the most immediate value. In particular, familiarize yourself with the Artifact: Component Model. Focus on problem areas in your current organization. Document and communicate any plans for incremental adoption. Identify extension points and extend this practice to reflect important requirements and constraints in your organization.

Select a modeling language (see Visual Modeling) and modeling tool, and where practical, standardize on them. Define standards for use of the tool, such as how to organize it and how to extract relevant diagrams into a reviewable artifact. Identify mandatory and optional diagrams. Educate the team on how to create, update, and review models using the tool.

Take inventory of your existing artifacts, models, and templates. Decide which you want to continue using and which you want to replace or adapt to fit the elements of this practice. Publish relevant templates and examples to the team.

Select a project to start applying the new practice. This pilot project should be visible and risky enough to properly adopt this practice. Throughout the project, periodically review the effectiveness of the practice and make adjustments. Eliminate steps or artifacts that do not provide value. Document your adjustments for future projects.

Common Pitfalls

Avoid trying to define the entire architecture before building it. This often leads to analysis paralysis, where a great deal of time is spent discussing and reviewing decisions made from a purely intellectual perspective. This is also known as "guessing". Build parts of the architecture that are understood and agreed upon, and make further decisions based on the results of the Executable Architecture instead of predicting what the architecture will do. The more complex an architecture is, the more important it is to build and enhance the executable architecture early and often so decisions can be made based on concrete, real-world information.
More Information