Why do you work in IT?

Like every profession, IT is driven by the passion and eccentricity of the people who work in it.

The stereotype of IT folk is that they are rational and unemotional. If we were asked "Why do you work in IT?", we would probably come up with a rational, unemotional explanation. Something like how IT skills are in constant demand, good working conditions, well-paid, and so on. But if you looked more closely, especially at people who have worked in IT for some time, you would see another side. Many are not unemotional rationalists, they do their work because of their enthusiasm and the enjoyment they get from their work. Many of us have found a niche, and our real reason is the satisfaction of working at something we believe is truly interesting and important.

We can be quick to criticise other people's specialisms. The project manager who prides themselves on delivering on time and to budget, but cuts corners on quality. The programmer who loves to code, but has no idea of the business relevance of the work. The obsessive DBA who eats, breathes and sleeps databases. The security specialist who constantly evangelises about protecting the organisation, without thinking about the impact on everyday work. The CIO who spends all their time on organisational politics, and does not sort out the pressing issues in their own department.

We criticise our colleagues for their singleness of mind and their lack of balance, much more than we examine our own biases. We should not be too critical, or try to be too rational. It's good that people enjoy their work. Like every profession, IT is driven forward by the passion and eccentricity of the people who work in it.

We do not have to share the passion to get the reward. There is a trickle-down from the passionate eccentric to the broadly useful.

Every DBA tool, every intrusion detection method, every design approach, every programming language, every piece of wisdom about business-IT relationship, has been driven forward by an eccentric with a passion for their specialisation. IT has not been driven forward by the rational, balanced and unemotional, but by the irrational, eccentric and passionate.

When I started out, I was rational. I went into IT because it was easy to get into and paid well. But now I am an passionate eccentric. I'm fascinated by the long-term management of IT, improving its cost, life span, and improving responsiveness to change. I know other people might not share my passion, but that does not stop me believing that what I do is really interesting and important.

And I think there is a spin-off from my enthusiasm. My work on system quality management can be used by others to get a handle on the long-term management of their IT, to understand issues like cost and risk and responsiveness. You do not have to be a believer to benefit.

We should be proud of our passion and enthusiasm. Of course we do need to be critical, and curb the excesses of each specialism (especially our own), but we should not forget what really drives people to work in IT, and how IT is driven forward.

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

Fungibility

Fungibility is a critical concept for managing long-term costs and risk in IT.

Words are the tools of thought and the tools of communication. The right word lets us condense and communicate a difficult concept, and the lack of a good word can make thought impossible.

In IT, we should use the word "fungibility" more. Fungibility describes things that are capable of mutual substitution. For example, a barrel of oil is fungible because it can be used in the same way as any other barrel of oil.

Fungibility is important to IT management. Fungibility reduces risk by giving us options if components fail. By letting us replace failing components, fungibility helps us prolong the useful life of systems, which is important for return on investment.

In IT, fungibility is not an inherent characteristic of components, but a combination of the component and how it is used. For example, the Oracle database is fungible if you limit yourself to standard SQL and standards-based drivers. You can replace Oracle with any other relational database.

If you use the special features of Oracle, such as SQL extensions and stored procedures, then you have destroyed its fungibility. You are locked in, you have undermined your own bargaining position, and you have increased risk.

Standards do not only provide guidelines on how things work well, they also enable fungibility. Without standards, there is no fungibility, and costs and risk increase.

Fungibility is wide and important in IT. We understand fungibility for hardware and system software. It also applies to design. For example, fungibility is important when integrating systems: no system should impact the fungibility of another, which means that all interfaces should be loosely-coupled, and should not exploit nuances of other systems that would prevent their replacement with equivalents.

Fungibility is important in development tools. Compilers for standards-based languages are highly fungible, but this fungibility can be completely undermined if you use a development tool that then ties you in. (I used to evaluate a lot of development tools, and I wish I had known the word "fungibility" to explain my concerns to vendors.)

I am not sure what the opposite of fungibility is, but in IT terms it is often "strategic". I wince when people say things like "Oracle is our strategic database". They interpret strategic to mean that a component will remain forever, and therefore can be used in a non-fungible way. Without fungibility, a technology strategy can be counter-productive to the cost and risk objectives that it is trying to meet.

Fungibility can be applied to people, too. For effective support, its important that support staff are fungible. To achieve this, systems have to be well documented, designed to standards, and not need any unusual skills.

But I do not think we should generally treat people as fungible. People's knowledge, skills, aptitude and productivity are not as interchangeable as many project plans imply. Any project plan with an unnamed "senior designer" resource is treating the non-fungible in a fungible way.

You might well disagree, but you do now have a new word to use in your arguments.

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

Why PCs are not secure

Here in the UK there is a constant stream of scandal as sensitive data is lost by banks, the police, the government, and pretty much everyone else. Rather than being a failure of "procedures", I see this as inevitable because of fundamental problems with the security of PCs and portable media.

I want to cover four problem areas: boundaries; the personal nature of PCs; developing with live data; and system management.

Boundaries are perhaps the best understood. The more places that hold sensitive data, the bigger the boundary that must be secured. Holding copies of data on PCs gives more places from which the data can be compromised.

The personal nature of PCs is a threat. PCs are productive because they bring together multiple features (internet access, email, office applications, portable media) in a way that lets the user decide how the work is carried out. PCs are effective precisely because they are not fully controlled. In this environment, it takes constant vigilance to ensure that sensitive data is not compromised. Locking down PCs, such as disabling USB ports, might help, but ultimately holding sensitive data on a PC is like keeping banknotes in a briefcase - it is just too hard to keep secure.

People want data on PCs so that they can query it as they need. They typically use live data to help them understand the data and develop queries. But to successfully develop queries in this way, you need unfettered access to play with the data, which makes it impossible to fully secure.

