Enabling Project Success Through an Architecture Baseline

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

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?

First, you’ll consider a scenario that illustrates a proof of concept, prototype, architecture baseline, and pilot to understand the differences. Then, you’ll look at how the Unified Process defines an architecture baseline. Next, I’ll discuss the benefits of doing an architecture baseline. Finally, as I always do in my articles, I’ll ask you to consider how you might use an architecture baseline to position your next project for success.

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.

Illustrative Scenario

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.

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[1] 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.

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

There are many benefits associated with an architecture baseline software development activity whether or not it is done with the Unified Process.

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.

Summary

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!

Reference