|Research, training, consultancy and software to reduce IT costs|
Minimal IT newsletters 2005
Though it sounds unlikely, it is possible to cut IT costs by up to 90%. The key to this is managing IT demand. This isn't simply a matter of saying "no", but requires a reappraisal of the nature and value of IT.
Computers remember, calculate and communicate. They are valuable because they are quicker, more accurate or cheaper than people. Sometimes they even make the infeasible possible. But people often claim computers can do things they can't. We need a simple way of analysing claimed benefits to see if they are real.
Computers add value because they help you remember, calculate or communicate. But there are some problems that constantly get in the way of achieving this value. Often the real challenge and real benefit is in fixing these problems, and not in the computer system itself.
Alignment of IT and business is misunderstood. To achieve alignment, businesses should fit IT around their organisational structures, and avoid enterprise IT systems that cut across them.
We often define IT projects before we really understand what benefit they will bring. This makes projects both impossible and unstoppable. To avoid this, you have to fully understand business benefits and change before you think about IT.
The science-fiction staple of the superhuman half-man half-computer cyborg is a good model for our use of computers. But to grasp this power, we need to learn more about the true nature of our computers, take more responsibility for them, and apply some common sense to their use.
To fully realise IT's potential, you need to apply skills of delegation, definition and instruction. These are not specialist IT skills, but the sort of skills you use every day at work or at home.
There are few words in the English language more boring than "filing" and "administration". Tedious though they are, you need to apply these basic office skills if you want to truly master your IT.
IT often tries, and fails, to treat people and computers as if they were the same. This does not give people the flexibility they need, nor computers the definition and proving they need.
50% to 90% of IT costs can be saved by managing IT demand. Nearly all excess demand stems from simple human over-enthusiasm, self-advancement, self-protection and peer pressure. We need to redirect our perception of IT so that our human nature drives us to an ever more efficient use of IT.
IT is full of overused phrases like "alignment" and "demand management". If we really want to reduce IT costs, we have to be crystal clear about our meaning, and avoid ambiguous phrases like these.
Words control how we think. The builder metaphor is appropriate for IT supply, but not for IT demand. IT needs new metaphors, like surgeon, which emphasise responsibility for outcome and not just delivery.
Like any mature political system, the IT industry under represents minority interests and allows only very limited debate. Unorthodox viewpoints, like those of Minimal IT, are crucial as a counterbalance to force debate and keep our use of IT healthy.
Achieving simplicity requires more than wishful thinking. To really keep things simple, you need to deeply understand how IT delivers value.
Most predictions of the future of IT are based on the extrapolation of technological capability or the hopeful self-interest of IT specialists. Predicting the future based on profitability and the self-interest of the majority provides a more realistic view.
Our current idea of IT literacy amounts to little more than being able to use office applications. True IT literacy involves understanding what IT is and how it adds value, and getting computers to work on your behalf.
The first PC revolution provided personal productivity tools to replace the typewriter, calculating machine, fax machine and drawing board. The second PC revolution will let anyone build outward-facing services to present their interests and responsibilities to the outside world.
Outsourcing and decentralisation are often predicted as the cause of death of the IT department as we know it. But the real threat, or opportunity, comes from merging IT into general business management and operation.
Businesses are caught in a tarpit of excessive IT staff costs. The way to escape is to ignore staffing issues and concentrate on the underlying value of IT.
To be valuable, IT change must be linked to business change. To be doable, it must be kept separate. Navigating this paradox requires education, awareness, respect, and a dose of suspicion.
You can only make order-of-magnitude savings in IT costs by reducing demand for IT. You need to focus less on what changes are required and how they will be carried out; and concentrate more on why you believe the changes are necessary.
Identifying which requirements are really driving IT change gives the clarity needed to define small, simple projects that focus on meeting true business need.
IT projects are typically defined to support business change. We need a simple way of checking that the proposed IT changes really will make a positive contribution to the business change.
IT projects fail when systems are not accepted by the business. You can reduce this risk by writing job descriptions to explain what the system will do.
Business alignment is not a vague management aspiration. It is a practical principle for designing systems.
Project management and architecture will not lead to breakthroughs in the use of IT. Like Harry Potter, we have to learn to visualise, strongly desire and confidently grasp where we want to go.
Strong business ownership is critical to the success of IT. But IT has made meaningful ownership impossible. To make ownership possible we need to stop sharing systems and data, and restructure systems so that they align to the structure of the business organisation.
A lot of what we think of as good practice in IT has no benefit, but just adds cost. For example, the dream of an enterprise-wide shared database has caused massive cost and waste over the years.
Test-driven development cuts costs and improves quality, but can be difficult to understand and justify. Thinking of testing as the formwork into which code concrete is poured can help you understand test-driven development and justify its adoption.
Designing systems to meet the needs of your consumers is critical to keeping systems simple and effective. Sometimes this means ignoring the advice of your suppliers.
If we want to reduce costs, we need to improve business' understanding and control of IT. Online games provide some fascinating insights into how we might do this.
System integration is not just about connecting systems, and has nothing to do with networks. It is about balancing the need to get systems to work together with the need to change them independently.
We can use integration to help us change systems independently, but we need to define what we should treat as separate systems. This can be done pragmatically based on technical differences, or more rigorously by looking at how systems support different management responsibilities.
Integration projects struggle because they send the wrong information between systems. Adopting simple rules for data content and structure can greatly simplify integration.
XML is a way of structuring data that works very well with integration. XML is simpler than many people imagine.
Extensible markup language (XML) is ideal as an interface data format. To keep it simple, you need to adopt some simple rules which ignore many of its advanced features.
"We like standards - we've got lots of them" is a good description of most businesses' approach to transferring data between systems. If you want any-to-any integration, you need to reduce the number of different data transfer technologies.
Integration architecture is referred to as point-to-point, as a bus, or as a hub. These are not mutually exclusive architectures, but complementary approaches for different aspects of integration.
Before buying an integration tool, do not just ask "Is this the best?", but "Do I really need it?"
You can document interfaces easily and effectively if you are not too formal, and if you yourself rely on the documentation you have written.
To make integration code simple, flexible and fast, you need to separate technical code from business code, use integration layers wisely, and be aware of different ways of processing XML.
Integrating software packages is easy if you have a clear idea of what you are trying to achieve and if you ask the right questions. But you will have problems if you abdicate integration to the package vendor.
Effective systems integration requires a clear idea of what you are trying to achieve and an awareness of the common problems to avoid.
Minimal IT: research, training, consultancy and software to reduce IT costs.