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 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.
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.
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,
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.