Precision and simplification

By Andrew Clifford

We should value simplification more than precision.

We are very good at being precise. Computers are unforgiving about ambiguity, and being precise is a requirement for a job in IT. We have to tease out nuances of meaning so that we can build solutions that truly match requirements.

Sometimes we take precision too far. A few years ago I was working on a large redevelopment project, and had the task of bringing together the work of the other architects into a coherent body of documentation. In the application architecture document, the architect had written that you could come up with different lists of applications according to how you defined what an application is, whether by function, or technology, or users. He had even drawn up a little logic table showing how different definitions would give different application lists.

Precise though this was, it was worse than useless. The point of architecture is to make sense of all the possibilities and to present the solution as coherently as possible. Explaining that you could do it differently is a statement of the obvious, not a useful solution.

Instead of being precise, we should try to simplify things so that they are easy to understand and to manage. In the example above, it would have been much more useful to assert a list of applications with brief descriptions, and then explain how the applications co-operate to meet the solution requirements.

One good place to start our simplification is to revisit the distinction between an application, a process and a service. There are some official definitions of these. ITIL defines them:

• Application - Software that provides functions that are required by an IT service.
• Process - A structured set of activities designed to accomplish a specific objective.
• Service - A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.

TOGAF defines them slightly differently:

• Application - A deployed and operational IT system that supports business functions and services; for example, a payroll.
• Process - A process represents a sequence of activities that together achieve a specified outcome, can be decomposed into sub-processes, and can show operation of a function or service (at next level of detail).
• Service - A logical representation of a repeatable business activity that has a specified outcome.

These definitions are precise and clever but our ability to define them precisely blinds us to a major flaw. In an ideal world, our processes, applications and services would be aligned and the distinction would not matter. A service (customer view) is provided by a process (provider view) supported by an application (IT view). Our ability to distinguish between the three means we tend to build more complicated solutions, with a many-to-many mapping between applications, processes and services. A less precise definition would drive us to simpler, better aligned solutions.

In the past we have been hampered by the sheer difficulty of acquiring IT capability. But things are different now, and we can easily create IT to whatever structure we want. We need to move away from the precise, nuanced distinctions of yesterday, to simpler, more understandable and easier to manage structures.

Subscription