Archives

Get monthly notifications of updates to news@sei features and columns

Contact the Editor

SEI Technical Reports

SEI Events

SEI Home

columns the architect

The Duties, Skills, and Knowledge of Software Architects  [2007 | 1]
Rick Kazman, Paul Clements, Mark Klein

Much research in the software architecture field in recent years has focused on technical aspects of architecting: architectural styles, documentation, analysis, architecture description languages, architectural reverse engineering, and so forth [Bass 03]. But what does it mean for an architect or an architecting organization to be competent? We assert that duties, skills, and knowledge form a triad on which architecture competence rests.

Skills and knowledge support the ability to perform the required duties. An omniscient, infinitely skilled architect is of no use if he or she cannot (for whatever reason) perform the duties required of the position; we might say that person possesses great potential, but we would not say that person is competent.

In particular, we are working toward understanding the following:

• What does it mean to be a competent architect? How can we measure the architecture competence of an individual?
• What does it mean to be an architecturally competent organization? How can we measure the architecture competence of an organization?
• How can an individual increase his or her architecture competence over time? How can an organization increase its overall architecture competence?

These questions define a large research area that is only now beginning to be explored. The goal of competence, of course, is to reliably produce high-quality architectures, but there is much more to it than that. For one thing, architects spend much of their time doing things other than producing an architecture for the current project. For another, organizations must put in place sound practices and reliable support to assure high-quality architectures in the future; focusing only on the existing architecture(s) will eventually lead to failure.

The desired output of this program of research is to propose a working theory of architecture competence and a framework for discussing and, eventually, measuring competence. This theory may be informal at first, but at the least we expect that it will provide some practical guidance. Perhaps initially the model will consist simply of lists of duties, skills, and knowledge that an individual or an organization must master, but eventually these lists will be replaced with a more detailed understanding of the relationships between what an architect (or architecting organization) does and the effects those things have on the quality of architectures produced both now and in the future.

At the SEI, we are working on creating this theory of competence. Our work began with an attempt to catalog duties, skills, and knowledge. There is no single definitive or authoritative source for the duties, skills, and knowledge required for competence in architecture. There are, however, a number of community resources that we have canvassed to assemble a description of what an architect and an architecting organization must know and do. The sources can be roughly divided into three categories:

1. Broadcast sources are sources of information written by self-styled experts aimed at mass anonymous consumption. These sources include
• Web sites related to software architecture. We performed a Web search for sites describing or giving advice on software architecture. Well-known examples include the Bredemeyer Consulting Web site and the Software Engineering Institute's (SEI's) architecture Web site. We took data from the 16 Web sites we found that explicitly mentioned duties, skills, or knowledge.
• Blogs and essays related to software architecture. Rob van Ommering's Things to Do in Denver If You're an Architect is a good example of an essay that explicitly discusses architectural duties, skills, and knowledge. In all, we took data from 16 essays.
• Books on software architecture. By looking at the detailed tables of contents of the Amazon.com best-selling books on software architecture, we can infer what authors are prescribing that architects do, have, and know. The 25 best-selling titles were surveyed; 23 made contributions.
2. Sources of training and education tell us what organizations in the business of education or training think that architects need to know and what architects (or aspiring architects) are paying money to learn. These sources include
• University courses in software architecture. A Web search revealed 29 academic courses in software architecture. Course descriptions and syllabi provided lists of duties, skills, and knowledge being taught in these courses.
• Public non-academic (industrial) courses in software architecture. We gathered data from 22 industrial courses whose descriptions were available online.
• Certificate and certification programs for software architects¹. Seven programs were identified from which we took data.
3. Sources related to software architecture careers tell us what employers are looking for and what architects seeking employment are saying about themselves. This category turned out to be an especially rich source of duties, skills, and knowledge, often explicitly listed in exactly those terms. These sources include
• Job descriptions for software architects. We visited the Web sites of the top 150 Fortune 500 companies and searched for position descriptions for software architects. We also visited major employment sites. Sixty job descriptions were included in the survey.
• Résumés of software architects seeking employment. We collected about a dozen résumés from employment sites.

