Architecture

In the last few years, I have been interested in architectural design decisions and architectural knowledge. Also I am interested on to marry light-weight processes and architecture; show the value of architecture. Here are some recent publications on this topic (most recent first).

• Ph. Kruchten, “Documentation of Software Architecture from a Knowledge Management Perspective–design representation,”  in: Software Architecture Knowledge Management: Theory and Practice, M. Ali Babar, T. Dingsøyr, P. Lago, and H. van Vliet, Eds.  Springer-Verlag, 2009, pp. 39-57.

In the chapter 3 of this book, I review how software architects have represented architectural knowledge and in particular architectural design. This has evolved over the last 3 decades, from very intuitive and informal to very structured, abstract and formal, from simple diagrams and metaphors to design notations, and specific languages. As our understanding of architectural knowledge evolved, the importance of design rationale and the decision process became more and more prominent. There is however a constant through this evolution: the systematic use of metaphors. (See more about the book here)

• Ph. Kruchten, R. Capilla, J. C. Dueñas, “The role of a decision view in software architecture practice,” IEEE Software vol. 26 (2), pp. 36-42, Mar/Apr 2009. doi:10.1109/MS.2009.52

A “decision view” provides a useful addition and complement to more traditional sets of architectural views and viewpoints; it gives an explanatory perspective that illuminates the reasoning process itself and not solely its results. This decision view documents aspects of the architecture that are hard to reverse-engineer from the software itself and that are often left tacit. The decision view and the decisions that it captures embody high-level architectural knowledge that can be transferred to other practitioners, merged when systems are merged, and offer useful support for the maintenance of large and long-lived software-intensive systems.

• Ph. Kruchten, “What do software architects really do?” Journal of Systems & Software, vol. 81, pp. 2413-2416, 2008 doi: 10.1016/j.jss.2008.08.025.

To be successful, a software architect—or a software architecture team, collectively—must strike a delicate balance between an external focus—both outwards: Listening to customers, users, watching technology, developing a long-term vision, and inwards: driving the development teams—and an internal, reflective focus: spending time to make the right design choices, validating them, and documenting them.

• D. Falessi, G. Cantone, and Ph. Kruchten, “Value-Based Design Decision Rationale Documentation: Principles and Empirical Feasibility Study,” in Proceeding of the 7^th IEEE Working Conference on Software Architecture, Vancouver, BC, February 18-22, 2008, IEEE Computer Society, pp.189-190. DOI: 10.1109/WICSA.2008.8

The explicit documentation of the rationale of design decisions is a practice generally encouraged, but rarely implemented in industry because of a variety of inhibitors. Methods proposed in the past for design decisions rationale documentation (DDRD) aimed to maximize benefits for the DDRD consumer by imposing on the producer of DDRD the burden to document all the potentially useful information. We propose here a compromise which consists in tailoring DDRD, based on its intended use or purpose. In our view, the adoption of a tailored DDRD, consisting only of the required set of information, would mitigate the effects of DDRD inhibitors. The aim of this paper is twofold: i) to discuss the application of value-based software engineering principles to DDRD, ii) to describe a controlled experiment to empirically analyze the feasibility of the proposed method.

• D. Falessi, Ph. Kruchten, and G. Cantone, “Issues in Applying Empirical Software Engineering to Software Architecture,” in Proceedings of the European Conference on Software Architecture (ECSA 2007), F. Oquendo (Ed.), Aranjuez, Spain, September 24-26, 2007, Berlin: Springer Verlag.

• D. Falessi, G. Cantone, and Ph. Kruchten, “Do Architecture Design Methods Meet Architects’ Needs?” presented at WICSA ’07, the 2007 Working IEEE/IFIP Conference on Software Architecture, Mumbai,  India, January 2007, IEEE Computer Society.

Several Software Architecture Design Methods (SADM) have been published, reviewed, and compared. But these surveys and comparisons are mostly centered on intrinsic elements of the design method, and they do not compare them from the perspective of the actual needs of software architects. We would like to analyze the completeness of SADM from an architect’s point of view. To do so, we define nine categories of software architects’ needs, propose an ordinal scale for evaluating the degree to which a given SADM meets the needs, and then apply this to a small set of SADMs. The contribution of the paper is twofold: (i) to provide a different and useful frame of reference for architects to select SADM, and (ii) to suggest SADM areas of improvements. We found two answers to our question: “do architectural design methods meet the needs of the architect?” Yes, all architect’s needs are met by one or another SADM, but No, no architectural design method meets simultaneously all the needs of an architect.

