 | Level: Introductory Mikko Kontio (mikko.kontio@softera.fi), Technology Manager, Softera
10 Nov 2004 In this second part of his series on designing software architectures, Mikko walks you through the role of the architect, from pre-planning the project prior to its inception to cleaning up the loose ends after it's shipped.
Introduction
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.
Preplanning
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.
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.
Elaboration
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.
Construction
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.
Transition
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.
Wrapping up
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.
The architect in training
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 conclusion
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.
Resources
About the author | | |
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. |
Rate this page
| |
