What is a system?

Defining "IT system" creates a powerful tool for IT management.

When I talk to people about system governance, they always ask how I define "system".

I used to gloss over the answer. I though that the concept of system was an artefact of the method, needed to make assessment easier. But slowly I realised that the concept of system is a core part of the method that creates a powerful management tool.

There are three parts to the definition of "system" used by system governance: the definition of IT, the breakdown of IT into systems, and what is included as part of a system.

In a strict sense, IT can be defined as the automation of the storage, processing and communication of information.

This strict definition of IT excludes many IT-related processes:

• Facilitation of business change.
• Internal processes of the IT department, such as project management.
• The actual usage of IT as part of a broader business process.

IT is the technology itself, not the work of the IT department nor the work of the broader business that uses the IT.

To make it manageable, the entire body of IT needs to be broken down into separate, non-overlapping systems. The best starting point is the business applications that are recognised in the organisation. This is never definitive, and breaking down IT into systems always needs some creativity.

A system breakdown should include technical systems. Some technical infrastructure is just a layer of capability, like a database, that only exists as part of another system, and is not a separate system. Some technical infrastructure does have an independent existence, like systems management software, and should be considered a system in its own right.

There are no hard and fast rules about breaking IT down into systems. It is a choice about how you want to manage. It is more important that you clearly define the systems, and consistently use those definitions, than precisely what the system definitions are.

The definition of "system" includes everything that supports the information automation: application software, system software, hardware, and operation and support processes. A system is a slice through the stack of technology and the human infrastructure that supports it.

Operation and support processes are included as part of the system because the IT can not deliver information automation without them. Other IT processes, such as project management and business analysis, are not part of the system because they are not required to deliver automation day-to-day.

The main benefit of this definition of systems is that it makes IT easier to understand. Systems provide a coherent structure that makes sense of all the components of IT: software, servers, databases, support processes, and so on. It provides a structure for communicating IT to a general audience, and for managing the technical details of IT.

This definition is hugely valuable. It distinguishes the provision of IT from other contributions of the IT department (such as business change), which makes each easier to manage. It provides a handle for all technology, operation and support activities. It allows us to discuss IT in a meaningful way with business colleagues.

The concept of "system" is not a weakness of system governance. It is a powerful tool.

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

Standards - consensus or competition?

Standards are too important to be monopolies. We need to introduce more competition into standards so that they can be adopted more widely.

Standards like ITIL, COBIT, and many of the ISO standards, contain excellent material for IT management. But there are problems. The standards are not well understood by many IT managers. They can seem bureaucratic and cumbersome. They are not as widely adopted as they could be, especially in smaller organisations.

Working with standards can be frustrating. Many of them have to be paid for. None of them allow you to freely modify and distribute derivative works.

There are good reasons why standards are restricted, paid-for products.

• Creating and distributing standards is expensive, and needs to be financed. Paying for standards makes people take them seriously. The costs are trivial to anyone who is serious about using standards.
• Creating and distributing derivative works would undermine the rigour of standards, and threaten the revenues from official versions.

Of course there is a downside.

• Any payment, however small, discourages casual use. In large organisations, only specialists bother to make the case for expenditure. The costs can be a barrier for small companies and for individual practitioners. The standards are not opened up to a more general readership.
• Because standards remain the domain of specialists, and specialists are enthusiasts for their subject, there is little demand for more generally accessible standards.
• Although standards can be tailored within an organisation, you can not republish derivatives. There is no way to challenge the standards by promoting variants, other than through official processes.
• Unlike standards which specify products, management standards are products-in-themselves that squeeze out competition and create monopolies in their subject.

The people who develop standards are dedicated and have a passion for excellence. But their efforts are not as widely appreciated as they could be. How can we make better use of all this good work?

Standards have rich processes for contribution, review and building consensus. But to make standards better adopted, we need more than consensus. We need competition. And we can only have competition when we have competing processes for setting standards.

We can introduce competition in standards by reducing restrictions on the creation of derivative works.

Linux provides a model for this. There is a tightly controlled core of functionality (the kernel) which is freely available and used by many competing distributions. Each distribution bundles the kernel with additional functionality for their customers. Some distributions (such as Red Hat and Fedora) concentrate on server management, others on the workstation environment (SUSE, Mandrake), multi-media capabilities (Ubuntu) or ease of use (Linspire). Different distributions have different commercial models, serving the needs of different markets. The core functionality is protected, and there is enough flexibility for variants to meet specific customer needs.

A similar model would allow competition to mould IT management standards to the specific needs of multiple customers, while preserving the critical core.

Would this weaken standards? Every day, managers pick and choose different parts of standards to use in their organisation. Making this tailoring to specific needs part of the standards process will strengthen standards, not weaken them.

Strong, widely-adopted standards need to be free. Standards are too important to be monopolies.

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

Governance or portfolio management?