• Ph. Kruchten, P. Lago, and H. van Vliet, “Building up and reasoning about architectural knowledge,” in QoSA-Quality of Software Architecture, Vasteras, Sweden, July 2006. In: proceedings: vol. 4214, LNCS, Ch. Hofmeister (ed.), Springer-Verlag, 2006, pp. 43-58.

Architectural knowledge consists of architecture design as well as the design decisions, assumptions, context, and other factors that together determine why a particular solution is the way it is. Except for the architecture design part, most of the architectural knowledge usually remains hidden, tacit in the heads of the architects. We conjecture that an explicit representation of architectural knowledge is helpful for building and evolving quality systems. If we had a repository of architectural knowledge for a system, what would it ideally contain, how would we build it, and exploit it in practice? In this paper we describe a use-case model for an architectural knowledge base, together with its underlying ontology. Putting together ontologies, use cases and tool support, we are able to reason about which types of architecting tasks can be supported, and how this can be done.

• Ch. Hofmeister, Ph. Kruchten, R. Nord, H. Obbink, A. Ran, and P. America, “A General Model of Software Architecture Design Derived from Five Industrial Approaches,” Journal of Systems & Software, vol. 80, pp. 106-126, 2007. doi:10.1016/j.jss.2006.05.024

We compare five industrial software architecture design methods and we extract from their commonalities a general software architecture design approach. Using this general approach, we compare across the five methods the artifacts and activities they use or recommend, and we pinpoint similarities and differences. Once we get beyond the great variance in terminology and description, we find that the five approaches have a lot in common and match more or less the ‘‘ideal’’ pattern we introduced. From the ideal pattern we derive an evaluation grid that can be used for further method comparisons.

• Ph. Kruchten, H. Obbink, and J. Stafford, “The past, present and future for software architecture,” IEEE Software, vol. 23 (2), pp. 2-10, 2006. doi: 10.1109/MS.2006.59

It’s been 10 years since David Garlan and Mary Shaw wrote their seminal book Software Architecture Perspective on an Emerging Discipline, since Maarten Boasson edited a special issue of IEEE Software on software architecture, and since the first International Software Architecture Workshop took place. What has happened over these 10 years? What have we learned? Where do we look for information? What’s the community around this discipline? And where are we going from here?This article is part of a focus section on software architecture.

• Ph. Kruchten, “Casting Software Design in the Function-Behavior-Structure (FBS) Framework,” IEEE Software, vol. 22 (2), pp. 52-58, 2005. DOI: 10.1109/MS.2005.33

I cast the software engineering process into the function-behavior-structure framework and thus into the broader framework of engineering design. By doing so, we can draw some lessons about the state of our favorite engineering discipline. The most important lesson might be that many of the analogies we’ve drawn from other engineering disciplines, especially civil engineering, are somewhat flawed or biased.

• Ph. Kruchten, “An Ontology of Architectural Design Decisions,” presented at 2nd Groningen Workshop on Software Variability Management, Groningen, NL, 2004.  Here.
• H. Obbink, P. Kruchten, W. Kozaczynski, R. Hilliard, A. Ran, H. Postema, D. Lutz, R. Kazman, W. Tracz, and E. Kahane: Report on Software Architecture Review and Assessment (SARA), Version 1.0. At http://kruchten.com/philippe/architecture/SARAv1.pdf.  February 2002.
• Ph. Kruchten, “Mommy, where do software architectures come from?” presented at IWASS1 1st International Workshop on Architectures for Software Systems, Seattle, WA, 1995 see
• Ph. Kruchten, “The 4+1 View Model of Architecture,” IEEE Software, vol. 12 (6), pp. 45-50, 1995. DOI: 10.1109/52.469759

and on a lighter side:

• Ph. Kruchten, “The Tao of the Software Architect,” The Rational Edge, March 2001. (free)