Altogether, we gathered information from more than 200 separate sources for our study of architecture competence. The survey resulted in more than 400 duties, skills, and knowledge areas, each of which somebody thinks is important for software architects to master. The collection includes about 200 separately cataloged duties, about 100 skills, and about 100 areas of knowledge. To extract order from the chaos, we performed an affinity diagram exercise to add structure to the duties, skills, and knowledge [Tague 04].

As a result of our survey of publicly available resources, we now have a set of raw data (as described by Clements et al [Clements 07]) that we have distilled into the following broad categories:

Duties:

• architecting
• managing/interacting with life-cycle phases other than architecture
• technology related
• interacting with stakeholders
• management
• organization and business-related issues
• leadership and team building

Skills:

• communication skills
• interpersonal skills
• work skills
• personal skills

Knowledge:

• computer science knowledge
• knowledge of technologies and platforms
• knowledge about organizational context and management

We realized, from our many interactions with practicing architects, that their jobs are far more complex than just making technical decisions, although clearly that remains their most essential single duty. And so we also realized that there was an unfulfilled need for a comprehensive look at what it means for someone to be a competent architect in all dimensions. We envision that this set of duties, skills, and knowledge will be a starting point for an individual wishing to be an architect to determine what he or she should study or practice. Similarly, an organization that wants to nurture architects will benefit from such a categorization, as they will have the beginnings of a roadmap for training and mentoring.

References

[Bass 03]
Bass, L.; Clements, P.; & Kazman, R. Software Architecture in Practice, 2nd ed. Boston, MA: Addison-Wesley, 2003.

[Clements 07]
Clements, P.; Kazman, R.; Klein, M.; Devesh, D.; Reddy, S.; & Verma, P. "The Duties, Skills, and Knowledge of Software Architects," Proceedings of the Sixth Working IEEE/IFIP Conference on Software Architecture (WICSA). Mumbai, India, January 6-9, 2007.

[Tague 04]
Tague, N.R. The Quality Toolbox, 2nd ed. Milwaukee, WI: ASQ Quality Press, 2004.

¹ A certificate attests to successful completion of a course of study. A certification attests to tested mastery of information or abilities.

About the Authors

Rick Kazman is a senior member of the technical staff at the SEI, where he is a technical lead in the Architecture Tradeoff Analysis Initiative. He is also an adjunct professor at the Universities of Waterloo and Toronto. His primary research interests within software engineering are software architecture, design tools, and software visualization. He is the author of more than 50 papers and co-author of several books, including a book recently published by Addison-Wesley titled Software Architecture in Practice. Kazman received a BA and MMath from the University of Waterloo, an MA from York University, and a PhD from Carnegie Mellon University.

Paul Clements is a senior member of the technical staff at Carnegie Mellon University's Software Engineering Institute, where he has worked for 8 years leading or co-leading projects in software product line engineering and software architecture documentation and analysis. Clements is the co-author of three practitioner-oriented books about software architecture: Software Architecture in Practice (1998, second edition due in late 2002), Evaluating Software Architectures: Methods and Case Studies (2001), and Documenting Software Architectures: View and Beyond (2002). He also co-wrote Software Product Lines: Practices and Patterns (2001), and was co-author and editor of Constructing Superior Software (1999). In addition, Clements has also authored dozens of papers in software engineering reflecting his long-standing interest in the design and specification of challenging software systems. He received a B.S. in mathematical sciences in 1977 and an M.S. in computer science in 1980, both from the University of North Carolina at Chapel Hill. He received a Ph.D. in computer sciences from the University of Texas at Austin in 1994.

Mark Klein is a senior member of the technical staff at the SEI where he is a technical lead in the Architecture Tradeoff Analysis Initiative. He has more than 20 years of experience in research and technology transition on various facets of software engineering and real-time systems. Klein's most recent work focuses on the analysis of software architectures. Klein's work in real-time systems involved the development of rate monotonic analysis (RMA), the extension of the theoretical basis for RMA, and its application to realistic systems. He has co-authored many papers and is a co-author of the RMA Handbook, A Practitioner's Handbook for Real-Time Analysis: Guide to Rate Monotonic Analysis for Real-Time Systems.

The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.

Return to COLUMNS list