This post discusses a philosophic question: Are there differences between architecture and design activities? Before answering this question, I would like to tell some assertions found in literature. Eden and Kazman discuss differences among Architecture, Design and Implementation fields. According to them: "Architecture is concerned with the selection of architectural elements, their interaction, and the constraints on those elements and their interactions... 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". Following this idea, Bass et al. defines software architecture as "the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them". The SEI (Software Engineering Institute) considers two distinct activities in the life-cycle development: Architecture design and Detailed design.
We can found several methods, methodologies, approaches, and so on, that can be seen as an architecture or design activity. For example OOAD (Object-Oriented Analysis and Design) methods, CBD (Component-Based Development) methods, SOA (Service-Oriented Architecture) methods. Can these methods be considered design methods? In architecture point of view, we have other methods, such as ADD method by SEI and 4+1 Model View by RUP. These methods present some steps to design a high-level architecture on several views.
In this context, I have some questions:
- Design comprises architecture activities? Or is it the opposite? Do analysis and design discipline in the life-cycle development encompasses an architecture method?
- OOAD is a design method, architecture method or design technique?
- Are UML Components and Catalysis (CBD methods) design methods?
At the end, my final question is: How is named an approach that defines components of the system in a high-level architecture with different views (architecture concept), and defines details of these components such as their operations(design concept)?
6 comments:
In my point of view, I think that architecture activity defines what should be done and the design activity defines how the elements specified by the architecture activity should be done.
So, the architecture activity comprises the design activity.
Please don't attribute "Detailed design" as one of the life cycle activities prescribed by the Software Engineering Institute. In our Software Architecture Technology program (www.sei.cmu.edu/architecture) we try very hard never to use that awful term. It implies that architectural design cannot be detailed, and if information is detailed it must not be architectural. This is not measurable, quantifiable, or (most importantly) even true. We prefer the terms "architectural design" and "non-architectural design" to make the distinction. Architectural design consists of all of the design decisions (which might include constraints on downstream designers) necessary to assure that the system will meet its behavioral and quality attribute requirements. Everything else is non-architectural design. This is discussed at length in a sidebar in the book "Documenting Software Architectures," and I don't feel it's really all that interesting a question anymore.
Design is a continuous activity of making decisions beginning with a collection of decisions that have broad system wide scope and moving to a collection of decisions that have very narrow scope.
As broad categories, saying that those decisions that have system wide scope are architectural and those that have narrow scope are not is a reasonable division but it does not answer the question of where the boundary is and that is the subject of this thread.
I would characterize a decision as architectural if it has one or more of the following impacts:
- it has system wide impact
- it affects the achievement of a quality attribute important to the system
I make this distinction because there are different techniques you might use to evaluate a decision if it is architectural than if it is not.
An architectural decision can be evaluated by considering its impact on the whole system or by its impact on important quality attributes.
Non architectural decisions are evaluated based on their implementation ease, on their understandability, and on the basis of language support.
I agree with Len: design is a continuous activity of making decisions - with no inherent definition of scope, technology, or resulting artifact.
Architecture is a specific design discipline that aims at global balance (tradeoffs). That includes the mentioned system properties and qualities, but it also includes project management enablers, such as the reduction of subsystem couplings to enable parallel and distributed development.
Design for aesthetics, usability, local resource economy, maintainability, etc. would all be examples of different design disciplines.
Design disciplines like CBD or SOA largely focus on architectural design.
This is very useful, I find myself agreeing with Len and Clemens. I think I will use Len's definition the next time someone asked me to outline the distinction between the two.
K
I could describe many specifics that differentiate architecture from design. But in general, I think architecture tends toward the aesthetic, and design tends toward the engineering. They certainly overlap broadly, and this is the source of much confusion around the use of the terms.
Many people will ask, "What is the aesthetic associated with software development?" If you have to ask, you probably don't have a very good grasp of what is really involved in developing large, complex software systems. Which I would say is true of most people involved in the process - unfortunately.
It's too bad software architecture isn't taught in universities, along with other aspects of computer science. It would probably be well for anyone who is serious about the profession to take some courses in building architecture, or at least in the history of architecture. I have found thorugh my own career that people with training in arts, languages, literature, etc., are more likely to make good software architects than those with training only in engineering and science.
I have said elsewhere that good architects don't necessarily make great designers, and many excellent designers are very poor architects.
Post a Comment