Lean Architecture for Agile Software Development

Chapter 7. What the System Does: System Functionality

One surprising by-product of the scenario-planning process is increased responsibility.

—The Clock of the Long Now, p. 118.

Every system has two designs: the design of what it does, and the design of what it is. End users ultimately care about the services they receive from the software, and these almost always fall into the what-the-system-does category. However, the underlying domain model shows through the service interface. Recall how important the direct manipulation metaphor is to object-oriented programming. Also, for the sake of keeping down long-term cost (which customers and end users also appreciate) and of supporting change (which customers and most end users also appreciate) the vendor (that's you) also wants to start off with a good overall system form, and that form is grounded in what-the-system-is. At the beginning of a project you need to focus on both. This double-edged focus applies not only to good beginnings but is the heart of long-term product health.

It is crucial to always remember that the heart of what software delivers is a service, a service that is about action. Unlike buildings, computers have animation at human time scales, and this animation is key to their role in life. Luke Hohmann advises us that instead of architecture being the best metaphor we have for software system design, that we should look instead to another one of the arts: dance. Like architecture, dance is also about form, but it ...