To overcome this, we need to design queries without accessing live data. This requires more advanced data analysis and data manipulation skills, but this is an absolute must if we want to query sensitive data without compromising security.

The most fundamental security flaw with PCs is that they take sensitive data outside a managed system. Sensitive data needs to be held in systems with certain characteristics, such as access controls, secure physical locations, logs, and so on. The only way that these characteristics can be enforced is to build them in to the system that provides access to the data, and never take the data outside that environment.

I think that holding sensitive information on a PC can never be fully secure however much we surround it with technology and procedures.

Sensitive data must be held in a properly controlled environment, which in today's technology means server-based systems outside of the control of the user. All access to the data must be through pre-defined and controlled routines. All interfaces to other systems must be similarly defined and controlled.

Where query access is required, the system must enforce rules to prevent leakage. For example, the system should enforce a maximum size of the result set from all queries, to prevent the user simply copying all the data into Excel.

I know this is hard. But the alternative is a never-ending battle to reconcile the irreconcilable - a productive PC under the user's control, and sensitive data that must have additional controls. You might be able to keep PCs sufficiently secure for most confidential information, but for really sensitive data, PC security is just too hard.

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

Managing mergers and reorganisations

To successfully navigate the IT of mergers, acquisitions and reorganisations you need to quickly establish high-level visibility, direction and control across the new structure. Here's how.

In my time in IT, I have lived through many major reorganisations. While working for a previous employer, the company demerged, was taken over, and then swallowed the company that took it over. It bought, and sold, a number of other companies. The local IT department went through numerous reorganisations as the requirements of the broader business (and whims of management) changed and evolved.

We manage this sort of change by combining the separate parts: we implement a new organisation structure, common processes, shared infrastructure, and common standards. This takes a lot of time, costs a lot of money, and is very hard. What can we do to make the process easier?

The method I now present as system quality management started as a technique for helping this type of change. System quality management is a simple method, with three main concepts.

• Present IT as a set of separate systems, rather than a complex of organisation, processes, projects and technology.
• Present IT strategy and objectives as characteristics, or qualities, that these systems should have. For example, the objective of risk mitigation is in part demonstrated by the presence of adequate system recovery plans.
• Assess each system for its qualities, and use the body of information you gather to understand the situation and develop an ongoing action plan.

The beauty of this approach is that it lets you quickly establish consistent management visibility, direction and control across an inconsistent environment. It lets you manage even if the organisation, processes, projects and technologies are all over the place. This makes the method very valuable during mergers, acquisitions and reorganisations.

You can get started with the method very quickly. All you need is a list of information and characteristics of relevance. Some of these will reflect general IT good practice, and some will reflect the specific requirements of the reorganisation (new standards for handling financial information, for example). You can use this to assess all the systems across the new structure. This quickly gives you a tool for overall direction and control. You can identify the areas that are priorities for management, and gather the facts and justification you need to be act confidently.

The real power of the method is that it lets you manage the new structure before you have completed the reorganisation. For example, you can start working towards exploiting shared infrastructure before you have merged operations departments. The method provides co-ordination and assurance that lets you work at different parts of the reorganisation at different speeds, and make sure that it all comes together eventually. In a group-subsidiary arrangement, it lets you set and control the required high-level direction, without otherwise interfering with local IT management.

System quality management evolved as a simple, practical tool for managing heterogeneous IT against a backdrop of major reorganisations. Of course there is more to managing reorganisations than just getting to grips with the IT, but system quality management does make that part of the work much simpler, and lets you direct more of your attention to the things that really matter.

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

What's in your basket?

No IT objective, such as cost reduction, can be managed in isolation. You need to adopt methods that let you manage a basket of competing objectives.

When I talk to people about reducing IT cost, I generally find that they do not actually want to reduce overall IT spend. What they want is to reduce some IT costs and redirect the money elsewhere, typically into new projects. Even if they do want to reduce overall spend, they have to preserve things such as service levels and regulatory compliance. Organisations do not want cost reduction in isolation, they want cost reduction in combination with other objectives.

I suspect you would find the same whatever specialist angle you looked at IT from. We do not want one objective in isolation. We want to balance multiple objectives, such as:

• Speed of change
• Service delivery
• Cost containment
• Risk management
• Compliance
• Fitness to continue to meet objectives in the future

Although we all know this, our management approaches only consider one objective at a time.

For example, many organisations want to improve the speed of change. To do this, they stop all investment on old systems, and divert the money into new systems. This works in the short term, but is counter-productive in the long term. Most IT change builds on what is already there. The difficulty and cost of change is proportional to the complexity of existing systems, which gets worse without timely maintenance. By pursuing one objective in isolation (speed of change) we undermine another (future fitness) which, eventually, impacts on speed of change.

This lack of balance is found in all parts of IT management. Agile development helps responsiveness to change but does not help control. We implement methods that improve control, reduce risk or improve compliance, but these add bureaucracy and costs to change. We reduce costs by cutting investment on old systems, but this undermines future fitness. We implement enterprise architectures to prepare IT for the future, but these can be out of step with the realities of today's business pressures. To be more responsive, we adopt agile methods. And so it goes on. We are stuck in an endless battle of competing management approaches.

To be more effective, you need an umbrella method to resolve these competing priorities at a high level. You need to set priorities for management, specific requirements that must be met (such as compliance), and rules for special cases. You need to know where each management approach should be applied, and where it should be avoided because it would undermine other objectives.

Although it is only a simple method, I think this is where system quality management logically fits. When I talk to people about system quality management, I often start with cost reduction, or risk management, or compliance. But the real value of the method is that it lets you look across multiple objectives and manage them all together in a balanced way. It may not be the last word in joined-up IT management, but I am sure it is a very good first step.

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