Software development as mapping
I started writing this post quite a while ago and now stumbled across it. Seems like it deserves publishing.... and an ending!
I have always been a bit disturbed about that we use architecture as the one and only metaphor for software development. Originally it was thought that building software was somewhat similar to building houses. Most people nowadays realize that this is not the case. The word architecture has gained a meaning of its own when used in the system development context. It is essentially useless to try to change it. We have to accept it and use the metaphor whenever we speak of the structure and subdivision of a software system. (Which also means that I have to accept the title "software architect" when being the person that makes decisions about the structure of a software system. Well, well - with great titles come great powers and sometimes a bit of reward.) It is nevertheless refreshing to think in other ways occasionally and this post is about software development as mapping.
I was happy to - yet again - read a brilliant a list apart article somewhat related to this issue. At least it made me start thinking about it again. The article is called Mapping Memory : Web Designer as Information Cartographer and is written by Aaron Rester. He makes the case that instead of thinking about web design as information architecture - we should think about it as cartography - providing maps for the user. Listen:
I suggest, therefore, that the art of cartography might fruitfully be used alongside architecture. This might sound like an odd suggestion, since at first glance, cartography appears to be nearly the opposite of architecture. Common sense tells us that an architect begins with an abstraction—a blueprint—and creates from that abstraction a concrete structure existing in physical space. The cartographer, on the other hand, starts with concrete structures existing in physical space and creates from that an abstraction: a map.
Now I think that this is valid also for system architecture. A software system is - in the end (believe it or not) - built for its users and they often need a map or a mental model to safely navigate the system. But what is this map really?
My experience is that a system architecture should be as close a resemblance of the users real world as possible. There are things that are core to the users - these things may be written in stone throughout the system. A word processing system shouldn't lack a document object - paragraphs, chapters, words and letters are core to the system. These concepts should be in the midst of the map.
Sometimes it can even be used as the tool for changing the users real world. If a business wants to head in a certain direction its software can be used to redraw the map. Most important in this case is the visual structure that Aaron Rester is talking about but underneath there is another structure that needs to be in sync. If the system behaves contrary to the experienced map the user will be confused and will think about the system as a magic artifact. It is possible to think of different kind of maps. A surface map that is what Aaron writes about and a infrastructure map that also explains the inner workings of the system.
Some things that I do when creating a system architecture:
My experience is that a system architecture should be as close a resemblance of the users real world as possible. There are things that are core to the users - these things may be written in stone throughout the system. A word processing system shouldn't lack a document object - paragraphs, chapters, words and letters are core to the system. These concepts should be in the midst of the map.
Sometimes it can even be used as the tool for changing the users real world. If a business wants to head in a certain direction its software can be used to redraw the map. Most important in this case is the visual structure that Aaron Rester is talking about but underneath there is another structure that needs to be in sync. If the system behaves contrary to the experienced map the user will be confused and will think about the system as a magic artifact. It is possible to think of different kind of maps. A surface map that is what Aaron writes about and a infrastructure map that also explains the inner workings of the system.
Some things that I do when creating a system architecture:
- Treat the business map and the software map as one and the same.
- The software map might describe things that are invisible to the user. The degree of "invisible" things is a measure of complexity.
- Introduce abstractions that are useful for the user. (And hide abstractions that confuses.)
- Ask visionaries about the future. Can the software map guide the user though the next busines development?
- Question any architectural elements that does not enhance the user. Remove them from the map.
All this thinking about mapping led me way back to the programmers stone. A very long time ago I read the original talks and being rather new to the business they helped increase my understanding of the strange organisation I worked in then. It was initially hard to accept that software was deemed good once it worked regardless of the inside quality. The stone helped me grasp that different kinds of persons have different kinds of outlooks on this matter. It introduced the rather simplistic notion of mappers and packers as a way of grouping people. Programmers (at least good ones) are mappers - they understand a problem domain and draw a map that is useful in software construction. A mapper knows how to organize a domain. Other people are mostly packers. They don't know how to organize a domain but are instead rather big on particulars. Listen to this part from thinking about thinking:
I hope this quote got you started. Read the whole thing when you have a couple of hours to spend!
To sum things up - I truly believe that we - system architects - are in deep need of other analogies than "architecture" and we need to think more about what we do. Mapping is one way to look at things but there are surely other ways too.
To understand what programmers really do, an alternative strategy of thinking (called mapping) is necessary, because programming is essentially a process of internalising the capabilities of the system, the nature of the problem, and the desire, and capturing the insight in a programming language. It is all about exploring the details of our desires, and understanding them in such a way that we can keep track of all the complexity. Mapper problem collapse can produce beautiful, tiny, elegant programs with no room for bugs in them. Mapping can do programming, but how it does it cannot be explained in packer,
action-based language.
I hope this quote got you started. Read the whole thing when you have a couple of hours to spend!
To sum things up - I truly believe that we - system architects - are in deep need of other analogies than "architecture" and we need to think more about what we do. Mapping is one way to look at things but there are surely other ways too.