Minimal IT logo and link to home page
Research, training, consultancy and software to reduce IT costs
Home | About | Newsletter | Contact
Previous | Next Printer friendly
13 November 2007

Creating joined-up solutions

By Andrew Clifford

You need a simple, shared view of your IT to create joined-up solutions to IT problems.

Imagine you have just come back from holiday, and are sifting through your emails.

  • Your DBA says that your version of Oracle is going out of support next year, and you must upgrade to keep supported.
  • The audit of Business Objects has shown that users make unauthorised access to the underlying data.
  • Your support manager has threatened to resign because documentation is so bad.
  • The ERP implementation has slipped, and you need to run the legacy systems for another 12 months.
  • You have a massive bill to upgrade a proprietary Unix server, which has reminded you that you are not on target for migrating to Linux.
  • One of the operating divisions is having a bad year, and have asked to delay all non-critical spend on their systems until next financial year.

What do you do? Each problem demands investigation, decision and action.

Often we investigate problems separately, and then try to fit the solutions together into an overall work plan. This is a mistake. If you investigate each problem separately, your solutions will not join up. You might upgrade systems that are being decommissioned, or spend money where there is no budget. You might miss opportunities to combine changes and cut down on testing. You do not know the size of the problems, their interdependencies, the priorities, or the business case.

It is hard to create joined-up solutions. Each problem looks at your IT in a different way: by database, development tool, support group, application, hardware, or user department. There is no common language. To create joined-up solutions, you need a view of IT that everyone can understand.

To do this, start with a list of all your business applications, because these are the points at which IT is used. Do not forget that the IT department is part of the business and its applications are business applications too. Describe each application so that everybody knows what you mean.

Document the software and hardware that supports each application, and the service and support processes around it. Call the applications "systems", to show that you mean all the technology and human processes, not just the application software.

Do not worry that your system definitions do not match your technical architecture. This is a management tool, not a design tool.

The system list creates a common language to navigate different views of IT. Because the system list covers all of your IT, mapping your problems to the list shows the size of the problems, and highlights where you need to find out more. It shows you where you can combine solutions into one piece of work, or where to avoid work because systems are being decommissioned. It shows priority areas with lots of problems, and areas that can be left until later. It gives clarity and traceability to justify your decisions. It lets you create joined-up solutions that tackle the problems efficiently and effectively.

This system list approach is the basis of system governance, which extends it into an ongoing management discipline. It lets you build joined-up solutions to manage today's problems, and proactively avoid tomorrow's.

Next: The testing time bomb

Subscription

Subscribe to RSS feed

Latest newsletter:
Magical metadata

We use the term "metadata-driven" to describe IT solutions in which functionality is defined in data. Taking this to the extreme can provide unparalleled levels of speed, simplicity and versatility.
Read full newsletter

System governance

System governance helps you implement high-quality systems, manage existing systems proactively, and improve failing systems.

Find out more