Systemhood

The concept of systemhood makes IT easy to understand. It helps us see how to do less work.

I started these newsletters with two ideas: reduce IT demand by identifying what we do not have to do; and use a strict definition of IT (the automation of information storage, processing and communication) to help understand the value of IT.

As I explored these ideas, I came across some recurring problems.

• IT is often misapplied as a business change driver. Big, strategic projects that are intended to drive business change often fail because they are not properly managed as business change projects, and the non-IT parts are not addressed.
• Most IT management is inward looking. Although we have to manage the efficiencies and effectiveness of supply, these are the wrong viewpoint for reducing unnecessary demand and focusing on value.
• We undervalue the IT that we have and underemphasise the value of keeping it in good order. We treat existing systems as a dirty canvas on which to paint new projects, rather than as a critical business asset. We do not see the value in simple things that keep systems running smoothly, like testing and documentation.

These problems all relate to the difficulties of understanding IT. We have multiple, competing views of IT: projects, technologies, process, organisational structure. These different views make it impossible to see how IT adds value, or where IT is unnecessary.

• We can understand IT value in projects, and so give IT projects objectives that they can not meet, such as leading business change.
• We have no externally understandable view of IT, so we focus on internal efficiencies.
• We do not understand what we have, so we can not value it.

To make IT more understandable, I applied an idea from systems integration and system governance.

One critical (and often overlooked) requirement of systems integration is the need to ensure that systems are resilient and easy to change once they are integrated. This can be achieved by defining the boundaries of each system, and making sure that the internals of each system do not leak beyond their boundaries.

System governance is a method for long-term management of IT. To ensure that all aspects of IT are assessed, it requires that all the IT is presented as separate systems.

These approaches stress the need to define systems carefully. Systems are an important, but undervalued, aspect of design. They are a useful, but undervalued, management handle.

This concept of "systemhood" makes IT much easier to understand. It help non-specialists understand IT, without getting bogged down in technical details. It provides a structure that lets us apply a strict definition of IT, to better understand IT value. It helps us control IT. It helps cut through the misapplication of IT, manage IT in a way that is relevant to its users, and value our existing IT portfolios. A strong assertion of systemhood helps tackle excess demand. Systemhood helps you to work less.

Systemhood has developed as one of the main themes of these newsletters. Next week I will consider whether it is a reasonable concept, and where it might take us in the future.

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

Work less

Don't work harder. Don't even work smarter. Work less.

Before I started Minimal IT, I felt that there was something fundamentally wrong about IT, but I did not know what it was. I decided to explore it, one step at a time, by writing a weekly newsletter.

I started writing about what I felt was the core of the problem. IT is ridiculously expensive, but most IT activity and spend does not deliver value.

We run huge expensive projects to replace existing systems. The business requirement for the projects is often to replicate the functionality of the old systems. Where's the value in that?

We implement generations of systems with similar functionality laid over each other, with interfaces keeping them in step. There is a multiplication of cost, but no increase in value.

We implement impressive technical infrastructures, such as storage arrays, server clusters and middleware. But we often do not need it: most data is redundant, and many servers run at only a few percent utilisation.

I tried to guess how much of IT activity and spend really adds value. I started as a programmer, and I've always had a hands on approach to IT. I know it does not take much to build a database or write a program. My personal estimate is that 90% (or more) of our IT is waste: we get value from 10% of the work, 10% of the code, 10% of the hardware, 10% of the data, 10% of the cost. The rest is at best supporting, but more usually just stuff that gets in the way.

I felt that we do not need to work harder, or even to work smarter. We need to be better at identifying what we do not have to do (the 90%). We need to work less.

We are very efficient at IT supply. We are good at delivering services, running projects, adding new features and implementing new systems. But IT demand is inefficient. We are bad at cancelling projects, removing waste, keeping systems running and decommissioning systems properly. The 90% has its roots in this demand inefficiency.

The other starting point for the newsletters was understanding IT value.

I had been working on a large project with hundreds of unclear requirements. I tried to understand the business benefit the project, but I realised I had no idea how IT ever created value. After some thought, I felt that the the best starting point is a strict view of IT value: all IT value is based on the value of automating the storage, processing and communication of information. We can build on this to create higher-order value (such as supporting strategic direction), but any value that can not be traced back to the storage, processing and communication of information is not a benefit of IT.

