Precision and simplification

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.

© Copyright 2012 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Assessments are awesome

As well as gathering facts and supporting decision making, an effective assessment process clarifies objectives, encourages collaboration, and builds buy-in for change.

Most of my work these days involves helping organisations carry out assessments. I get involved in different sorts of assessments - shared services, information security, governance, transformation initiatives, and so on. But whatever sort of assessment we are doing, we get a whole load of benefits over and above the primary objective of the assessment itself.

Defining what we want to know clarifies objectives. At the start of most exercises, the objective for the process is generally high-level and vague, such as "identify opportunities for improving shared services". As part of the assessment process, this objective is broken down into specific questions to be answered, and rules about how the answers will be treated. This forces a detailed analysis of the objective, for example classifying opportunities for improvement, or articulating rules for compliance. Even before we start gathering information, we have created a more detailed view of what the organisation is aiming for.

The fact-gathering process is a major knowledge-sharing exercise for the organisation and helps the organisation collaborate more closely. Assessment involves building definitive lists of whatever is being assessed, such as projects, or systems, or IT services, and answering standard questions for each item. The process is very collaborative, and is often the first time the organisation has worked closely across different teams. As well as understanding more about each other's areas, the assessment process creates loads of opportunities for tactical improvements.

Assessment gives management confidence to act more decisively. In the assessments I have been involved in, management often have a good grasp of what needs to be done, but they are held back by two things: they can not back up their "gut feel" with facts; and they are not confident that they fully understand the areas that have not recently been the focus of their attention. Assessment helps both of these. It shows how management's high-level perceptions of the situation can be traced back (or not) to real facts. It also demonstrates that the less well known areas have been examined. Effective assessment makes it much easier for management to be confident of their decisions and justify further investment.

Assessment helps build buy-in. People are often concerned about change, but asking them their opinions and getting them involved in fact-finding warms them up to the process. People who could be hostile to change become very enthusiastic for assessments because they see it as a way of getting their views across to management.

At the end of the process, the assessment delivers on its primary objective, such as identifying areas for improvement, assessing compliance, providing details for a transformation programme, or whatever. But along the way it delivers much more - a more detailed sense of direction, closer collaborative working, more confident and better justified decisions, and greater buy-in. On a personal level, although assessments may appear dull, it is a much more interesting and rewarding activity than it may seem. When you get into them, assessments are awesome.

© Copyright 2012 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.