What’s Design Got to Do with It?

Some of the earliest conversations I had in my career about planning through some form of structured specification process were around the topic of design. At the time, I would have asked a reciprocal question “what’s architecture got to do with it?” Now, having spent the last two years in architecture research and understanding a bit more of the domain of planning and governing system implementations, I’ll offer this post to summarize a few of the confusing points that I’ve found along the way.

1. Design is not architecture. This paper from Eden and Kazman (2003) attempts to theoretically assert this position and equally, in support of my last post, that they are both different from implementation. The intension/locality thesis is helpful here, which states that “Architectural specifications are intensional and non-local; Design specifications are intensional but local; and Implementation specifications are both extensional and local.”
2. The term “design” does not always mean design. Based on the idea that you’re either discretely doing design or architecture work, there have been some interesting conversations that I have been a part of over the last year or so, which take me back to my aforementioned roots. I am finding that those who have their history in software development are much like me in that, in the earliest planning activities, they most clearly identify with design not architecture. Often the phrase “high level design” is mentioned when discussing the planning activities for a software project. Based on Eden and Kazman, I would wonder if a high level design process, the output of which would probably be a document which contains this design for the entire software project, would constitute architecture due to its non-local influences. If you consider this paper from Kruchten, his approach to software architecture very much fits in line with what others would consider to be “high level design.” I tend to believe that for any given software system, a software architecture based on an appropriate framework (4+1 View, for example) will sufficiently cover any requirements of a high level design process, thereby reconstituting high level design as normative software architecture.
3. Design must be informed by the architecture. In the event that my interpretation of Eden and Kazman and my application of the discipline of software architecture to high level design activities is inaccurate, then it is still worth noting that any design – be it high or any level – should be structured by a governing software architecture specification. One of the more recent instances of where this has been evident to me is in some high level design documentation I reviewed. It was apparent to me that without a governing architecture, the terms and levels of abstractions found in the design documentation were neither consistent nor all together helpful. Describing software systems should be a top-down activity where starting with the architecture is first applied to defining the domain of the software system itself. If there are to be concepts used in the design and implementation which are defining characteristics of the system, then they must be first set forth in the architecture. Only then should they be explicated in the design and then found to be implemented consistently in the construction. This might be obvious to some, but it is certainly not obvious to all.
4. Design has implications in both UX and SE. User Experience (UX) has become a prominent area of interest in the software communities, especially so in the website construction domain. I will often reference Boxes and Arrows because of its influence on my understanding of this area of study. As I mentioned before, there are no doubt software and systems engineering implications on design. To again make reference to Eden and Kazman, “Design is concerned with the modularization and detailed interfaces of the design elements, their algorithms and procedures, and the data types needed to support the architecture and to satisfy the requirements” [quoted from D. E. Perry, A. L. Wolf (1992)]. Therefore is it is seen that design is clearly a part of the engineering practice. The disciplines of UX and Information Architecture (IA) have also claimed design terms and usages. Where the phrase “design patterns” in IT is traditionally heard in connection to Façade or Factory, it is now being used to talk about Clear Entry Points and Spotlight Transition for UX design patterns. Anyone who has encountered design in non-IT context or has read Norman’s The Design of Everyday Things, understands that design is everywhere, but the salient point here is that design in IT is less clear than we often think. I think there is work yet to be done to systematically connect UX and SE design work. They have much to learn from each other.
5. Design is like architecture in that its use in SE tends to depart from other non-IT domains in terms of roles and responsibilities. For non-IT projects there are usually at least three distinct types of people involved in the respective architecture, design, and implementation activities. For example, a house is “designed” by an architect and then designed (in a more traditional sense) by the interior designer. Architects define spaces where design activities can consist. In the SE world, the same person is often performing both the architecture and design activities. It is not completely clear to me, largely because I don’t think the entire set of applications for the words architecture and design are completely consistent, how and where the duties of one discipline start and stop. What is clear to me is that often SEs are called on to architect, design, and implement systems all themselves. I wonder if as IT continues to mature as a discipline, there will be globally recognized analogous specializations forming around architecture vs. design? I think the increasing use of architecture frameworks and the UX specializations are certainly evidence of a shift.

If you find yourself on my blog, then I’d love to hear your thoughts on any or all of these points. Thanks for reading.

Advertisement