So these where my two starting points: reduce unnecessary demand for IT; and use the strict value of IT. Next week I will describe some of the recurring themes I found, and how one principle seemed to underpin all of them.

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

Perfect testing, perfect documentation

If you think of testing and documentation as just tasks on your plan, they will be near worthless. If you rely on them as the authoritative specification of your system, they will be near perfect.

Most IT project plans include testing and documentation.

Often they succumb to project pressures: testing gets shortened, and documentation gets dropped.

When we have the opportunity to do them well, we think of them as processes. We have processes to define and execute tests. We have processes for writing, reviewing and signing off design documents.

But thinking of testing and documentation just as project processes is not enough. We need to take them further.

Many years ago, testing was synonymous with debugging. Testing was a way of removing defects. Ideas developed, and testing became a way of proving that requirements had been met. Ideas developed further with test-driven development. Tests are part of the evolving specification of the system, especially when delivered as automated test packs.

In my experience, something similar has happened with documentation. Years ago we used to write one huge document per project which described every aspect of the design, but which was not kept up to date. As designs have become more modular, the focus of documentation has shifted to the individual components of the system, so that they can be reused and extended.

Testing and documentation have matured from being just a hurdle in the way of implementing a system to being part of the final deliverables of the project. This is a good progression, but we need to take it one step further.

The next step we need to take is to turn our perception of documentation and testing around. Instead of seeing them as something we try to keep up to date, we assert that they are, by definition, the authoritative specification of the system. If the system functionality differs (for example because someone has not updated them after a change), then the system is wrong. This means that there is no such thing as out-of-date documentation or incomplete test packs, just system errors.

To achieve this, you have to rely on your tests and documentation. If you habitually read code before looking at documentation, your documentation will be worthless. If you test modifications just by throwing some production data at the test system, your tests will be worthless. Conversely, the more you use and rely on documentation and tests, the more reliable you will make them.

Treating testing and documentation as authoritative is part of the maturing of IT.

When IT was young, it made sense to dash for growth. Testing and documentation only had to be good enough to get to implementation.

But the dash for growth is over. The emphasis has shifted to the ongoing management of IT. Documentation and testing support the gradual evolution of systems, and are much more important than they were. To be effective, we have to stop thinking of them as nice-to-have parts of projects. We have to treat them as the perfect, authoritative specification of the system. And the more we rely on them, the more perfect they will be.

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

Should IT model the real world?

We assume that IT should be based on a detailed model of the real world. But the best IT is simpler and focuses on the areas of greatest value.

When we learn data analysis, we are taught to model the real world. We create data entities that represent real world entities, like "person". We create attributes that reflect real-world properties of the entities, like "date of birth", "last name" and "first name".

We take this further in object oriented analysis. As well as defining data, we define methods that reflect the real-world actions that can be performed on or by the object.

When we analyse business processes, we do something similar. We map out activities, who does them, and the flows of information between them.

We then take our analysis into design. We design data, objects and processes that represent the world as it is, or as we want it to be.

The larger and more serious the requirements, the more detailed our models. We create fully elaborated data models that can capture every last nuance, detailed object models, highly decomposed process models.

We assume that good analysis and good design requires us to build and then to implement a detailed model of the world, either as it is or as we want it to be. We assume that databases should store every nuance of real-world data, programs should implement every exceptional business rule, and every detailed business process should be automated. The goal of IT is to implement an ever more accurate model of the real world. If we were painters, we would aspire to the realism of Canaletto.

This view is not just wrong, it is potentially damaging.

At its core, IT is very simple. IT automates the storage, processing and communication of information. IT adds value when it does so in a way that is quicker, cheaper or more accurate than people. But there is always some cost involved in providing and using IT. Even if IT cost nothing to implement, it is another thing to think about, and another thing to support. If the IT does not make the activity quicker, cheaper or more accurate, then IT is not just unnecessary, it is damaging. Attempting to automate all the information and all the business processes adds hugely to the cost of IT and undermines the value.

We need to think about this during analysis and design. Of course we should start with a model of the real world, but we should not attempt to capture and implement ever nuance. We should focus on the information activities where IT can add most value. We should carry out "creative simplification" to build systems that present simple, powerful and valuable capabilities. We should be clear about the limitations of IT, and not pretend it can do everything.

Our IT should focus on providing an ever more valuable tool for the real world, not an ever more accurate model of it.

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