Back to basics: Standards and open source

Standards and open source are fundamental to reducing the costs and risks of your IT.

Everybody agrees that standards are a good thing. People like open source software because it is free. What is less clear is the effect that standards and open source have on long term IT costs and risks.

One of the main causes of excessive IT demand is technology refresh. This is IT demanding IT; costs and risks without business value. If the functionality of a product is based on standards there is less need to keep to the latest version. And when you do decide to upgrade, the impact is less because the new version will work the same way as the old.

For example, versions of Internet Explore (IE) before IE8 did not follow web standards closely. Upgrading from IE6 to IE7 and from IE7 to IE8 was important because of changes to how the browser works, but the upgrades were difficult. Because IE8 follows standards closely, there is much less of a need to upgrade to IE9, but many fewer issues with doing so.

One of the criticisms of standards-based software is that it represents the lowest common denominator and does not have all the bells and whistles of proprietary software. But if you want to minimise the costs and risks of your IT, this is a good thing. Using more stable, conservative products means that there is less to go wrong, and less opportunity for vendors to force you into expensive upgrades. And with standards, you are not stuck with one vendor. Once you are on IE8, you can switch to Mozilla Firefox or Google Chrome really easily.

The costs of open source software - free - can be very tempting, though in some cases that is offset by higher staff costs to understand implementation. What is more significant is the long-term dynamics of open source software. Because there is no vendor making money from upgrades, there is much less commercial pressure for you to take major, disruptive upgrades. Instead, there will be small upgrades to fix bugs and incrementally improve the product. It is easier to keep on current versions of open source software, without the hassle and expense of occasional major upgrades.

One of the arguments in favour of proprietary software is that you get more "out of the box". I am not sure that is true - modern Linux distributions contain hundreds of software packages. Where I think they differ is the ease in which you can opt for less. It is easy to get a minimal Linux server, which is just what you need for an efficient, secure and low-cost production environment. But with Windows you are stuck with a much larger footprint of functionality whether you need it or not. And all of that needs securing and upgrading. To minimise the extent to which IT demands IT, you need the option of using a much more stripped-down environment.

To minimise cost, risk and disruption, you need to be in control of the software that you use. Standards and open source achieve this in a way that proprietary software, however effective, can not.

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

To improve responsiveness, risk and cost, you need to stop obsessing about systems development.

We are obsessed with systems development. There are huge bodies of work about structured methods. There are huge bodies of work about agile development.

These are all very well and good. They help you deliver new solutions quickly, at low cost and with low risk. However, maintenance costs for IT systems are higher than development costs, and frequency of system replacement is the big multiplier for IT development costs. If you are trying to minimise unnecessary IT, maintenance and longevity are much more important than development.

It is about focus. The focus of all development methods is the same, whether they are traditional, waterfall, structured methods or newer, iterative, agile methods. Their focus is on the development process itself: they attempt to meet requirements with minimum cost and at lowest risk. This is a good aim, but the wrong focus. The costs, risks and responsiveness of systems development are only a very small part of the overall costs, risks and responsiveness of IT. To achieve minimal IT, our systems development should focus on reducing overall costs, risks and responsiveness, and not just optimising the the development process itself.

The key is to think about what the systems development process delivers - systems - rather than the processes by which it delivers them. To get closer to minimal IT, you need to focus on the qualities of the product of systems development, not the qualities of the process.

Other than meeting requirements, the important qualities of systems that are influenced by development are the ease with which systems can be maintained and modified. The three most important are to have a structure to the system that makes it easy to modify, to have automated regression tests that allows change to be made confidently and quickly, and to have documentation which helps people understand the system and which is easy to keep up-to-date. Without these the system will constantly demand more resources than it needs - IT demanding IT without delivering business value.

Processes are important. But the processes used for development are inconsequential when compared with the processes used during maintenance and support. If your maintenance and support processes preserve and enhance the structure, tests and documentation of the system, the system will continue to be responsive, change will be cheap and low-risk, and the system will last for a long time. Conversely, if you don't preserve these during support and maintenance, then your systems will quickly degrade, and become difficult, expensive and risky to change. You will quickly be forced into an expensive redevelopment or acquisition.

To achieve significant cost savings, you need to stop thinking about systems development. Instead of worrying about how quickly and cheaply you can deliver projects, worry about how long your systems last and how cheap they are to maintain. Put your efforts into maintaining effective, non-bureaucratic standards for automated tests and documentation. This is a far better way of improving responsiveness, risk and cost than obsessing about systems development.

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

Back to basics: Proactive IT management

The only way out of the mess of IT is to manage IT proactively.

