Level: Introductory Mikko Kontio (mikko.kontio@softera.fi), Production manager, Softera
06 Apr 2005 Enough about the how of designing a software architecture! This month, Mikko explains why you would want to do it in the first place. Find out how the software architecture benefits different phases of the development process, as well as various end-product stakeholders.
For the past several months I've focused on designing a software
architecture. I've talked about requirements gathering, documentation, integration with the development process, and more. One thing I haven't discussed, however, is the benefits of the software architecture. So, in this month's column I'll focus more on the why than the how of designing a software architecture.
I'll explain the benefits of the software architecture in two ways: first with regard to how it works with the overall design and development process, and second with regard to how it benefits various stakeholders in the final product, including investors, managers, and the development team.
The article concludes with a simple overview of these benefits, which you can use as a guide for integrating architectural design into your company's development process.
I'll start with a look at how the software architecture positively impacts a development project at different design phases. As in previous articles, I'll use the Rational Unified Process® (RUP®) design process as a framework. I'll add an additional phase, however; the phase before the project begins.
Before the project begins
If your company has an established architectural process or product-line architecture, it serves as a framework for the project before it even begins. The benefits of having architectural guidelines or a product line architecture in place before the project's inception are threefold:
- First, the architectures serve as a guideline for planning and scheduling projects. Having some basic services defined and in place (for example, a single-sign-on service) makes building new services a lot faster.
- Second, the architectural guidelines provide a framework for discussing possibilities such as open interfaces (APIs), mobile usage, and open source components or software. The architecture gives your company a better foundation for proceeding with development.
- And third, the architecture serves as a framework for discussion with subcontractors. Having set architectural guidelines makes their offers similar and easier to manage and compare.
At the inception phase
As you will recall, it is at the inception phase that the requirements specification is started and the architectural candidates designed. The basic idea of the inception phase is to get as good an understanding of the project as possible. After the inception phase the project and steering groups should have a solid idea of the project. At that point it is easier to decide whether to proceed to the next phase or end the project.
The architectural design is very helpful when it comes to estimating how much work the project will require. After you've done that, it is easy to plan the project timetable and calculate its overall cost. If the expenses are too high you can design an alternative architecture.
If the project contains requirements that are considered risky, you can test them by building prototypes or proof of concepts. In some cases you might choose to test the whole architecture by building a simple prototype which, for example, contains all the layers of the
designed architecture. If building the prototype is easy and requires about the estimated time, then you know that the whole system and its plans are on solid ground. The prototype and documentation also serve as a working example for the designers and developers.
Using a standard architecture also facilitates reuse. For example, the architect will likely know what components have been built and utilized for other projects in the company and can easily see where they might fit into the current one. Reusing existing components (or even best
practices) can speed up the development process, saving time and money.
Perhaps most importantly at the inception phase, the architecture provides a framework for communication among project stakeholders. In some cases, the customer doesn't really understand use cases or requirements documentation, so the architectural drawings are the first artifacts they can really talk about.
At the elaboration phase
At the elaboration phase the requirements are finished and the focus shifts to the actual design of the system. In this phase you begin to see the benefits of the work that went into planning the architecture in the inception phase.
The software architecture serves as a framework for elaboration, both suggesting and limiting the direction the design should go in. One of its primary benefits is that it prevents too much diversity in design decisions. If you present the same problem to two software designers, each will come up with a different solution, and this is also true of coders. A well-documented software architecture accompanied with a set of design guidelines helps to ensure project consistency at all levels.
Having an architectural design in place lets you manage even very large projects in a consistent and reliable way, regardless of whether you're designing a single system or a product family.
At the construction phase
At the construction phase the detailed designing is done and it is time to implement the system. Having a set of implementation details in place ensures a smoother implementation process. The presence of the architecture at earlier phases will have ensured some consistency in the implementation and design details, which in turn will make it easier to test different parts of the system.
The architecture also makes it easier for the project manager to plan for the simultaneous implementation of different parts of the system. Components that communicate through interfaces can be easily implemented at the same time by different teams or developers.
At the transition phase
At the transition phase most of the design and development teams' work is done. In this final phase the software or system is transferred to the client.
The architecture will be most helpful at this phase if and when the system needs to be integrated into other systems. Designing the integration is easy if the system's interfaces and structures can be easily found and understood.
The architectural information serves as a framework for explaining the system to the client. It serves as a starting point for sales material as well as presentation material for seminars, conferences, and other marketing environments.
Benefits to stakeholders
In addition to providing a reliable backbone for the overall development process, the software architecture can be a boon to various project stakeholders. Knowing how the software architecture will benefit individual stakeholders makes it an easier sell for everyone. In the sections that follow, I'll explain how the software architecture could serve as a valuable interface for your company's management and development teams, as well as for customers and third-parties.
The management team
The primary benefit of the software architecture, in any capacity and for any stakeholder, is that it works as a way to communicate. It acts as an interface between different parts of the project and different members of the project team, including the clients and third-parties.
For management, the architecture can provide a relatively simple view into a potentially complex system. Business facets can be isolated, analyzed, and discussed without the need to discuss technological issues. Roadmaps can be drawn up based on such discussion, and decisions made. For one example, the overview of the software architecture is a much more accurate tool than use cases alone for estimating the cost of a project, both in terms of money and of time.
The software architect should also be a good ally to the management team, providing an overview of the system technology and its business effects.
The development team
Obviously, it is the development team that stands to benefit the most from a well-made software architecture. The architecture works as a project framework and guidebook throughout the development process. It gives the team an overview of the project from the beginning, and a starting point for elaboration. Someone, the architect, has already dug out all the important features and drawn the overall structure of the system.
With the architecture in place, the team can easily divide up different parts or components of the system. These parts can then be designed and implemented simultaneously, in an
organized fashion. In fact, a smart architect will probably have made it a requirement that system components be developed simultaneously, and planned out how it would happen well before the construction phase.
Clients
A well-designed architecture acts as a guarantee for the client that the software also has been well designed and implemented. The documentation of the architecture assures the client that when he needs detailed documentation (or product overviews) he can expect quality material. If the client is concerned about integration or scalability issues he will be particularly reassured by the presence of a solid software architecture and equally well-thought-out
documentation.
Third parties
Your company might use a third-party company to resell, integrate, operate, or maintain your end products, or train potential clients or users in its use. For any of these purposes you will have to provide the third party with excellent background information, and possibly training. As always, the software architecture serves as an excellent starting point for any of these purposes.
A benefits checklist
As promised, this month's column concludes with a simple checklist of the benefits of the software architecture at each phase of the design process and for various project stakeholders.
Benefits in the development process
Here's an overview of the benefits of the software architecture at each of the five phases of the development process.
1. Before the project begins
- An enterprise architecture helps to control and steer simultaneous projects.
- Attaching guidelines to offer requests and evaluating them is easier.
- Planning and scheduling projects is easier.
- The architecture provides a framework to discuss and evaluate possible solutions before inception.
2. At the inception phase
- Eliminates risks by encouraging prototypes.
- Aids in estimating timetables.
- Increases the potential for component reuse and implementing best practices.
- Provides a solid foundation for the project.
- Enables communication among project stakeholders.
3. At the elaboration phase
- Serves as a starting point for the detailed design.
- Serves as a manual for design decisions.
4. At the construction phase
- Makes controlling the implementation easier.
- Enforces similarity in design decisions across different parts of the system.
- Enables simultaneous implementation of different parts of the system.
- Serves as a basis for architecture trials.
5. At the transition phase
- Makes integrations to other systems easier.
- Is a useful, consistent aid for sales and presentation material.
Benefits to stakeholders
Here's a listing of the benefits of the software architecture to particular
project stakeholders.
The management team
- Serves as an interface for various stakeholders to discuss the system.
- Increases the accuracy of time/cost estimations.
- The architect is an ally and informational resource to the management team.
The development team
- Provides an excellent overview of the system.
- Provides a guidebook of design issues.
- Enables the development of different parts of the system simultaneously.
The client
- A well-designed architecture guarantees a well-designed and implemented end-product.
- Makes planning integrations easier.
Third-party companies
- Serve as a framework for training, technical support, and so on.
- Provide a standard, consistent overview of the system software.
Resources
- For a more case-specific discussion of the benefits of the software architecture, see Mikko's first column in this series: "Why serious
architecture plans matter for small devices" (developerWorks, April 2004).
- See Mikko's "
Designing software architectures, Part 1" (developerWorks, October 2004) for an overview of the architectural design process.
- In "Designing software architectures, Part 2" (developerWorks, November 2004) Mikko continues the series with a look at the role of the architect.
- In "Designing software architectures, Part 3" (developerWorks, December 2004), Mikko explains the essential qualities of a requirements specification and shows how to write and document use
cases.
- "Supporting Iterative Development Through Requirements Management" (The Rational Edge, January 2004) is an in-depth look at how requirements are established and managed throughout an RUP development life cycle.
- "Reference Architecture: The Best of Best Practices" (The Rational Edge, January 2004) is an excellent discussion of the benefits of RUP in software design and development.
- Browse for books on these and other technical topics.
- Don't miss a single installment of Mikko's Architectural manifesto column! See the column series page for a
complete listing of previous installments in this series.
- The Wireless technology zone specializes in articles covering various wireless solutions.
- Get involved in the developerWorks community by participating in
developerWorks blogs.
About the author  | | | Mikko Kontio works as a production manager for the leading-edge Finnish software company, Softera. He holds a Masters degree in computer science and is the author and co-author of several books, the latest being Professional Mobile Java with J2ME, published by IT Press. Mikko can be reached at mikko.kontio@softera.fi. |
Rate this page
| 
