Ian Barnett
Dr. Richard N. Taylor,
Professor of Information and Computer
Sciences
at the University of California, Irvine
Dr. Nenad Medvidovic,
Director of the USC CSSE
Dr. Eric M. Dashofy,
Senior member of Computer Systems Research,
The Aerospace Corporation
- Software architecture can be thought of as:
- a map through the jungle
- blueprints for a building
- Essential to establish the vision, and how to accomplish it
- Provides greater understanding of the software system to be
designed
- Helps overcome complexity
- “Good architecture makes construction easy, ” (McConnell
44)
- Coordinates work of developers
- Ensures software vision from top to bottom
- Provides evidence to all stakeholders that the software
system is feasible.
- To achieve this overall understanding of the system as
a whole and to obtain this shared vision, all
stakeholders need to own the architecture.
- “Quality of architecture determines conceptual
integrity of the system. A well thought-out
architecture provides the structure needed to
maintain a system’s conceptual integrity from the top
levels down to the bottom,” (Code Complete, 44).
Collaboration with all the
stakeholders is essential for
architectural success
- “. . . the principle of deciding the form of the whole before the
details have been explored outside the mind of the chief designer
does not work in novel situations for which the necessary
experience cannot be contained within the mind of one person,”
(Taylor, Medvidović, and Dashofy 86).
- Too much complexity for one individual.
- This leads to lack of sufficient understanding of the problem and
solution.
- “The designer of today’s state-of-the-art artifact needs help from
masters of various crafts,” (Brooks).
- Complexity leads to probable misinterpretation, but which can be
circumvented by collaborative design (Blair, Watt, and Cull 28).
- “Don’t close the trade-space too fast,” Neil Siegel
- This allows for more fact-based decisions
- A team working toward creating the architecture will be able to
explore a larger trade-space
- More cases explored can lead to
greater understanding of the
problem and greater evidence
that the best solution was chosen
- “By describing the …
alternatives, the architecture
provides the rationale for system
organization and shows that each
class has been carefully
considered,” (McConnell 45)
- Architecture itself contributes to feasibility evidence
that the system can be built which can increase
stakeholder commitment
- If the system is built according to the architecture, it
will meet all requirements and operational concepts.
- Architecture, if understood by customers, convinces
them that their requested system has a
way forward
- Collaborative design helps all to feel
like winners, so they will fight to make
it a success
- All understand the software
solution better
- Tangible
- Neil Siegel, Effective teams come from:
- Exploring the trade-space
- Listening
- Making the success of the project ‘our’ success
- Collaborate early and often, (Chiang and Mookerjee 91).
- “Exactly one person per area of architectural concern (that
is, availability, deployability, auditability, and so on)”
- Make each contributor to the architecture accountable
- Architect works as a facilitator instead of façade (i.e. helps
customers communicate to developers, encouraging direct
interaction) (Blair, Watt, and Cull 29).
- Team communication integrated into process, every phase
- Scheduled walkthroughs, peer reviews,
of code and
architecture, project meetings, win-win sessions (Chiang
and Mookerjee 90)
- “Programmers realize and refine the architects vision… If
an architectural design decision has unforeseen
consequences, a programmer likely will be the first to
notice,” (Taylor, Medvidović, and Dashofy 670).
- System engineers need to understand how the software
will fit with the rest of the system.
- Management needs to support and drive the team toward
that architectural goal. Architects help them think of the
consequences of their decisions.
- Customers present vision. Architecture convinces them
that their requirements are being met.
- “The higher the system complexity, the more intense
coordination should be,” (Chiang and Mookerjee 92).
- Frederick Brooks suggested two main reasons to use
collaborative design in software
- Complexity of system/unfamiliarity with software
technologies
- Short development time
- Collaborative design and architecture promotes learning
- Helps bring a team unfamiliar with the technologies up to
speed more quickly
- More considerations can be addressed
- Because of the improved understanding by all, the
construction of the software can be expedited and
improved.
- Improve success of CS577 projects
Blair, Stuart, Richard Watt, and Tim Cull. “Responsibility Driven Architecture.”
IEEE Software March/April (2010): 26-32.
Brooks, Frederick P. The Design of Design. Boston: Addison-Wesley, 2010.
Chiang, I. Robert, and Vijay S. Mookerjee. “Improving Software Team
Productivity.” Communications of the ACM 47 (2004): 89-93.
Covey, Stephen R. The 7 Habits of Highly Effective People. New York: Fireside,
1990.
McConnell, Steve Code Complete. 2nd ed. Redmond: Microsoft Press, 2004.
Smolander, Kari, Matti Rossi, and Sandeep Purao “Software Architectures:
Blueprint, Literature, Language or Decision?” European Journal of
Information Systems 17 (2008): 575-589
Taylor, Richard N., Nenad Medvidović, and Eric M. Dashofy. Software
Architecture: Foundations, Theory, and Practice. Hoboken: John Wiley
and Sons, 2010.
Jungle images obtained from http://writingday.wikispaces.com/group13 and
http://www.costaricafuntravel.com/Tours-Caribbean-Costa-Rica.html