We understand the term "legacy". As IT gets older it loses its structure, becomes harder to work with, does not keep up with new technology, and does not comply with new standards and regulations.

To me, legacy is the biggest issue in IT. Legacy makes IT difficult to work with and adds hugely to the cost of change. But most significantly, most IT change exists to replace legacy, not to meet new business requirements. Think about the major IT projects in your business. Are they totally new, or is a large part of their purpose, and the majority of their workload, to replace old, difficult, non-compliant IT? Legacy is the greatest driver of demand for IT. But it is value-less demand – IT demanding IT. To get closer to minimal IT, and to significantly reduce IT costs, we have to tackle legacy.

Tackling legacy is not a technical issue. We know what to do. We need to upgrade, refactor, replatform, maintain documentation and tests, manage bugs, and so on. For a small amount of investment, we can keep IT running smoothly without the huge costs and disruption of major legacy replacements. So why don't we?

There are two reasons. First, it is very hard to identify what needs to be done. How can you keep track of everything on all of your IT all of the time? It's almost impossible keeping things on supported versions of operating systems, let alone subtler issues such as ensuring effective business ownership and keeping documentation up-to-date. Second, even if we do identify what to do, how can we possibly justify proactive maintenance? How can it ever take precedence over business-driven change?

I think there is a solution to this problem, using a method which I call "system governance". This gives visibility and justification for proactive maintenance, without incurring a significant management overhead.

If you want detail, follow the links from System Governance for white papers and a process manual. But in summary, to tackle legacy you need gather the right body of information that:

• Presents IT as a set of systems, (see last week's newsletter) because this provides the best management view of IT.
• Is sufficiently high-level to be relevant to management, and sufficiently low-level to connect to the detail of IT.
• Covers everything that is important about your IT: how it is used, service and support, risks, development, technology, and breaks these down into meaningful high-level questions. The business value of each question needs to be expressed.
• Assesses each system against each question, capturing enough narrative to provide context to the assessment.
• Applies consistent calculations to identify what needs to be done, with links to question definitions and narrative to provide justification.

Whether you use exactly this approach or not, you need something like this to tackle legacy. You can not build your way out. If you do not have the information to manage IT, all your new projects, systems, architectures and technologies will themselves be legacy in a few short years. The only way out of the mess of IT is to manage IT proactively.

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

Back to basics: The importance of structure

To overcome the really big problems in IT we need to change how IT is structured.

The first really big problem is that IT projects are difficult, expensive and full of risk. The second is the legacy of old systems which are difficult to work with, run on out-of-date technology, and don't do what business needs.

Although these problems seem very different they can be traced back to a common cause: we structure IT for the convenience of technologists, not for the convenience of business and IT management.

In the past, IT has been expensive and technically difficult. We have found ways to make the best use of expensive resources and to make IT easier to implement. We have arranged IT into shared technical layers (network, operating system, database, application software, user interface) to exploit economies of scale and expertise. We have encouraged sharing of IT capabilities to reduce cost, and use common databases to allow different applications to share data.

We have successfully created structures which are optimised technologically. Buy they are misaligned to business and to long-term IT management needs. Most organisations are hierarchies of semi-autonomous departments defined by function. But IT is structured totally differently, as shared layers of technical capability.

If you follow the trail of cause and effect, nearly every major problem in IT has roots in the IT structures that we typically use. It is very difficult to make the connection between a business change and the required IT changes. This leads to IT-led business solutions, rather than business-led IT solutions. Everything is interconnected, and it is hard to identify and justify what needs to be done to keep IT current and manageable. Systems slip into unmanageable legacy. The sharing and connections between systems are so complicated that every change has a huge knock-on effect. The complexity of IT and the lack of effective business control leads to large, expensive IT projects that are prone to failure.

Read more on IT problem cause and effect.

IT is now much cheaper and we have developed much better ways of managing it. We have the opportunity to move to more aligned IT structures. The ideal is a set of separate, encapsulated capabilities which are meaningful in business terms and which provide appropriate units for IT management.

Although it is technically easy to move to a more aligned structure it is emotionally and politically hard. We have spent decades defending the structures that we have.

The first argument against aligned structures is that it makes it much harder to connect systems. However, modern methods of integration, particularly messaging middleware and web services, allow separate systems to work together seamlessly.

The second argument is that aligning IT to business structures preserves the inefficiencies of current business operations. However, a set of understandable, separate, but closely integrated systems is the best basis for enabling business to optimise processes.

To achieve minimal IT, we need to bend technology around structures that make sense to our organisations and which help us with the really difficult problems of long-term IT management. We need to move on from the structures of yesterday.


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