Many traditionalists believe that the software architect's job begins and ends with the elaboration of the application development process. In fact, as you'll learn in this second part of my discussion on designing software architectures, the architect's work should ideally begin before a project is underway, and it often doesn't end until long after the rest of the team has gone home.
In the first part of this series I explained the importance of choosing and implementing a good process as part of any development project. I touched on the role of the architect in choosing a process well-suited to a project's requirements and constraints, as well as documenting and implementing the process. In this second part of the series, I'll explain the role of the architect in more detail, step by step, using the Rational Unified Process® (RUP®) as a framework for discussion.
As I explained last time, RUP is based on iteration, and each iteration results in an executable release (see Resources). RUP has four phases: inception, elaboration, construction, and transition. I'll use these four phases to focus my discussion on the role of the architect. As previously stated, however, elaboration is actually a midpoint in the development cycle, from the architect's point of view. His or her real work begins with preplanning the project and it doesn't end with the transition, either.
Before a project even gets underway, the architect should be hard at work with all the necessary details of preplanning it. Preplanning includes setting the scope of the project, setting the financial limitations, and getting the project accepted. Much of this phase involves information gathering, negotiation, and the earliest stages of documentation. It is in the preplanning phase that multiple departments and other interested parties first stake their claim on a project and also establish its limitations. If any aspect of the project will be outsourced, the preplanning phase is also the ideal time to seek out development partners.
The software architect's primary role in this phase is to note the expectations being placed on a project and begin narrowing these down to a list of requirements and constraints. Given a list of requirements, the architect can offer a technical perspective on various design options and associated costs. In this process, the architect often acts as a mediator between the many different interests involved in a project (typically, management, marketing, and development) and provides the language to help these groups communicate more effectively with each other.
In order to serve most effectively in the preplanning phase of the project (and throughout the project) the architect should be well on top of the latest technology trends, as well as proven strategies that can be applied to a wide variety of scenarios. He or she should also be prepared to use or suggest a variety of communication devices and tools to help stakeholders collaborate on planning the project, from simply decoding departmental jargon to providing screenshots, architectural diagrams, and use cases to clarify the application guidelines before the project's inception.
The most expensive mistakes tend to happen in the first stages of a development project, although many of them could be avoided by having a good architect on the job from the start. An architect can prove invaluable during the inception phase of a project, which usually includes more formalized requirements analysis, project planning, and iteration planning, as well as the first stages of architecture design. Some projects also initiate the first parts of object-oriented analysis and design during the inception phase.
Having an architect actively engaged in requirements analysis is a good way to ensure that all the necessary requirements are carefully defined and documented. Given the requirements, the architect can also pinpoint typical problem areas from a structural point of view and work to resolve them at this early stage.
After the requirements analysis is complete, the architect moves on to his or her central concern of designing the architecture. In most cases, the architect comes up with a variety of architecture candidates and compares their strengths and weaknesses, often soliciting input and feedback from other people on the development team.
After the architect has settled on a particular architecture, he or she should create some prototypes to help everyone see its pros and cons. Every architecture comes with some tradeoffs, and it's important to compare them openly and effectively. Architectural diagrams and prototypes are among the first concrete artifacts of an application. For many stakeholders, the project does not become "real" until it is manifest in these more concrete forms. If the stakeholders have understood the process thus far (and if the architect has chosen a sound development framework) then the project can proceed to the construction phase. If not, if it becomes clear, for example, that the stakeholders have not understood the essential potential and limitations of the project, or do not agree with the architect's proposed direction, then this phase might send the project development temporarily off the rails.
Regardless of whether the prototype is well received, this stage of the development process is very important. It is the last chance for the team to gracefully reassess the project requirements and make necessary changes.
If the architect has not already been actively engaged with project analysts and designers, he or she should begin to work more closely with them now. It is important to ensure that every stage of the development process is done correctly and is properly documented. Analysis and design errors can be difficult to correct, and even the correctable ones are always very expensive.
Finally, design and implementation guidelines should be established and documented at this stage, and every developer on the team should have the opportunity to ask questions about the chosen solution. Team members who are not familiar with the technologies being implemented should receive whatever training is required to come up to speed prior to development. At the end of the elaboration phase, and prior to construction, the architect should go through the implementation guidelines (that is, coding conventions, and so on) with the development team. This ensures, one last time, that everyone is on the same page about how the project will go.
After the project is underway, the architect begins to step back a little -- but only a little! His or her biggest job at this stage is to regularly audit the development artifacts. It should be a routine part of the development process that the architect reviews code samples from different developers. The most important thing is to make sure that the implementation guidelines are being adhered to, and that all other standards for the application have been met. The architect can also offer support to the development team at this stage.
The transition phase is all about getting the software to the client. Again, support is the best tool to ensure the success of the project. Ideally, the architect will be one of the primary representatives of the product at this stage, answering technical questions, such as how the software was designed and how other systems can be integrated with it, from a client-friendly perspective.
Given the architect's role as mediator between various stakeholders throughout the project, he or she should have little trouble answering the client's questions, and, hopefully, doing so in a way that highlights the end product's best features. For larger organizations, or international ones, it might not be possible to present the product in person. Regardless of how the product is delivered, the architect should be sure that it is well documented on paper and delivered with appropriate technical specifications.
Every development project should conclude with some kind of formalized wrap-up. The project should be critically analyzed so that the development team and organization can learn from its successes and failures. If the development team will continue to work together in the future, a formal closure to the project is also helpful, giving everyone the chance to air their experiences before moving forward to the next project.
In addition to helping the development team process and benefit from its experiences on a project, the architect will, in many cases, be called on to assist the client in adjusting to their new software. The architect might need to do some training or troubleshooting with the client in the early stages of adoption. If the system is further developed or integrated with another system in the future, it would obviously benefit the project to have the participation, or at least advice, of the original architect.
Even more important than the architect's step-by-step involvement in a development project is the background preparation that allows him or her to effectively participate in a team. The ideal architect bridges technology and concept, using a variety of visual and verbal tools to ensure that each member of the team understands the project as it moves through each stage of development. He or she also stays abreast of technology trends and is therefore able to bring considerable knowledge and creativity to the process of selecting an appropriate framework for the project. Finally, the architect's overarching perspective on the project makes him or her a good candidate to represent the end product to the client, and also guide the client through the adoption process.
In some cases, it might seem that the architect's work overlaps with that of a project manager. In some smaller projects that can happen, but in most cases the architect and the project manager work hand-in-hand, with each person handling his or her areas of expertise.
Following is a summary of the role of the architect in each stage of development:
- Preplanning: Follow technology trends; mediate among stakeholders; initiate requirements gathering and analysis.
- Inception: Formalize requirements specification; ensure that
all team members understand the scope and limitations of the project;
possibly create software prototypes for demonstration purposes.
- Elaboration: Design the architecture; analyze the chosen
solution's pros and cons; create a prototype of the end product;
document design and implementation guidelines; organize training
for development team members; establish and communicate coding
conventions; audit object-oriented analysis and design.
- Construction: Audit each stage of implementation; support
the development team.
- Transition: Support the transition of the end product to the
client; represent the end product to the client.
- Wrapping up: Further assist client adoption of the end product; design and plan further development; participate in product integration with other systems; explain how the system was designed and implemented.
In this second installment of a five-part series, I've focused on the process of designing software architectures from an architectural perspective. In last month's introduction to the series, I explained in detail the importance of the process, using RUP as my starting framework. In this second part, I've examined the role of the architect. I'll continue next month with a focus on the details of writing a proper requirements specification.
- See Mikko's Architectural manifesto:
Designing software architectures, Part 1 (developerWorks, October 2004) for an overview of the architectural design process.
- Documenting
software architectures (The Rational Edge, January 2004) is one
architect's account of the importance of good documentation in large-scale development
projects -- as well as a review of a book worth reading.
- 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.
- Risk
reduction with the RUP phase planThe Rational Edge, September 2003) is a more example-driven look at how RUP works in a real-world software development project.
- 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 zone specializes in articles covering various wireless solutions.
Mikko Kontio works as a Technology 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.
