What's really going on 1: how we manage IT

We can significantly improve IT value, cost, risk and responsiveness if we understand what's really going on with our IT. To start, we need to understand what's really going on in our IT organisations.

IT really matters. It supports vital business processes. It can save a lot of money and reduce risk. It can also cost a lot of money and introduce a lot of risk. You can use IT to grasp new business opportunities quickly, but IT can also be a major barrier to business change.

Because it matters so much, managing IT well is really important.

IT is also very complicated. It requires the co-ordination of a vast number of concepts and technologies. As well as being very important, managing IT is very difficult.

We have responded to the importance and difficulty of managing IT by splitting IT down. We split it down in three different ways: people, process and technology.

We split IT people down by specialisation. We divide the technical work into a huge number of sub-professions: business and system analysts, projects managers, programmers, architects, systems programmers, network administrators, desktop support engineers. The list is almost endless. Because of the technical complexities of IT, we need to co-ordinate the efforts of multiple specialists to deliver IT solutions.

We split IT work down into processes. We have processes for project delivery. We have processes for service delivery. Defined processes give us some assurance for the outcome of tasks. They also let us capture and reuse the best approaches, and we have built up vast libraries of process expertise.

We split IT technology down into multiple technical areas. We have hardware layers, system software, databases, middleware, application servers, reusable objects, business applications, user interfaces, and so on. This works well with technical specialisms, and allows us to achieve economies of scale by using experts to support the same technical area across multiple IT applications.

We know that IT really matters and is complicated, and we have responded by creating structures of people, processes and technology to deliver IT.

Yet, despite all this management effort, there is still huge room for improvement.

To pick a few common themes:

• There is a huge gulf of misunderstanding between business and IT.
• IT projects, especially large ones, have a dismal success rate by any measure.
• Most organisations have vast, unmaintainable legacies of old systems, demanding a huge slice of the annual IT budget.
• Few organisations feel safe from IT risks.
• Despite massive drops in hardware prices, IT remains stubbornly expensive, often one of the largest areas of expenditure in the organisation.

Within each organisation, different parts of IT have hugely different characteristics in terms of value, cost, risk and responsiveness. Even if you do not agree that there are huge problems in IT, there is certainly huge potential for improving the worst parts up to the level of the best.

Why is this? Why, despite all our management effort, does IT management remain so hard, and and why does consistent, long-term IT success remain so elusive?

Next week I will cover the reasons why we find IT management so hard.

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

Crossing boundaries

I have recently been applying development methods and tools to InfoSec work. The experience has made me realise just how much we can learn by sharing our skills more widely.

My background is in IT architecture, design and development. My company provides methods and tools to help with the long-term management of IT. Because of our background, the methods and tools we have developed are reasonably well architected and designed. The methods we use draw from our background in logical modelling. We have done a reasonable job selecting and integrating the components of the tools that we provide.

Although the methods and tools have been well received for their intended use, we have also had a lot of interest in them for information security (InfoSec) assessments. This wasn't our originally intended market, and it is interesting to see how methods and tools developed for one IT area are received in another area.

In some aspects, such as basic data gathering and presentation, our tools are similar to InfoSec tools. In other aspects, our methods and tools are different, and these differences reflect the differences of background.

To support our general IT focus, we have to bring multiple strands of IT into a single framework. Because of our background in architecture and logical modelling, it seemed obvious to combine everything around a simplified logical model of IT. This is unusual in InfoSec, which tends to work in more detail at individual devices and procedures. Our approach has some advantages for InfoSec, particularly for management-level assessments, and partner consultancy has successfully used our approach to create a very well received multi-standards InfoSec assessment tool.

Similarly, we have to identify policy issues across multiple IT areas. This is complicated and difficult to standardise. Because of our background with development tools, it seemed obvious to us to integrate a specialised programming language for this, and chose a rule-based expert system. This is unusual in the InfoSec market which very much relies on expert opinion. We have had a good reception for our product because it can capture and reuse this expertise, freeing the experts from more repetitive tasks and allowing them to focus on more challenging areas.

I would not claim that our methods and tools totally revolutionise InfoSec, but they do demonstrate that methods and tools that might seem obvious in one part of IT can be innovative and useful when applied to another part.

I am sure there are many similar opportunities. Could the disciplines of object orientation be applied to systems programming, so that servers can be configured more easily by non-experts? Could the standardised, layered model used for networks be applied to development technologies, to get away from the problems with rapid obsolescence?

We talk a lot about breaking down silos in business. But the truth is that in IT we have become so specialised that we suffer from silos too. Skills, methods and tools that are obvious in one part of IT can be a breakthrough in another. We can learn a lot by sharing our skills and breaking down the silos within IT.

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

BOCTOC

I had an idea for a new acronym - BOCTOC - to describe how we should apply IT to business.

BOCTOC stands for business opportunity and change, technology opportunity and change. It describes the order in which we should approach the application of IT to business. I would appreciate your views on whether this a useful acronym.

Business opportunity considers whether there is value in the business doing something. The value may be simple commercial profitability, strategic positioning, investor relations, risk, or other aspects.

Business change considers how the business needs to be different to achieve the value. This describes changes in what the business produces, how it works, how it is organised, or whatever, to achieve the business opportunity. The emphasis is on what the changed business should be like, not how to achieve the change.

Technology opportunity considers how information technology could theoretically contribute to the changed business. This defines IT very narrowly, as a capability that automates the storage, processing and communication of information. It considers what information automation, if any, could support the changed business.

Technology opportunity is not about IT products or the IT department. It does not ask "What package can we use?", or "Can IT project managers be used as change agents?" It is more theoretical, to understand the potential for applying information automation to the changed business.

Technology change is a gap analysis that maps the technology opportunities to the existing IT in the organisation. This produces a list of requirement for new or changed information storage, processing and communication.

