NEWS AT SEI
This article was originally published in News at SEI on: March 1, 2007
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:
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:
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:
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.
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.
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.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.