What do "governance" and "portfolio management" mean, and which should we use when?

A few years ago we needed a name for the method that we were developing. The method involves structured, high-level assessment of IT to identify and justify improvements in risk, cost and quality.

We chose the name "system governance".

We chose the word "system" because the method considers IT holistically. It is not just concerned with application software, or hardware, or support, but how all these come together to form a meaningful whole.

We chose the word "governance" because the method sits logically above day-to-day management. It is a way of controlling and enabling more detailed management work.

The name "system governance" has served us well. It has let us build up a distinctive brand. It places what we do within overall IT governance, and plays particularly well to an audit and control audience.

But the name has problems too.

Some managers see "governance" as unwelcome imposition, that disrupts their day-to-day work. However much we argue that system governance supports day-to-day work, I know some people will misunderstand.

Some governance specialists dismiss system governance because "we already do governance" or "it doesn't follow our standards". By placing the method under a governance umbrella, we risk that our distinctive message is misunderstood.

We have been considering whether we need a different name.

When we started we had considered the name "system portfolio management". Our method refers to the "system portfolio", and our main report is a "system portfolio review report".

System portfolio management is an accurate description. "System" conveys the holistic nature of the method. "Portfolio" certainly applies: systems are significant business assets. "Management" has no overtones of imposition.

Project portfolio management (PPM) is accepted as a part of governance and as a management tool. Using the similar name "system portfolio management" would convey the aim of the method accurately.

When we started we did not use "system portfolio management" because we did not want to be confused as another PPM wannabe. Our message and method are distinct from PPM. We also did not want to discourage using the method for just a small number of systems.

We are now reconsidering our decision. On balance, "system portfolio management" is as good a name. Adopting the name "system portfolio management" would allow us to expand the method to include business functionality, business value and some work planning, which would be good.

We have four options.

• Keep the name "system governance". We have established the meaning of the term. We will just have to keep fighting against the negative view of governance and make sure that we present the method as distinct from other parts of governance.
• Change the name to "system portfolio management". Generally a good name, but we do risk alienating some of the audit and control audience, or those who want to apply the method to only a few systems.
• Use both names. Use "system governance" as we have up until now, and introduce "system portfolio management" as a more outgoing, business-value lead variant of system governance.
• Come up with a totally new name.

What do you think? What do these words mean to you? What would you do?

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

Systemhood's challenging future

Systemhood could challenge project management and service delivery as the basis for managing IT.

In the last two newsletters I have presented the idea of systemhood. Systemhood involves asserting the definition of systems strongly, and using systems as the basis for management. The opposite of systemhood is to think of IT as a complex of technology, IT organisation, IT projects, IT processes, business change and business usage.

Systemhood makes IT easier to understand, and helps us see which bits of IT add value. It helps us control IT, for example by reducing the scope of IT projects that have impossible objectives. It helps us make the case for proactive management of existing IT systems, which reduces long-term costs. Systemhood helps cut out unnecessary demand for IT, and reduce the IT work required to deliver business value.

Systemhood has many potential benefits, but is it realistic and is it desirable?

The main argument against systemhood is that a lot of IT is not structured as separate systems. It is built as layers of technical infrastructure that are shared by many business applications.

I worked for many years as a systems integration specialist. When you integrate systems, it is really important to preserve the autonomy of systems. Autonomy allows IT to evolve in a controlled manner, without hugely disruptive wholesale change. Shared infrastructure layers have their roots in a more technologically constrained past, and are the enemy of autonomy. Although I know some would disagree, I would argue that architectures that are not based on strongly autonomous separate systems are simply weak architectures.

Another argument against systemhood is that it is not flexible, and that it places too much emphasis on internal IT structures, not business. Component-based IT that runs on shared infrastructure is more flexible and a better basis for modern flexible business.

Using IT to enforce business flexibility is a misapplication of IT. Inefficiencies in business operations can not be overcome by implementing less constrained IT. IT can support the richer information flows required for flexible business, but only after business had adopted that change. Modern integration methods mean that even fully autonomous systems can be used in very flexible ways.

Structuring IT as systems is not inward looking. It makes IT understandable and meaningful to a non-technical audience. It encourages strong ownership. Presenting IT as infrastructure layers, IT projects and service delivery processes is much more inward looking.

Although there are arguments against systemhood, there are sound counterarguments in favour.

This brings me to the future of Minimal IT. I want to explore just how far systemhood can be taken. The main "product" from systemhood has been system governance. I have written a lot about system governance as a decision making tool for compliance, cost reduction and infrastructure investment. This has not been contentious because there are relatively few competing ideas in these areas. But now I want to explore whether system governance could be developed into a more assertive framework for managing the business value of IT and for structuring IT work. This is more contentious because these ideas compete with established project management and service delivery processes.

Will systemhood stretch this far? I am not sure. But it is definitely worth exploring further.

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