There is a strict progression in these ideas. You must understand the business opportunity before you consider what the changed business should be like. You must decide what the changed business should be like before you consider how technology could help. You must understand how technology could help before you can build a list of requirements for technology change.

You can use this approach to respond to business opportunities, by mapping out the IT opportunities and changes once business changes have been decided. The business opportunities are independent of the IT, and the IT organisation should not try to find business opportunities to justify technology change.

This approach also suggests where the IT organisation should be proactive. Some business opportunities are not considered because the costs of running the changed business look like they would outweigh the value. Sometimes using IT makes business changes viable, and there is an opportunity to proactively suggest where IT could be used.

Similarly, sometimes IT enables business opportunities that require changes to business processes, but these are not identified because they do not fall into the areas of responsibility of managers within the current organisational hierarchy. In these cases, the IT organisation might be in a position to identify possible opportunities.

Where IT is proactive, it still has to follow BOCTOC. If IT identifies a business opportunity, its first job is to sell that opportunity into the business at an appropriate level. IT should never try to work bottom up, and try to sell IT projects before the business opportunity has been clarified and business changes characterised.

Does BOCTOC make sense?

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

Advanced IT Management

What does advanced IT management look like?

In IT, we build increasingly sophisticated solutions, and tend to equate "advanced" with "technologically sophisticated".

I recently saw the phrase "Advanced IT Management", and it conjured up images of technologically sophisticated tools, with really clever Web 2.0 interfaces and web services and Ajax and things like that.

I kicked myself for falling into this mental trap. Just because we are in the business of IT, it does not follow that we can only improve management by improving technology. We can make big advances in management that are not technologically sophisticated at all.

These advances go further than following our current methods better. Of course we can apply project controls more diligently, seek out good design patterns, and refine our service delivery processes. But in the work I do, I see some step changes we can make, some real advances, especially in the long-term management of our IT.

We can:

• Halt the decline into legacy. We are good managing projects, and managing day-to-day service delivery. But we tend to let existing systems decline, and they inevitably slip into unsupportable legacy.
• Base technical decisions on business objectives, and communicate technical decisions effectively to a business audience.
• Manage different technical specialisms consistently. Instead of managing each specialism separately - such as design, databases, infrastructure, information security, compliance, architecture - we can manage all of these under a consistent management framework.
• Use numbers, not just anecdote and argument, to manage technology. There is a need for specialist opinion, but to understand value and set priorities, we need numbers. The best technicians may not be the best politicians, and we need a way for them to make a case for their work that isn't just based on clever argument.
• Apply policy consistently. Too often our IT policies are merely statements of good intention, with no way of ensuring they are applied consistently across all of our IT. We need an approach that makes it easy to set a direction and stick to it.
• Manage outcomes as well as processes. Much of our management is process-based, basically checking that people are doing what they are told. We also need to check that the processes are working, and that we are consistently achieving the IT outcomes that we want.

Taken together, these are a significant advance, and nothing to do with sophisticated technology.

I saw the phrase "Advanced IT Management" when we were playing around with ideas for our new Metrici website. We put it on the site as some filler words, to try out layout. We laughed at ourselves for such a bold claim. We do not use advanced sophisticated technology.

But then we realised that we were not being unreasonably bold. The areas in which we specialise are not technologically sophisticated, but they do pursue all the advances listed above. We can, and should, describe them as advanced.

Perhaps one of the reasons we find IT management hard is that we look for improvements in the wrong places. For advances in IT management, we should not look for advanced IT, but look more closely at management itself, and what we need to change to drive it forward.

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

The limits of advanced development tools

Advanced and specialised development tools may be unsuitable for complicated functionality because of difficulties with testing.

I like testing. I try to write tests before I write code, and even when I do not, I make sure I have automated tests for everything before it goes live. Development sometimes take a little longer, but I feel this emphasis on testing is the only thing that guarantees product quality. We have invested enough in our testing to be able to completely test a new version of the system in about one hour. This helps us respond quickly to new requirements, and lets us compete with businesses many times our size.

Last week, our development came to a complete halt because we had absolutely no idea how to test what we were writing. It took us a couple of days to work around the problems, and it made me realise that there could be a similar problem with many other development tools.

We were developing rather complicated analysis routines for our Metrici Advisor service. We write this type of analysis using the XML processing language XSLT. Mostly, this works very well. It handles complicated data sets easily, and allows us to develop with relatively little code.

It is usually easy to test XSLT by running files of XML through a command-line processor. But there can be problems. Although you can modularise the code, you can not run these modules independently. XSLT is entirely driven from its input, so to test each condition you have to craft complete input files.

This is not a problem with simple code and data. But as code and data get more complicated, you need to break the tests down into smaller unit tests. But this is impossible in XSLT which expects complete input data files.

After a couple of days scratching our heads, we solved the problem by using some add-ons to XSLT which allow us to pass test data directly into the modules, without creating large input files for every test condition. This halved the amount of code we needed, and reduced the amount of test data and scripts significantly. Without the add-ons, it would have been virtually impossible to test the code properly.

This problem is not limited to XSLT. It is a more general problem with advanced and specialised development tools. I can think of two requirements for any tool for developing complicated functionality, which these tools sometimes omit.

First, they must allow code to be modularised. A drag and drop development environment may look good, but if you can not create your own modules or objects then they are unsuitable for complicated functionality.

Second, it must be possible to test the modules or objects in isolation, without running a full instance of the system. You need to be able to run individual tests for individual pieces of code with little bits of test data, and build these up to a higher level.

Many modern tools fall short of these requirements. They can still be valuable, particularly for building rich interactive systems quickly. But they may be the wrong tool for building complicated functionality, because, as we found, it can eventually become impossible to test the system properly.

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