Enabling Project Success Through an Architecture Baseline
Enabling Project Success Through an Architecture Baseline
Although the architecture baseline software development activity as defined in the Unified Process has been around for a long time, I don't find it used as often as I would like.
In contrast, you often hear about proof of concepts, prototypes, and pilots. How does an architecture baseline differ from these more common software development activities? What are the benefits of doing an architecture baseline?
What an Architecture Baseline Is and Is Not
Although you have probably participated in software development activities that were called proof of concepts, pilots, and prototypes, I find that individuals and organizations define these differently. The following scenario will provide working definitions for these activities. In contrast, an architecture baseline is a more formally defined practice and I will use the standard definition.
Consider a scenario that illustrates how a proof of concept, prototype, architecture baseline, and pilot might be used to inform decisions and further the design. This will be helpful to illustrate what an architecture baseline is and is not.
First, a team considers how a portal solution might be used to create a unified desktop for representatives serving customers in a contact center. A proof of concept activity is done with a particular vendor to determine the suitability of this solution and of the vendor. The proof of concept is successful and the team decides to move forward. The code developed in the proof of concept assists in learning about the portal product, but is not used going forward.
Next, a prototype of the user interface design for the unified desktop is created and tested on actual users. This prototype is a veneer of what the system might look like when completed, but is not actually functional. Valuable end-user feedback is gained from the prototype. Several iterations of the prototype are done until the usability goals of the system are met by the design.
In parallel with the user interface prototype, an architecture baseline is created to realize the architecture for the unified desktop portal. The baseline creates a small working example to illustrate the architecturally significant scenarios of combining the account management and billing applications on the desktop, authentication, and content management. This solution architecture will be the basis for development and builds upon the learning, but not actual code, from the proof of concept. Performance testing is done on the architecture baseline components to ensure that non-functional requirements will be met.
Once the user interface prototype and architecture baseline is completed, the development team creates an increment that is released to production and piloted with the actual contact center representatives. This increment allows the representative to log on to the portal, view content, and service customers through the account management and billing portlets.
The table in Figure 1 describes the purpose and sample application of these valuable software development activities that inform decisions and further designs.
|Software Development Activity||Definition and Purpose||Example|
|Proof of concept||To create a small working example for the purposes of learning about the application of a particular technology to solve a particular problem.||A proof of concept to understand the capabilities of a vendor's portal product to improve the productivity of contact center representatives.|
|Prototype||A small example (working or not) to test a design being considered for implementation.||A prototype of the portal user interface that will be part of a usability test to gain feedback on the design from actual end users.|
|Architecture Baseline||A small working example of the candidate architecture to realize the major architecture decisions and to illustrate architecturally significant scenarios. This will be used as the basis for development.||A reference application that illustrates the authentication, content management, and application integration solutions for the unified desktop.|
|Pilot||A fully working example of a small portion of the system that is implemented in production with a small set of users.||A pilot implementation of the unified desktop portal to a small group of contact center employees.|
Figure 1: Software Development Activities and Examples
From the example in Figure 1, you can see a few differences among an architecture baseline and a proof of concept, prototype, and pilot. Whereas a proof of concept creates throw-away code to evaluate a solution and/or vendor, an architecture baseline creates code assets that become the basis for subsequent development. Although a prototype creates an iteration (working or not) of what a system might look like, an architecture baseline creates the inner guts of what a system will look like. A pilot is a first release of a system in production to a small set of users, and the architecture baseline creates the architecture underpinnings of the system that is needed to create the first release.
Architecture Baseline Defined
Now that you have compared the less familiar architecture baseline with the more common proof of concept, prototype, and pilot, you can examine a standard definition of an architecture baseline.
We have to thank the Unified Process or UP for defining the architecture baseline software development activity. Although this activity is key part of UP, it doesn't preclude its use in other development methodologies by any means.
An architecture baseline is defined as a partial implementation of the system that validates the candidate architecture and serves as a basis for subsequent development.
What Is a Candidate Architecture?
You might ask, what is a candidate architecture? The Unified Process is use-case driven. The candidate architecture is the contemplated solution that satisfies these functional use cases and non-functional requirements.
Architects derive architecturally significant scenarios from the candidate architecture to be proven in the baseline effort. Scenarios are chosen for the baseline because they expose more risk to the project. This risk may be due to the introduction of a new technology, integration of a new back end system, or utilization of new product features or standards.
Once the architecture baseline is complete, there is no longer a candidate architecture. Rather, there are code assets that realize the candidate architecture and become the basis for future development.
Page 1 of 2