Enabling Project Success Through an Architecture Baseline
The Elaboration Phase
The architecture baseline occurs in the Elaboration phase of the UP; it is designed to identify and mitigate risks early in the lifecycle of the project. The architecture baseline chooses to implement the foundational pieces of the system so that the greatest risks are addressed first.
The Unified Process is an iterative and incremental process designed to produce working software in each increment. The architecture baseline is the first increment of the system and is sometimes called iteration zero.
Architecture Baseline Benefits
Identify and Mitigate Risks
The architecture baseline assists in understanding and mitigating risks early in the project life cycle. This provides 20/20 vision to a project in terms of the solution it is putting in place and assists it in creating a realistic project schedule to implement the solution.
Enable Accurate Estimates
Once an architecture baseline is complete, confidence in the solution architecture will increase by all project stakeholders including architects, project managers, business analysts, and developers. With a solid architecture in place, more precise estimates can be done for delivering new features in future increments.
Ensure Compliance with Standards
Each organization has certain enterprise architecture and software governance standards that projects must comply with. The architecture baseline should be done in accordance with these standards. If new products or deviations from standards are needed in the candidate architecture to satisfy the use cases, this will be identified early and support organizations can be included in the baseline effort. With compliance out of the way early in the project, the team can proceed without facing hurdles later.
Clearly Defined Roles and Responsibilities
The architecture baseline activity might produce cookbooks for subsequent development using the solution architecture. These cookbooks can define roles and responsibilities needed to deliver upon the architecture. Following the baseline, it should be clear what type of development activities would be suitable for on and offshore development teams.
Putting the Architecture Baseline to Work
Whether or not your team is using the Unified Process, an architecture baseline may be used to establish the architecture for your project and to realize the many benefits.
In a waterfall development methodology, an architecture baseline could be included at the end of the design phase or at the beginning of the build phase.
In an agile development scenario, an architecture baseline could be included as the first increment to help define the sandbox architecture for which the team will begin delivering working software in subsequent increments.
If you are using the Unified Process, it is likely that you are already putting architecture baselines to work because they are a key part of the Elaboration Phase.
You learned that an architecture baseline is a valuable software development activity, not as well understood or used as the more common proof of concept, prototype, and pilot. However, the architecture baseline activity has a more robust and commonly accepted definition than its cousins because it is a part of the Unified Process.
You examined how the Unified Process defines the architecture baseline as a partial implementation of the system to validate the candidate architecture and mitigate risks early in the project lifecycle. You also looked at the many benefits of doing an architecture baseline such as identifying and mitigating risks, enabling accurate estimates, ensuring compliance with standards, and articulating clear roles and responsibilities for development.
Finally, you saw how an architecture baseline is a valuable software development activity that may be incorporated into even waterfall or agile software development methodologies.
Have you participated in a proof of concept, prototype, or pilot software development activity? How about an architecture baseline? If not, consider how you might include this valuable activity in your next project to enable its success through identifying and mitigating architecture risks early in the project lifecycle. The rest is up to you!
About the Author
Jeff Ryan is an enterprise architect with twenty-four years' experience architecting and implementing thoughtful solutions to business problems. He has used architecture baselines extensively to establish the architecture for several successful projects.
This article is Jeff's 25th for developer.com. Click here for a list of previous articles on enterprise architecture, SOA, Java, XML, and XSLT.
Page 2 of 2