Today, tomorrow and for ever

In IT we need to achieve three things: delivery of service today; change for tomorrow; and fitness for the future. Each requires a different management approach.

IT services are critical to the running of our businesses. We have to deliver service today, and every day.

Service delivery depends on implementing effective and repeatable processes. Major frameworks such as ITIL define a complete set of processes for service delivery.

We run projects to support where the business is heading tomorrow.

Projects are not as repeatable as service delivery. Every project is different. The most effective approach is to have a strong method for running projects that takes account of these differences, and then a consistent framework that sits above the project method to balance competing priorities and to control individual projects.

Approaches such as PRINCE/2 provide a strong project approach, and disciplines such as project portfolio management (PPM) provide a framework above this.

But what do we do about the future? How can we make systems last as long as the business needs them? How do we prepare for future changes years before they materialise into projects?

Managing these "for evers" is not the same as managing service delivery or change. We are not yet carrying out any processes, so a process definition approach can not work. We are not yet running projects, so a project method and framework can not work.

The best preparation we can make for the future is to make sure that each and every part of our IT is as fit as it can be for whatever the future might bring. Of course, we do not know exactly what the future will bring, but that is not a reason for inaction. We need to be creative and think what characteristics will best prepare our IT for the future, and then to actively manage our IT to achieve these.

We can prepare for the future by setting and enforcing standards, and by creating specialist roles that focus on different aspects of IT fitness. But a common complaint of everyone charged with enforcing standards or pursuing a specialist agenda is that they are constantly pushed aside because of the pressures of service and project delivery. To redress this, we need to raise the profile of standards and specialist work so that it can compete with service delivery and projects for management attention and resources.

System governance is a framework for the long-term management of IT. It is based on the definition, assessment and improvement of the characteristics of IT systems. It highlights the business case for managing fitness of systems, letting it compete for resources with service delivery improvements and project opportunities. System governance provides a focus and a home for standards and specialist work, and gives these the profile that they need to deliver fitness for the future.

We need a three-pronged approach to IT management. We need a strong process management framework to manage today's challenges of service delivery. We need an effective project management method to deliver tomorrow's changes. We need system governance to manage the fitness of our systems to prepare them for whatever the future might bring.

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

In defence of complexity - part 2

The strongest arguments against simplifying IT architecture involve the role of IT in the organisation. We have to decide whether the arguments for simplification or the arguments for complexity will win.

Continuing from last week, there are subtle arguments against the simplification of IT architecture into independent systems that are aligned to organisational responsibilities:

• Business is not rational. Any attempt to implement a simple architecture will fail because business structures are not clearly defined. (The pro-simplification response is that irrational business does not necessarily require complicated architecture. A "creative simplification" of IT into independent systems is a good model even if business is not that rational.)
• Although most business managers are intellectually capable of managing IT, the intricacies of IT mean that there is a value to specialisation. Specialists will inevitably build architectures that make most sense from their point of view.
• IT is a demonstration of political power and capability, not just a rational response to the opportunities of automating the storage, processing and communication of information. All organisations have to show off, to impress customers, investors and employees. IT is a good candidate for this exhibitionism, and major cross-divisional systems have political benefits that outweigh their practical disadvantages.
• IT delivers value precisely because it does cut across existing business structures. Misaligned, shared IT provides opportunities for creative dissonance. Rational, simple IT might be more efficient in the short term, but in the long term chaotic and overlapping IT leads to a more vibrant and successful business.

We have now come to the end of my heretical journey. I have described the arguments in favour of a radical simplification of IT architecture, and the arguments in favour of retaining current complexity. We need to ask whether the arguments for complexity will continue to hold sway, or the arguments for simplification will overcome.

This is not a silly question about predicting the future. It is a serious question about what direction we want to take.

We can stick with the status quo, and continue with IT architectures designed for the convenience of those who provide IT. We can continue to use IT as a political tool for driving business change. We can continue with our current organisation and management of IT. Our big IT management problems will stay the same: we will battle to deliver major IT projects, fight legacy systems and struggle with skill shortages.

Alternatively, we can radically simplify our IT architectures to create truly independent, decoupled systems that are aligned to organisational responsibilities, and which do not share technology layers with other systems. This will keep IT focused on simple information automation, and out of organisational politics. It will, in time, dismantle our current IT organisation and management, and merge IT into general business management. It will reduce major project failures, the decline into legacy, and skill shortages.

I have shown you my vision of where we could, and should, go with IT. Do you share this vision? If not, what is your vision for the future of IT, and what are you doing to make that future a reality?

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

In defence of complexity - part 1

Although we aspire to build simple IT solutions, many arguments suggest that this may not be possible.

We have been exploring a hypothesis about making IT much simpler. We started with the view that, for good engineering reasons, we have designed systems based on shared layers of capability, and that these are the root cause of major management problems in IT. IT management techniques do not solve the problems and, by increasing our tolerance to them, dig us deeper into the problems.

We can address the underlying architectural problems by encapsulating technology layers inside systems and by aligning IT systems with business owners. This fixes the major problems. In the long run it also dismantles our view of IT as a specialist activity, and replaces it by IT subsumed into everyday business management.

This is heresy because it challenges the technical, managerial and organisational orthodoxies of IT.

There are many counter arguments to this hypothesis. Some of the counter arguments are good, and some are subtle and clever. But I will start with some of the counter arguments that I personally think do not hold water.

• It is not technically feasible, because it does not perform well or does not scale.
• The IT structures we have represent real business choices and not technology choices.
• There is no problem, IT delivers good value.

I think these arguments are wrong because:

• In the past shared layers did provide economies of scale, but improved capacity and falling prices make those economies now largely unnecessary. Where performance or scalability problems remain, these relate to intense processing requirements within a single system. Building shared layers would not help.
• We may have got our business colleagues to agree to the structures, for example to agree to a large shared Oracle database, but this does not constitute real choice. What other options did we offer? Taking a recommendation is not the same as making a real choice.
• IT does deliver good value at times, but in general the costs and constraints of IT are so large that, even if there is no obvious problem, the opportunities for improvement are huge.

Having covered what I believe are spurious arguments, I want to cover some good arguments. These all ask, "Is it feasible and worthwhile?"

• A lot of business data and processing is fundamentally shared. Splitting it out might make some parts of IT simpler, but it would not be better aligned and would create more problems than it solves.
• The problems are caused by the excessive variety of technical solutions and application software. Committing to one large package vendor is technically simpler, and the potential for misalignment is less of a problem than the challenges of managing multiple technical solutions.
• IT is fundamentally hard. In the same way that we rely on doctors and lawyers, we have to rely on IT professionals to bridge the gap between business need and technical implementation. The best designs are the ones that then make it easiest for the IT professionals, which means the shared, layered architectures that we have.

Next week I will continue this argument by covering some of the more subtle forces that encourage complexity.

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

The rise of true eBusiness

eBusiness is not about selling products on the Internet or automating supplier links. True eBusiness goes much deeper and can only occur when the paraphernalia of IT is swept away.

Over the past few weeks we have been considering a possible future scenario for IT, in which IT architecture is radically simplified, and much of traditional IT is dismantled.

In this scenario, IT is closely aligned to organisational structures. IT is easier and cheaper than currently, and IT management is included as part of general business management.

Some might see this as negative because it removes some opportunities to achieve more value with IT. Although there will be some loss (not least to our careers), the compensating gain is greater.

One model for this new scenario is that IT will be thought of like we currently think of staff. To be called a "manager", you should be able to manage staff. Managers delegate responsibility to staff, but retain control of and accountability for their actions. Managers define and control the working relationships between their team and other teams. Our view of IT will be the same: every manager should be able to manage the IT in their area. Managers choose what to delegate to the IT. They retain control and accountability. They define and control interactions between their IT and other parts of the business, whether IT-to-human relationships or IT-to-IT relationships.

IT will merge into the general background of business, like accounts, HR and facilities. IT change will be part of business change, and IT decisions will neither lead nor constrain business decisions.

In this new scenario, there will be opportunities for businesses to explore and profit from new business models, to restructure and profit more from IT. These new business models will not be thought of as IT innovations. They will be thought of as the natural evolution of business. Different business will try different approaches. There will be winners, and losers, and cross-fertilisation of ideas. Those who change their business models to gain the most value from IT will be more profitable and more nimble, and out compete those stuck in the old ways and those who have taken wrong turns. True, deep, eBusiness will evolve when we stop thinking of it as something separate from normal business.

For this evolution to progress, we must take the brakes off IT. We must stop the drain on resources and motivation that comes from massive, failed projects. We must halt and reverse the decline into legacy. We must give control of IT to business.

These problems are largely caused by the architectures we have adopted. Although there are good engineering reasons for the architectures, the business cost of them, and the opportunities from changing them, are huge. If we want to really gain the benefits of IT, we have to sweep away the paraphernalia that makes IT so complicated, and let IT merge into general business management.

Remember that this is just a hypothesis. As the final part of this series, next week I want to summarise the counter arguments to the hypothesis and see whether, on balance, this is what we should pursue.

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

The dismantling of IT

A simplification of IT architecture would have far-reaching impacts across the whole of IT.

Over the past weeks we have been considering a simpler IT architecture, made up of independent systems that encapsulate their technical implementation, and which are aligned with the responsibility structures of the organisation.

We need more debate about whether this simpler architecture is feasible, or desirable. This week I want to put that debate aside, and think about the implications if we can and do adopt this simpler architecture.

The most obvious change is that the new architecture would remove technical layers, such as databases and middleware. These capabilities would of course still exist, but they could be standardised and hidden inside the systems. They would not need so much management, and we would need fewer specialists.

The new architecture would mirror the business structure. There would be no need to map layers of technology to applications to business areas, and there would be no need for enterprise IT architecture.

Many of our current approaches to managing complexity would not be required. For example, we currently use business process management (BPM) tools to show a business process view across multiple systems. But if systems are aligned to responsibility structures, and interfaces represent real flows of business meaning, then there is little scope for adding value with BPM tools.

There would be impacts on projects. Because the IT structure reflects the business structure, the IT response to business change would be more focused, and there would be no IT-enforced impacts from sharing IT between business areas. IT projects would be smaller and more firmly linked to business change. It would also be easier to identify and justify the minor changes required to stop systems declining into legacy status.

There would be impacts on IT management. There would be fewer large IT projects. There would be less need for an IT work plan independent of a business work plan. There would be no need for IT-lead decisions on the value of IT.

Because the units of IT are smaller and simpler, development tasks would reduce. Analysis, programming and testing would be simpler, though there would be new requirements for explicit integration rather than implicit integration through data sharing, and for coping elegantly with data differences between independent systems. The architectural simplification may even allow a new generation of effective end-user development tools, possibly something like multi-user Excel on steroids, properly integrated to all the other business systems.

The impact on IT professionals could be profound. There would be less need for all types of IT staff: technical specialists, architects, project managers, development staff. IT departments may end up more like HR departments, giving specialist advice but leaving day-to-day management with the main business.

This is all just a hypothesis. But we must not reject the hypothesis just because we do not like the dismantling of traditional IT. We need to consider what other types of IT will grow in its place, which I will cover next week.

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