Guidelines for the System Metaphor
Extreme Programming’s system metaphor, as traditionally presented, has a fatal flaw. It has a nudge which encourages teams to describe the system at too high a level, as one large monolithic thing. The result is nearly always the same: a generic metaphor that doesn't really describe the software and provides next to no guidance for implementation. This has led many in the Agile community, including Kent Beck, XP's creator, to abandon the system metaphor entirely. I have three big worries with this.
The ultimate goal of the system metaphor is to create a common vision and vocabulary for discussing and reasoning about a system - with all stakeholders. This stands for the refreshed system metaphor too. Communication is king in the abstract world of software architecture, and so communication is the ultimate metric for determining whether a system metaphor is good or bad. Metaphors that enhance communication are better than ones that confuse or mislead the team.
To this end, there are five guidelines for evaluating metaphors to determine their fitness as aids for describing software architecture, and one corollary for sharing and using metaphors.
A good metaphor:
Corollary: Even a good metaphor still requires explanation.
A good metaphor represents a single view. It is now common practice when thinking of software architecture to describe a system using multiple views. Views are like taking pictures of a 3D object. While it would be nice to see the whole object, because a picture can only capture two dimensions at a time you’ll need several pictures to get a good representation of the object. What this means for the system metaphor is that you will need more than one metaphor to adequately describe the system.
A good metaphor deals with only one type of structure. Structures are the building blocks for an architecture and there are three basic kinds of structures in the software world. Static structures deal with code – classes, modules, layers, and so forth. Dynamic structures deal with running code – objects, tiers, processes, connections (e.g. a client connecting to a server) and so on. Physical structures deal with, well, things in the real world, the hardware – computers and servers, routers and switches, as examples.
When creating a metaphor it should be a single view and deal with only one kind of structure at a time. This aids with communication and reasoning by keeping things simple and by helping you compare apples to apples. Use metaphors of things (i.e. nouns) to represent static structures. Use metaphors of actions (i.e. verbs) to represent dynamic structures. Physical structures are less abstract and are generally best served by being represented directly.
A good metaphor gives clear guidance concerning design decisions. The metaphors you use should provide a guide rail for implementation by clearly communicating design decisions, background, and rationale. Great metaphors will make it easy to connect higher-level, architecturally relevant design decisions and guidelines to the lower-level, implementation oriented design decisions. Maintaining architectural integrity is, after all, a team responsibility.
A good metaphor sheds light on system properties. One of the most important reasons to think about the architecture of a system is ensure that desired properties are promoted by the design. These properties are commonly articulated as quality attributes or quality requirements. Having a clear understanding for why a set of structures and guidelines were chosen helps everyone to continue to support those properties in their low-level design decisions.
System properties are communicated through storytelling with the metaphor as the impetus for the story. A good metaphor will make it easy to tell a story about desired (or undesired) system properties and how the design promotes (or inhibits) the properties.
A good metaphor draws on a shared experience. Shared experiences are the bedrock of any good metaphor. Metaphors create a new vocabulary for discussing the architecture of a system and often rely on subtle nuances for sharing meaning. For the metaphor to be effective, everyone on the team must have the background necessary to not only understand the metaphor but also understand the implications of the metaphor. This shared experience might be technical in nature (documented architectural styles and patterns are an excellent source for a shared experience) or can be non-technical such as references to pop culture, movies, and food.
A common experience is also created through the act of choosing a metaphor and the best metaphors are those that the team arrives at together. Metaphors bring with them a payload of information, pointers to design decisions, whiteboard discussions, arguments, code, guidelines, and many other important ideas important to a particular part of the system. Having a relatable metaphor better facilitates communication and more easily brings to mind this history and data payload.
Corollary: Even a good metaphor still requires explanation. No metaphor can survive in isolation. It is naïve to think that a metaphor, even a great one which satisfies all the other guidelines, will immediately make sense to a person who is hearing it for the first time. Take the time to explain the metaphor to your team and create the shared experience necessary for everyone to relate to it. Doodle on the whiteboard. Sketch on paper. Show them code. Talk about quality attributes. Once the intent and rationale behind the metaphor is commonly understood you may not need any documentation since the metaphor should immediately bring to mind all the important structures, guidelines, and properties relevant to that view of the system.
System Metaphor, a Great Addition to your Silver Toolbox
I’ve found the refreshed system metaphor to be extremely helpful, but it is not a panacea for agile architecture – it is no silver bullet. The refreshed system metaphor is, however an excellent addition to your silver toolbox. With this set of guidelines the system metaphor becomes, in my opinion, a viable tool for describing the architecture of a software system in many situations. But your mileage may vary for non-collocated or especially large teams. In these cases, metaphors will still be useful (they’ll come up naturally anyway), and you will need to supplement the metaphors your team uses with additional documentation. A little documentation (the right documentation) never hurt anyone and even a lightweight architecture description document that assists with communication and understanding is worth its weight in gold.
Making metaphors that matter is difficult work. It takes iteration and breakthrough insights over time to really discover the great metaphors that make sense. With this set of guidelines in hand, knowing when you’ve discovered a good metaphor will be easy.
The system metaphor is dead! Long live the system metaphor!
For More Information... These guidelines were born from reflection on a recent project in which we used the system metaphor, as presented here, to effectively describe the architecture of our system as we built it. The guidelines, along with examples, were presented as an experience report I coauthored with Michail Velichansky, "Making Metaphors that Matter" (PDF), at the Agile2011 conference in Salt Lake City, UT. Don’t hesitate to get in touch with questions, feedback, or insights using the comments here, email (mkeeling[at]neverletdown[dot]net), or twitter (@michaelkeeling).
- While Beck may have changed his mind about many practices from XP, both versions of Extreme Programming, available in two editions of Extreme Programming Explained, are readily available and actively promoted by the publisher. Treating both editions as equals curbs the adoption and spread of better practices. The metaphor lives on in spite of being abandoned by its creator.
- Agile teams, while improving, have been generally slow to adopt now common knowledge on software architecture. Deemphasizing the system metaphor has created a black hole in the software lifecycle around architecture and design. Those teams that are software architecture-focused have a hard time figuring out how to remain agile while incorporating architecture best practices.
- Metaphors aren't going anywhere. They are a natural reaction to describing complex things – in literature, in life, and in software. Ignoring the system metaphor makes it more difficult to use effectively.
The System Metaphor, Refreshed
The ultimate goal of the system metaphor is to create a common vision and vocabulary for discussing and reasoning about a system - with all stakeholders. This stands for the refreshed system metaphor too. Communication is king in the abstract world of software architecture, and so communication is the ultimate metric for determining whether a system metaphor is good or bad. Metaphors that enhance communication are better than ones that confuse or mislead the team.
To this end, there are five guidelines for evaluating metaphors to determine their fitness as aids for describing software architecture, and one corollary for sharing and using metaphors.
A good metaphor:
- Represents a single view.
- Deals with only one type of structure.
- Gives clear guidance concerning design decisions.
- Sheds light on system properties.
- Draws on a shared experience.
Corollary: Even a good metaphor still requires explanation.
A good metaphor represents a single view. It is now common practice when thinking of software architecture to describe a system using multiple views. Views are like taking pictures of a 3D object. While it would be nice to see the whole object, because a picture can only capture two dimensions at a time you’ll need several pictures to get a good representation of the object. What this means for the system metaphor is that you will need more than one metaphor to adequately describe the system.
A good metaphor deals with only one type of structure. Structures are the building blocks for an architecture and there are three basic kinds of structures in the software world. Static structures deal with code – classes, modules, layers, and so forth. Dynamic structures deal with running code – objects, tiers, processes, connections (e.g. a client connecting to a server) and so on. Physical structures deal with, well, things in the real world, the hardware – computers and servers, routers and switches, as examples.
When creating a metaphor it should be a single view and deal with only one kind of structure at a time. This aids with communication and reasoning by keeping things simple and by helping you compare apples to apples. Use metaphors of things (i.e. nouns) to represent static structures. Use metaphors of actions (i.e. verbs) to represent dynamic structures. Physical structures are less abstract and are generally best served by being represented directly.
A good metaphor gives clear guidance concerning design decisions. The metaphors you use should provide a guide rail for implementation by clearly communicating design decisions, background, and rationale. Great metaphors will make it easy to connect higher-level, architecturally relevant design decisions and guidelines to the lower-level, implementation oriented design decisions. Maintaining architectural integrity is, after all, a team responsibility.
A good metaphor sheds light on system properties. One of the most important reasons to think about the architecture of a system is ensure that desired properties are promoted by the design. These properties are commonly articulated as quality attributes or quality requirements. Having a clear understanding for why a set of structures and guidelines were chosen helps everyone to continue to support those properties in their low-level design decisions.
System properties are communicated through storytelling with the metaphor as the impetus for the story. A good metaphor will make it easy to tell a story about desired (or undesired) system properties and how the design promotes (or inhibits) the properties.
A good metaphor draws on a shared experience. Shared experiences are the bedrock of any good metaphor. Metaphors create a new vocabulary for discussing the architecture of a system and often rely on subtle nuances for sharing meaning. For the metaphor to be effective, everyone on the team must have the background necessary to not only understand the metaphor but also understand the implications of the metaphor. This shared experience might be technical in nature (documented architectural styles and patterns are an excellent source for a shared experience) or can be non-technical such as references to pop culture, movies, and food.
A common experience is also created through the act of choosing a metaphor and the best metaphors are those that the team arrives at together. Metaphors bring with them a payload of information, pointers to design decisions, whiteboard discussions, arguments, code, guidelines, and many other important ideas important to a particular part of the system. Having a relatable metaphor better facilitates communication and more easily brings to mind this history and data payload.
Corollary: Even a good metaphor still requires explanation. No metaphor can survive in isolation. It is naïve to think that a metaphor, even a great one which satisfies all the other guidelines, will immediately make sense to a person who is hearing it for the first time. Take the time to explain the metaphor to your team and create the shared experience necessary for everyone to relate to it. Doodle on the whiteboard. Sketch on paper. Show them code. Talk about quality attributes. Once the intent and rationale behind the metaphor is commonly understood you may not need any documentation since the metaphor should immediately bring to mind all the important structures, guidelines, and properties relevant to that view of the system.
System Metaphor, a Great Addition to your Silver Toolbox
I’ve found the refreshed system metaphor to be extremely helpful, but it is not a panacea for agile architecture – it is no silver bullet. The refreshed system metaphor is, however an excellent addition to your silver toolbox. With this set of guidelines the system metaphor becomes, in my opinion, a viable tool for describing the architecture of a software system in many situations. But your mileage may vary for non-collocated or especially large teams. In these cases, metaphors will still be useful (they’ll come up naturally anyway), and you will need to supplement the metaphors your team uses with additional documentation. A little documentation (the right documentation) never hurt anyone and even a lightweight architecture description document that assists with communication and understanding is worth its weight in gold.
Making metaphors that matter is difficult work. It takes iteration and breakthrough insights over time to really discover the great metaphors that make sense. With this set of guidelines in hand, knowing when you’ve discovered a good metaphor will be easy.
The system metaphor is dead! Long live the system metaphor!
For More Information... These guidelines were born from reflection on a recent project in which we used the system metaphor, as presented here, to effectively describe the architecture of our system as we built it. The guidelines, along with examples, were presented as an experience report I coauthored with Michail Velichansky, "Making Metaphors that Matter" (PDF), at the Agile2011 conference in Salt Lake City, UT. Don’t hesitate to get in touch with questions, feedback, or insights using the comments here, email (mkeeling[at]neverletdown[dot]net), or twitter (@michaelkeeling).
Comments
Post a Comment