PC holiday checklist

Here's a handy checklist for any PC maintenance you are asked to do over the holidays.

If you're visiting people over the holidays and they know you work in IT, they're sure to ask you to have a look at their PC. Here are some things you might want to try.

Safety first

Make sure Windows Update is switched on, and anti virus is up-to-date.

If there is no anti virus software, or if it is slowing down the machine too much (a problem with Norton), try one of:

• Microsoft Secutity Essentials, a free product from Microsoft
• Avast!, which is free for home use.

These both provide protection without eating up too many resources.

Microsoft Office

If the PC has a version of Microsoft Office earlier than 2007, make sure the Microsoft Office Compatibility Pack is installed to let them read office 2007 documents.

If they do not have Microsoft Office, consider installing the latest version of OpenOffice.org. As well as being a fully-functional office suite, it can read Office 2007 formats.

Windows Live

Some of the Microsoft Live Programs are great add-ons to Windows.

Windows Live Mail is a much more modern replacement for Outlook Express. Windows Live Photo Gallery provides Windows XP with very similar photo features to Vista.

Backup

The most important part of backup is being able to restore important documents, emails, photos and videos if the machine fails. Backup software focuses on backing up the entire system configuration, but is not so useful when it comes to restoring files onto a new PC when you do not have the same or compatible backup software.

I prefer taking simple copies. Show the PC's owner how to compress their documents onto a zip file and copy that to a USB flash drive. If you are handy with batch files, use XCOPY (or on Vista ROBOCOPY) to automate the backup to a removable drive or another PC on the network.

Passwords

To keep passwords securely, install a password manager like KeePass.

Startup programs

PCs are slow to start because of the large number of programs that insist on running at start up. Many of these are unnecessary. Use the msconfig utility, or download the Windows Defender and use the Software Explorer. (There may be problems if you run Windows Defender with Microsoft Security Essentials.) These will show you what runs at startup. A lot of programs install unnecessary startup components (particular Adobe, Apple, OpenOffice, Google). Experiment with disabling these to speed up startup.

Free stuff

There are thousands of fun free programs you could install. Two of my favourites are:

• Google Earth which is a great way of exploring the planet from your armchair.
• GIMP which is a superb image editor for anyone who takes a lot of digital photos.

Keep in touch

I love Skype, and use it all the time for work and to keep in touch with family. If the PC has not got Skype, install it.

This is not a definitive list. But it should be enough to earn you an extra mince pie this Christmas.

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

What's wrong with government IT

The UK government's "Make IT Better" report is deeply flawed.

The Conservative party have published a leaked copy of the Make IT Better report which sets out the UK government's vision for public sector IT.

I am not an expert on public sector IT, but having read the document, I have four concerns:

• It presents an inappropriate IT strategy for the UK public sector.
• It will cause damage to the IT industry.
• It will create a loss of political accountability.
• It will weaken industry standards.

Public sector IT strategy is inappropriate

In the UK, the public sector takes around 43% of GDP, and presumably a similar proportion of IT activity. This is so large that you can not separate public sector IT from the IT industry in general. It is no more realistic to set strategy and architecture for the whole public sector than it is to do so for the entire IT industry. Rather than considering the public sector as a separate entity, the government should focus on policies to ensure a competitive, flexible and viable IT industry for the benefit of both public and private sector.

Damage to the IT industry

In pursuit of economies of scale, the report sets out public sector procurement initiatives for networks, data centres and applications. In the short term these may achieve their objectives, but in the long term a concentration of purchasing power and resultant concentration on a few major suppliers undermines competition in the IT industry. The best way to achieve economies is to ensure there is a competitive, flexible and viable IT industry.

The IT industry is largely supported by small and midsize IT businesses. Large scale centralisation disfavours these businesses and undermines the flexibility, economy and innovation that they bring.

Loss of political accountability

The report refers to sharing services across the public sector, but does not consider the impact on accountability.

We have separate public bodies, councils and authorities to provide accountability. Without this we would have a totalitarian state.

Different parts of the public sector need independent accountability and management. This means they must have separate IT systems. IT systems and IT service agreements must not cut across boundaries of political accountability.

Where data sharing is required, this should be achieved through controlled integration that is open to public scrutiny, and not through data centralisation. Different government agencies should be no more free to share your data without your permission than your bank, supermarket and power supplier.

Weaken standards

The report refers to standards, but does not grasp what needs to be done to ensure that the public sector strengthens standards rather than weakens them. I suggest:

• All public sector standards should be replaced with standards that apply across both public and private sectors. There should be no standards that are "private" to the public sector.
• Where possible, the public sector should contribute to existing standards, rather than create their own.
• Any standards that receive significant public funding should, as a condition of funding, be available for free, allow royalty-free use, and freely permit the creation of derivative works. This opens up the usage and innovation around the standards.

For these reasons, I believe "Make IT Better" is deeply flawed.

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

Rigorous testing

I recently implemented a software release with a significant bug in it. Does this mean my testing approach is flawed?

This weekend I implemented a minor enhancement to the Metrici Advisor service. The enhancement added some new features to assessment forms. I had followed our testing procedure thoroughly, the new version passed all the tests, and I put it live.

I was emailed on Saturday morning by one of our more active users. The assessment form, when accessed from one part of the system, did not work at all.

This particular way of accessing the form is not heavily used, and it fails so gracefully that it is not obviously an error. I do not suppose anybody else had really noticed. The bug itself was trivial to fix - I had missed out a single line on a configuration file. But that is not the point. I still managed to put in a version with a significant bug, and my testing did not catch it.

I was concerned by this. Does this bug suggests that we should change our testing approach?

We have always taken the development and testing of Metrici Advisor very seriously. Our software provides advice on IT management. We have to practice what we preach. As a small company, we have to be able to compete with much larger companies who spend a lot more on development. We have to do things right to survive.

We develop the software in small increments. We rely on test-drive development. We have automated tests for every level of the system: for the underlying code, for high-level services, for stylesheets, and for the user interface. We amend these before or during coding. We rely on the testing 100%. Once a new version has passed the tests, we consider it good to go live.

In some ways, our approach might look unprofessional. We only spend 45 minutes testing the entire system. I have known teams to spend months testing systems of similar size. For minor enhancements, we do not carry out much acceptance testing. Obviously, as this weekend shows, our approach just occasionally misses a bug.

Is our approach flawed? Although the tests are not perfect, the process is rigorous. Once a test condition is identified, either as part of development or because of a bug, it becomes a permanent part of the test packs. The test packs are maintained in parallel to the code. We have invested heavily in testing: our test packs include more than 2500 tests, which works out as one test per 24 lines of code.

We could put more effort into manual testing of releases. But the chances of finding anything that 2500 automated tests have not found are very slim. Every minute that we spend testing manually would be better invested in improving the software and the automated testing. We have only had about 20 software bugs in production in almost four years. I have been reading about test driven design. By using a similar approach, we are achieving defect rates (0.3 defects per thousand lines of code) that are much lower than industry averages.

To answer my own question, I am not going to change our testing approach. Test-driven design and development really works. One bug does not undermine that.

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

The perils of PowerPoint

A compelling PowerPoint presentation is no substitute for proper systems design and project plans.

In theory, there are two ways to run a systems development project.

In traditional waterfall methods, you create formal documents at stages in the project to record the analysis and design, and get them signed off.

In more modern agile methods, you do away with much of the formal documentation. In its place, you collaborate closely with users and deliver working code frequently.

In practice, it is not like that.

Waterfall methods break. The rigid methods and documents are too cumbersome, they take too long, and are abandoned. Except in some organisations, where the methods are followed so rigorously that the whole process gets clogged up and everything is late.

Agile methods go wrong too. The user collaboration and frequent delivery does not happen. The agile mindset has not really taken hold. People just try delivering systems in a rush without proper process and controls.

Either way, the design process breaks. But there is still a need to get management to agree to the design to continue funding the work.

This is where PowerPoint steps in so dangerously. (I am not Microsoft-bashing. I use OpenOffice.org Impress, and the same applies.)

PowerPoint is an excellent tool for gaining agreement. With PowerPoint you do not need to show the detail — just a few references to strategic imperatives, some nice graphics, a few charts. With a bit of clever PowerPoint, you can get management to agree, and the project can continue.

But the problem with this is that the project has not had a proper design review or sign off, because you have not got a proper design. You have convinced someone to give you money, but not on the basis of any substance.

The thing we forget is that waterfall method documents and agile method processes are primarily about design, not about agreement.

The same happens in project management. A convincing PowerPoint is no substitute for realistic planning and project management engagement.

So, if you are using PowerPoint, do not ask yourself, "Will they agree?". They probably will.

Instead, ask yourself, "Can I back this up?" Have you carried out and documented the detailed design? Have you got working code and happy users? Is your plan realistic and have you got the project management organised?

Because if you get agreement, but have not got the substance to back it up, it will come back to bite you. The remainder of the project will be full of misery as you try to bridge the gap between reality and the unrealistic expectations that you set.

And if you are shown a PowerPoint presentation, ask for the detailed documents and plans that back it up. If the presenter does not have any, or they are "still working on it", they will not have thought through the design and plans, and you should not believe a word of what they say. If you agree solely on the basis of the PowerPoint, you will be deeply disappointed with the result.

Of course this is hard. It has to be. IT is hard. But the sooner we wean ourselves off "IT as presentation" to "IT as substance", the better.

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

The silly hat method

Every day at precisely 10am, gather your team. One by one, ask them to put on a silly hat, hop on one leg, and say in a squeaky voice what is their single most pressing problem for the day.

I am sure this method would work. It would provide a forum for communication. The silliness would make it less threatening, and easier to bring up difficult issues. Hopping on one leg would stop the meeting going on too long. It would save time because you would not need written progress reports.

Our IT methods are full of this sort of thing. Our methods work, but they contain a lot of embellishments that are basically unnecessary. You do not have to wear a silly hat to have regular, open, team discussions.

There are many dangers to embellishing our methods. We focus on the embellishments too much, we build bureaucracy around them, and reapply them inappropriately in other areas. But the biggest problem is that it stops us understanding the essential parts of the method.

Our method above would gradually be corrupted. Before long, the only things that people would remember are that you do not have to report on progress, but wearing a silly hat is a good idea.

I have seen this with agile methods. People have walked away with the message "we do not need proper plans and designs", and a with a vague notion that something called a SCRUM meeting would make it all better, if only they had the time to do one.

To avoid these problems, we need to think about the defining characteristics of the method. But there is a catch here. All methods provide defined processes, and encourage good organisation and communication. These are very important, but they are not defining because every method has them in some form.

We need to understand the theories about how the method works, and ways of working based on those theories.

Agile methods contain a lot of good stuff about process and organisation and communication, and there is a huge value in following them. But what are the essential concepts and techniques that make agile methods different, and that must be followed to gain most value? I can think of a few.

• It is hard to understand requirement before the solution is built. Deliver small increments frequently to gain a better understanding of requirements.


• Meeting core requirements and timescales is critical. Let the detail of the solution evolve around these, rather than specifying everything in detail up front.


• There is much more in IT that we could do than we need to do. Focus on the development of the required solution rather than on formalities of the process.


• IT is a detailed and skilled activity. Empower the people actually doing development work to make decisions about the process and product.

I have probably missed some. The important point is to be able to characterise the method by theory and technique, not just by the overall process and the more exotic elements like SCRUM meetings. You have to fulfil the essential characteristics of the method to get the benefits of the method. Otherwise you are in danger of hopping around looking silly.

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

Ubuntu Netbook Remix

The latest release of Ubuntu for netbooks demonstrates the increasing quality and flexibility of Linux.

I have been using an Asus EEE PC 901 netbook for almost a year.

The netbook came with a tailored version of the Xandros Linux distribution. This is OK, and works very well with the netbook. But I found it hard to install all the software I wanted, and a lot of the available software was not up to date.

I played around with other Linux distributions. I tried the Easy Peasy distribution, installed on a removable memory card.

Esay Peasy is based on the Ubuntu distribution, but with a desktop optimised for a small screen. I found this much easier to use than Xandros, but I had problems with the WiFi and the built-in webcam. Over the weeks as the underlying Ubuntu updated itself, the problems with the WiFi and camera went away.

Recently I decided to take the plunge and overwrite the pre-installed Xandros with a different Linux distribution.

I looked around for the most up-to-date distribution, and decided to install the netbook version of the Ubuntu 9.10, known as Ubuntu Netbook Remix (UNR). The desktop is very similar to Easy Peasy.



Even before I installed it, I was impressed with UNR. Like many other Ubuntu installations, you can run the distribution directly from the installation medium without installing it. This let me check that all the hardware worked before I committed to the install.

If you are a Windows user, Ubuntu also has WUBI, a windows-based installer that allows you install Ubuntu from inside Windows, creating a PC you can boot into Ubuntu or Windows as easily as installing any other piece of Windows software. The Ubuntu filesystem is stored in a file in the Windows file system, so you do not even have to mess around with disk partitioning.

UNR has everything you would expect of a modern Linux distribution. It comes with all the normal applications (office, photo, messaging, email, etc), and a software centre to choose from thousands of other free applications. As well as open source software, I had no problem installing proprietary software such as Skype and Google Earth. Everything works brilliantly.

I had previously tested that it supported the hardware on the netbook itself, especially the WiFi and the webcam. But I was really impressed that it worked out of the box with additional peripherals, such as a separate webcam, a digital camera, and a network printer.

In Windows, each of these requires additional drivers. Supporting my camera is particularly impressive - unlike most cameras it does not act as a USB storage device and so requires extra drivers. UNR also correctly identified and automatically installed drivers for my network printer, which I have never managed to do before on Windows, Linux or Mac.

I am sure that anyone using recent versions of Linux has had similar experiences. Linux functionality, ease-of-use, reliability, flexibility and depth of hardware support is improving at a surprisingly rapid rate. Where will it stop?

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

Being awesome

Who do you help to be awesome at what?

I recently read an excellent article by Joel Spolsky on figuring out what your company is all about.

In it Joel recounts some advice about presenting your company mission in the form:

• We help $TYPE_OF_PERSON be awesome at $THING

This approach is really great for IT because it so accurately describes the role of IT. The only purpose of IT is to help people do things. To deliver any value you must be able to articulate WHO it helps to do WHAT. If you waffle on about "strategic enablement" or "information is the life blood of the organisation", you have lost the plot.

I also really like the strong word "awesome". We need to up our game from "enabling" to helping people be "awesome".

It sounded like good advice, so I tried it on our own business at Metrici, and particularly on our Metrici Advisor service. It was harder than I thought, but it was a very valuable lesson.

Trying to think of WHO we help was hard. Do we help managers, consultants, businesses, decision-makers? Yes, we do, but that is a bit too broad. They do not catch the essence of who we help.

And WHAT do we help them do? Gather information, evaluate, make decisions? Yes we do, but once again that is too broad.

After a bit of head scratching, we looked at the name of our own product and figured out our mission.

• We help advisors be awesome at giving advice.

This really works for us, and it sums up neatly everything we do.

We define advice as:

• Recommendations
• Measures
• Assurance
• Evaluation
• Justification
• Priorities

The service helps:

• People who specialise in giving advice.
• Managers who advise their own organisations.
• Anybody who investigates and makes decisions, because they advise themselves.
• Anybody who takes advice.

The advice-giving is awesome because it is:

• Quick
• Rigorous
• Insightful
• Consistent
• Actionable
• Justified

This mission even helps us clarify some misunderstandings.

• Metrici Advisor is not a survey tool. If you just want a quick opinion survey, use something like Lime Survey. If you want to give advice based on information gathering, use Metrici Advisor.
• Metrici Advisor is not a process management tool. You can use Metrici Advisor to advise on your processes, or you can make Metrici Advisor part of your advisory processes, but either way Metrici Advisor does not manage the processes for you.

Clarifying our mission also clarifies which parts of the service need to be given more emphasis in our marketing:

• Reusing libraries of best practice.
• Driving out effective recommendations using the rules engine.
• Linking to background information from anywhere in the tool.
• Producing final reports directly from the tool.
• Customising the standard materials, rules, analysis and reports for each organisation.

Just playing around with a few words has really helped us sharpen our mission, and given us a powerful tool to explain ourselves to our customers and partners.

Try it yourself, for your business, your services, or your software. Who do you help to be awesome at what?

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

Necessary complexity

Necessary complexity is a unifying principle that should underpin our IT management and design.

As you go about your work, what do you think about?

If you are like me, a lot of the time you think about the immediate task. Planning, proposals, design, programming.

But stepping back from the immediate, what sort of concepts do you use to help you think?

This is important for us in IT. IT is pure though stuff. It is an extension of our thinking selves. Like a builder uses concrete, bricks, mortar and wood, what are the mental materials we use when we put together IT solutions for our organisations and clients?

A lot of the mental constructs we use are not specific to IT. We have ways of thinking about time and money and political relationships. These are important, but they would be much the same if we were working in any field.

We also think about the technology detail. We think about how much RAM our servers need, what operating system to install, how to configure firewalls, and the syntax of the substring command. These are specific to IT, but they are not really concepts. They are just the syntax for representing the ideas we have about IT. But where do we get those ideas?

To crystallise the question, what are the mental constructs we use that are particularly related to IT and are not just the detail of the technology?

I can think of a few. Normalisation, partitioning, componentisation. These have analogies in other fields, but their meaning in IT is very specific.

But there is one concept that underpins a large part of this: necessary complexity. It is something we should always think about, something that permeates all the aspects of our IT work.

Necessary complexity can be defined as, "as complicated as it has to be, but no more". Necessary complexity is important generally, but particularly in IT because IT has both the power to simplify and the ability to confuse.

Many of the concepts we use in IT boil down to the pursuit of necessary complexity. For example, we use normalisation techniques to fully represent the semantics of data in a form that can be stored as efficiently as possible. Normalisation is a way of making data as complicated as it needs to be, but no more. Normalisation is the pursuit of necessary complexity in data design.

The same applies to IT architecture and methods. Huge frameworks have been defined for IT architecture and methods to cope with the complexity of the IT task. But these have in many cases gone too far, and there has been a counter-movement to simpler designs and more agile methods. As an industry, we are searching for architecture and methods that are as complicated as they need to be, but no more.

When we are considering what IT response is appropriate for our organisations and clients, we need to think of necessary complexity too. We need to define sophisticated approaches that meet the complexities of the requirements. But often we get carried away with the designs and technology, increasing complexity but not value. We need to take a step back, and make sure that all the complexity is necessary.

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

Programming for Web 2.0

How should we design and code for Web 2.0?

One of our customers said he liked our Metrici Advisor service, but that it needed to be "more Web 2.0".

I was not sure what Web 2.0 meant, so I looked it up. Different people define Web 2.0 differently. It can mean:

• Bold and simple visual style.
• Richer and more dynamic user interface.
• Merging of content with other sites.
• User control over the web experience - "My web, my way".

It would be easy to get diverted into just one of these - a styling make-over, some JavaScript wizardry, some website feeds, or customisation options for the user. But before we looked at individual requirements, we wanted to know whether the underlying software was in a fit state to support Web 2.0, whatever it is.

Like all good web applications, Metrici Advisor separates the underlying logic from the user interface. It also separates the different parts of the user interface: the controller that manages the interaction with the user, the view that determines the content that the user sees, and the visual style for the content (implemented as cascading style sheets, CSS).

The separation between logic and user interface is very thorough, but there were some problems with the separation between the different parts of the user interface.

The view contained extra markup just to support the styling. The styling mixed the visual style, the overall page layout, and the layout of individual controls. This made the style hard to change. We fixed this by removing all style-related content, and restructuring the CSS so that the visual style, page layout, and individual controls are implemented in separate files.

Controller and view components contained hard-coded references. For example, a typical view component outputs a web page which contains references to the actions the user could take. The controller code that responds to those actions contains hard-coded references back to the views. Although the code was clearly separated, it was heavily coupled.

We fixed this by using a file to configure all the pages, and the references between view and controller components. This allows us to reconfigure the service to present different applications to different users. It also allows us to merge content from other sites, or expose meaningful subsets of our service for consumption by other sites.

We introduced themes, which collect together overrides for the standard user interface. The themes let us include the JQuery JavaScript library to provide more dynamic functionality, without modifying the underlying user interface code.

None of these changes of themselves achieve the Web 2.0 requirements, but they make it much easier to restyle the service, to build a richer and more dynamic user interface, to interact with other sites, and to give the user more control. Since making these changes we have created a number of customised versions of the service which have been well received.

Stepping back from all of this, the changes we have made have just been old-fashioned good practice: clear separation of responsibilities, decoupling, and removing hard-coding. Web 2.0 sounds new, but it requires the same disciplines I learnt programming COBOL 20 years ago.

I am still not sure what Web 2.0 means, but I know how to program it.

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

Umami

Like the taste umami, there are aspects of IT management which we all vaguely recognise but which we have not defined well enough to manage effectively.

Since the time of Aristotle, we have subdivided our sense of taste into different individual sensations.

Different traditions have divided taste differently. In the West, we have traditionally acknowledged four primary tastes: sweetness, bitterness, sourness and saltiness.

More recently, based on sharing ideas with other traditions and on better scientific understanding, a fifth primary taste has been acknowledged. In English, there is no word for this taste, which could be described as "savoury" or "meaty", so we have adopted the Japanese word umami. Acknowledging umami, and understanding the scientific basis for it, has enriched our understanding, and given us new insights into how to create new flavours in the food we eat.

What has this got to do with IT management?

IT management comes in rich and complex flavours, but we acknowledge only two primary tastes:

• Projects. These are significant lumps of defined change, characterised by objective and scope definition, planning, work assignment and tracking.
• Processes. These are repeatable, ongoing activities, characterised by defined processes, metrics, and continuous improvement.

There is another primary taste which, like umami, languishes unacknowledged.

This unknown taste flavours a lot of what we do. Here are some activities rich in it:

• IT review
• Software selection
• IT governance
• Information security
• Legacy system management
• Application portfolio management

These can be characterised as systematic investigation, analysis, recommendation, prioritisation and justification. In English, I have struggled to find a good word for this. Perhaps it is "evaluative management", but I will stick with "IT umami" for now.

IT umami is separate from projects because it is not a defined change.

Although it may look like an ongoing process, IT umami is not simply process management in the same way that, say, software change control is. IT umami does not deliver value directly itself, but through the information and recommendations that the activity delivers.

Although we recognise it vaguely, we do not have a well-defined sense of IT umami. We attempt to achieve it through projects and processes. Many projects include a lot of investigation, and yet anything that needs a lot of investigation is ill-defined and hard to manage as a project. Our service delivery processes are peppered with all sorts of reviews, but it is hard to find time for these because of the pressures of day-to-day delivery.

Acknowledging IT umami as a distinct primary contributor to IT management would hugely enrich how we manage. It would give us fresh insights and help us to develop new methods and new tools. It would reduce uncertainty in projects. It would give us better insight and justification for the reviews we carry out as part of service delivery.

Most importantly, properly acknowledging IT umami would help us achieve the things that fall outside our current project and process management. It would give us a clearer sense of direction. It would help us to control and secure IT properly. It would help us halt and reverse the decline into legacy.

But to start we need a better name than IT umami. Anybody?

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

Business Process Management software

Business Process Management software would be much more useful if it was presented more conservatively.

My clients and contacts frequently suggest using business process management (BPM) software, but often I argue against them.

BPM software is used to build applications that automate business processes. A simple example is employee expenses, where an employee submits an expense claim that has to be authorised and then paid. BPM software goes much further than simple workflow, and can integrate IT systems, and view and control process activity.

BPM tools are used to build applications which involve passing information from person-to-person, and person-to-system. They are also good for some types of integration, such as managing incoming messages from other organisations.

Supporters of BPM software have a very ambitious vision. BPM software can transform your business. Managers can create and change processes by themselves, even in real time. You can use graphical tools to design and enforce business rules. You can integrate legacy systems at the click of a button. BPM is the glue that holds your business together.

I argue against this because it breaks a lot of IT good practice. For example:

• Clear system boundaries and responsibilities are vital for IT. BPM thinking deliberately breaks boundaries down and cuts across responsibilities, presenting processes as corporate glue. But in the long term, this means that nobody has clear ownership, and the BPM solution quickly becomes unloved legacy.
• Any business change needs to be carefully managed. There are very few situations where processes could realistically be changed at the click of a button.
• Business rules are an important asset that need to be verified and maintained through time. Visualisation of process flows is helpful, but extending this to a full graphical programming for business rules complicates long-term management. All non-trivial rules and data are best embodied in conventional code and databases.
• System integration requires a lot of discipline to avoid a management nightmare. Interfaces need to be particularly rigorous to work well with flexible BPM software. BPM software that just accesses databases belonging to other systems is unmanageable in the long term and completely inappropriate.

All applications require a mix of process flows, data storage, rules and interaction. When you design a system, you pick a base technology that meets the main requirements. If you have a management reporting system, you base it on database products. If you have a highly interactive system, you base it on web servers. If you have a lot of information flows, you base it on BPM software.

To me, BPM software is a good tool for building certain sorts of applications. But those applications must follow the same rules as any others - they have to have clear boundaries and responsibilities. Because they touch many areas, they need more, not less, focus on ownership, change control, rigorous development and long-term management.

I think that BPM software suffers because it is presented too ambitiously. I do not suppose many people believe the hype. But BPM lacks a more honest, simple, down-to-earth presentation that would help people like me accept it and design with it. If you promote BPM, perhaps a less ambitious vision would be more successful.

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

Living wills

Living wills for IT systems, which explain how they need to be managed at the end of their life, would help us keep them running usefully for much longer.

The UK government has proposed that every bank maintains plans which explain how the bank should be managed if it runs into financial difficulties. The plan shows how the bank's assets can be sold, how its liabilities can be met, and how it can be wound up quickly. These plans, dubbed "living wills", would help regulators quickly assess a failing bank and stabilise the situation.

I have been wondering whether we would benefit from something similar in IT.

IT living wills are nothing to do with business continuity or disaster recovery. IT living wills explain how to decommission a system gracefully, for example:

• After mergers and acquisitions, when a system is no longer required because it is replaced by an equivalent system from the other party to the merger.
• When key technology or suppliers fail, and a system must be replaced because it is no longer viable.
• At the end of a system's life, when the organisation requires a system with greater functionality, a new technology basis, or fewer constraints.

One of the main contents of an IT living will would be a list of the business processes that are supported by the system, and other systems that take data from the system.

This would be difficult to document. The links from older systems are like spaghetti. Commentators have pointed out that banks will need to simplify their corporate structures so that they can write living wills. I see parallels in IT, where the need to record what a system supports would drive simplification.

An IT living will would explain how the business assets in the system, the information and business rules, can be recovered.

Most corporate information is held in databases. The data needs to be exported in a simple, understandable form that could easily be taken into another system, or even into a simple spreadsheet. A database dump will not do. The living will would have to explain how to resolve the complicated structures used inside the database into much more understandable business data.

Recovering business rules is really hard. Reverse engineering code would not be acceptable. We would have to maintain good written specifications of all key rules.

A living will would explain how the main parts of the system interact, and how they could be replaced individually. It would be easy to explain how to replace a database if you have used standard SQL, but impossible if you have used vendor-specific extensions.

IT living wills would encourage a lot of good management practice. They would force systems to have simpler connections, data and rules. They would help us spot technology dead-ends. Paradoxically, planning the end of systems will help keep them running usefully for longer.

But IT living wills go much further than just good housekeeping. Existing systems are a major constraint on business change, and living wills would force us to make systems easier to change and to decommission. If we really want to take business forward, perhaps we should start by planning how to turn off the IT.

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

Do you know what business you are in?

We are so obsessed with service and business focus that we forget the special role that we have within business.

"Service is our business"

I saw this slogan on the side of a car wash company van. It is a fine sentiment, and often repeated. Giving good service is a vital part of any endeavour.

But there is a bit of a lie in the slogan. I suspect that their business is actually something to do with car washing.

In IT, it is not just the term "service" that confuses us. We use the term "business focus" in a similar, vague, way.

I have two concerns.

First, terms like "service" and "business focus" are not precise, and different people interpret them in different ways. For one person business focus might mean making a land-grab to lead business change projects, to another it might mean publishing weekly help desk statistics.

Second, these sentiments can cover up vagueness about what our role really is. We can seem truly business-focussed, and give great service, but completely abandon the role that we should be taking.

I will give some examples.

I once knew an IT service department that had a business focus initiative. There was a poster and slogan competition. But I certainly had no idea what they meant by "focussing on the business". The job of an IT services department is to deliver IT reliably, at low cost, and at low risk. Doing that job well is surely business focussed. Working with your business colleagues to understand their needs and constraints is part of that, but you must never forget what you role in the business is.

I see the same problem in project management. Project management has become a political game: making alliances, managing expectations, getting close to the business customer. Fine, but at the end of the day your job is to tease out valuable requirements for IT and to deliver IT solutions that meet those requirements. In the name of business focus we have shifted toward business change projects, but taken our eyes off the underlying IT delivery. Rather than defining manageable IT projects, we embark on woefully unrealistic business-IT change projects that are doomed to failure.

How do doctors work? Building good relationships with your patients, listening to their needs, is important. But your job as a doctor is to diagnose and treat disease. Sometimes this involves giving bad news, or suggesting unpleasant courses of action, or changing courses of action that are not working, or telling the patient that you do not know what is going on. Any doctor who shied away from this would be abandoning their calling. But in the name of "service" we constantly hide reality from our business colleagues.

I am not suggesting that we should abandon the ideas of service and business focus. But these have to be pursued in a context in which we have a very clear idea of the contribution that we are called to make. Our role is to advise on IT and deliver IT solutions. If we forget that, no amount of service and business focus can redeem us.

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

Wrapping infrastructure and architecture 2: how

A management model based on systems and qualities provides a wrapper that makes IT infrastructure and architecture easier to manage

To make management easier, we wrap money, activity and service delivery in management models, such as budgets, projects and SLAs. We need to do the same for infrastructure investment and architecture.

We need to start by considering why we care about infrastructure investment and architecture. In the long term, these have a big impact on the value of what is delivered, on its cost and risk, and the ease with which new business changes can be accommodated.

We need a way of modelling this long-term value. It is not to do with "spending within budget", or "delivery on time and to budget", or "repeatable low-cost service excellence". A better model is to see IT as an asset, and infrastructure investment and architecture are ways of maintaining and improving the value of the asset.

It is hard to measure the value of the asset directly. It is hard to understand the business value of the processes an IT system currently supports, and to disentangle the contributions of IT from human resources, finance and so on. It is even harder to understand how the management decisions you make now will impact value in the long term.

The best we can do is to model long-term asset value by using a set of characteristics, or qualities, that act as indicators of likely long-term value.

To give an idea of practicalities, I will outline what we do in our Metrici ESQM method.

We do not deal with the whole of IT as a single asset. We split IT down into a series of assets that people recognise, typically using the granularity of business applications. We call these assets "systems", where each system includes all the technology, process and people required to deliver the services from the applications.

To establish measures, we agree a basket of qualities that are indicators of likely long-term value, and which are impacted by infrastructure investment and architecture. For example, we might consider clarity of ownership, ease of change, scalability, consistency with corporate standards. We also capture key management data such as strategic importance.

We assess each system against each quality. This gives a view of the likely long-term value of the assets, and shows risks and opportunities where infrastructure investment and architecture can have an impact.

This approach is simple and effective. It gives simple numerical measures. Because it is based on assets that people recognise (such as the "Sales System"), it is easy for business colleagues to understand. It shows which systems are good and bad, and through time shows which systems are improving and which are failing.

Importantly, this model provides the wrapper we need for parts of IT management that we find difficult. It wraps infrastructure investment and architecture using in a simple management model (systems, qualities, assets, value), and leaves the detail (server purchase, routers, architectural standards, systems design) to the managers involved.

It is not a perfect model, but neither are budgets, projects and SLAs. But it is a good-enough model that can improve the management of infrastructure investment and architecture to the levels of maturity achieved in other part of IT.

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

Wrapping infrastructure and architecture 1: why

Make IT infrastructure and architecture easier to manage by wrapping it in a management model.

What do we manage in IT, and how do we manage it?

We manage money. We negotiate purchases, raise orders, manage invoice payments. But at a higher level, we do not talk about individual purchases, orders and invoices, we talk about budgets. We use budgets to set spending limits and to control expenditure. We use budgets as a way of wrapping up money to make it easier to manage, leaving the detail of the management to the managers involved.

We manage activities. We plan work, assign tasks, manage resources, control progress. But at a high level, we do not talk about individual tasks and resources, we talk about projects. We use projects to wrap related work into meaningful units of change, making them easier to manage, and leaving the details of management to the managers involved.

We manage the delivery of services. We run operational schedules, run help desks, contract offsite services, purchase connectivity, and so on. But at a high level, we do not talk about schedules, staff, offsite services and connectivity. We use wrappers like Service Level Agreements (SLAs) to embody a set of service requirements and to manage and control their achievement, making them easier to manage, and leaving the details of management to the managers involved.

In each of these cases, we create a wrapper to help management. Instead of dealing with the detail, we create a management model that hides the detail. Budgets, projects and SLAs are not perfect, but they are much better than dealing with all of the detail all of the time.

Some parts of IT have not got wrappers. We have not got good wrappers for the long-term management of IT, for infrastructure investment, for architecture. To a small extent they are managed within other wrappers. But mostly, we try to deal with them as they are. We try to get justification for a new storage array, try to make a case for improving documentation, or get business sign-off for an enterprise architecture. However much we try to make these business-facing and high-level, we are stuck with trying to manage them naked, without a wrapper to make their management easier.

We need a wrapper for these other parts of IT. We need something that allows us to record requirements for them, and to manage and control these aspects, without getting into the detail all of the time. We need something that helps us have meaningful conversations with our business colleagues.

What should this wrapper look like? The other wrappers are high-level abstractions that represent the main thing that management is concerned about, but which can contain and structure the detail reasonably well. What sort of high-level abstraction do we need for the long-term management of IT, for ongoing infrastructure investment, or for architecture?

We need a new wrapper, separate from budgets, projects and SLAs, to help us manage these other parts of IT better.

Next week I will introduce what I think this new wrapper should be.

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

The culture of dishonesty

IT project management is submerged in a culture of dishonesty.

I am a rubbish project manager.

I can define work, run teams and meet deadlines well enough. But when I have worked formally as a project manager, I have been decidedly second-rate.

After years of pondering my failure, I have concluded that the reason I am a rubbish project manager is that I am just too honest.

There are four parts of project management I struggle with: hiding behind formalities, false certainty, deliberate omission and not finishing.

I am no good with the formalities of project management: plans, resourcing, sign-off, change control. No sooner have I started on a project plan than I see problems with it, and take the project in another direction. I am very open, and discuss this with my sponsor, but I tend to forget to follow up with all the right formalities. When things go wrong, I have not protected myself enough, and I get the blame.

If I am not certain about things, I let on. If I am asked how long things will take, and how much they will cost, I say what I know. "Somewhere between six weeks and one year, somewhere between ten thousand and a million." I never give the sponsor a warm glow that they are dealing with somebody who can see the future.

I blurt out the limitations of the work. "We are just doing the integration, nobody is looking at the reporting." Get me to run a project, and you will get a big list of all the things I am not doing.

Although I mess up lots of things, I am OK at meeting deadlines. If I am given a firm date, I assume it is there for a reason, and focus on delivering the core of the solution on time. But as often as not, I miss out half of what they wanted.

I am not being facetious when I say that I am a rubbish project manager. I come across as vague, lightweight, blameworthy. Project management requires special skills of communication and brinkmanship, gradually coaxing commitment from the sponsor. Project management is a dance: I keep tripping over my neurotic honesty.

If you are a project manager, should you follow my lead and be more honest? No, not if you value your career. In most environments, you have to manage the truth and cover your back.

But if you sponsor or commission projects, or manage project managers, be on the lookout for dishonesty. Do not ask for certainty, and certainly do not believe it when you see it. Look beyond the project formalities, and ask "So what?" What do all those plans, budgets and procedures really mean? Ask the awkward questions, like when can the old system be decommissioned, not just when will the new system be built. Do not impose firm deadlines unless you have to, but if you do make sure the project manager knows it is real, and check they are managing to it.

We reap what we sow. If we want to improve on our dismal project success rates in IT, maybe we should start by being a bit more honest.

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

Knowing when to start finishing

To meet deadlines, we focus on accurate estimation and tracking. We often overlook the important skill of knowing when to start finishing.

How long does it take to do something?

In simple cases, like shovelling a heap of sand, there is a direct relationship between the size of the task, the number of people, and the time it will take. If one man can shovel a ton of sand in an hour, then two men can do it in half and hour, and six men could shovel twelve tons of sand in two hours. Managing this sort of task is easy - just size up the task, divide by the number of resources, and make sure they keep going.

We use this effort-driven model a lot, but it is often inappropriate. It only works when we know the size of the job, when the task has a definite point of completion, when we can determine a rate for the job, and when the only thing required to get the job done is suitably skilled resources.

Most tasks are not simply effort-driven.

Discovery tasks, like finding a bug in a program, are almost impossible to estimate. It might take 10 minutes, or 2 days, or 3 months. You might be able to define an average, but tracking individual tasks against this average is meaningless. If things are running late, it might be worth getting someone else involved, or maybe postponing the task until later.

Open-ended tasks, like report writing, are probably the most common. How long does it take to write a management report? You could write a two line summary in five minutes, or a one-pager in a day. In a week you could talk to a few people and perhaps produce a few sides. An in-depth report could take four weeks. You could take years to analyse the situation in detail.

I have often been asked to finish reports and design documents that other people have struggled to complete. Those originally responsible were failing because they did not know when to start finishing.

Consider a project architecture document. The document is not meant to be a definitive account of everything, but enough of what is known and key decisions to guide the detailed design as much as possible. The temptation is to keep investigating, keep looking for detail, until you are sure, and never to commit what you have to paper and never to finish the task.

To finish an open-ended task on time you need know when to start finishing. If you have to write a report, you have to know when to stop investigating and commit what you know to paper. If you have a week to write a report, spend three days finding out what you can and spend the morning of the fourth day writing this up. That gives you a day and half to find out the most important parts that you have missed, and to make the document as presentable as you can.

Instead of estimating open-ended tasks, you just need to set a reasonable budget of time, and stick to it. There is no need for contingency, and no excuse for late delivery. You just need to know when to start finishing.

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

Ryanair

We can learn a lot from the business practices of Ryanair, both bad and good.

I decided to take a short break and visit the Republic of Ireland. I booked flights with Ryanair.

Ryanair is a very successful budget airline. It offers very low prices, but when you come to book a ticket, you are presented with a number of notionally optional, but entirely necessary, extras.

For each person on each flight you have to pay a £5 card handling fee, unless you use the rather uncommon Visa Electron card (I later found how to avoid the Ryanair card handling fee). You usually have to pay a £5 online check-in fee for each person on each flight. So each return flight costs £20 more than the headline price. Checked-in baggage is an expensive extra.

As well as the disingenuous hidden charges, additional charges if things go wrong are downright predatory. If you forget to check-in online, it costs £40 per person per flight to check-in at the airport. Changing a name on a flight costs £100 to £150. Excess baggage costs £15 per kilogram.

I had not booked on Ryanair before, and I found the whole process bewildering and stressful. I felt that they were trying to rip me off to start with, and extort me later if I hit problems.

I was going to write about the parallels between Ryanair's practices and IT project management. How we sell projects on low headline prices, in the full knowledge that they will really be more expensive. How we are predatory if our business customers want changes later in the project.

I did some more research into Ryanair. Although I still think that Ryanair are disingenuous and predatory, I now partly admire them.

Ryanair does everything it can to keep costs down and pass this on to their customers. Where costs seem high (such as baggage costs, or in-airport fees), they are trying to show people where the true costs are, and encourage them to take cheaper options.

Like other low-cost airlines, Ryanair avoids the costs of traditional, full-service airlines. But Ryanair goes further than most. They constantly battle airports and public bodies over fees and taxes, and withdraw services from airports over seemingly small amounts. Rather than work within industry norms, Ryanair constantly pursues value for their customers.

We can learn a lot from Ryanair.

We should avoid disingenuous and predatory pricing, knowingly or negligently giving low project estimates and inflating costs later.

But there is a lot we should copy from Ryanair. We should be prepared to break out of the traditional, expensive full-service model of IT and show low-cost alternatives. We should show where the money goes. We should show the true costs of business decisions, indecision, lack of business ownership, last minute changes, underinvestment.

And we should constantly battle to lower costs. This means breaking away from industry norms, constantly exploring new ways to save money, and constantly challenging suppliers to reduce costs.

Love them or hate them, we have a lot to learn from Ryanair.

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

Ban project management!

Make a great leap forward in the management of change by banning projects and project management.

Project management is an obvious way of managing change: it allows you to set objectives, define responsibilities, organise and control the work. If project management never existed, we would have to invent it.

What if project management did not exist, but we were not allowed to invent it? What if projects and project management were banned?

This is not a serious proposition, but it is very thought-provoking.

If projects were banned, everyone would be less enthusiastic for change. You would have to take good care of the systems and infrastructure that you already have, making sure that they were always in good condition, and continued to meet evolving business needs.

Sometimes you would need more than just incremental change. You would have to do this as additional work within existing teams. You would have to put a lot of effort into explaining and discussing the benefits of the change, and into persuading different groups to work in the same direction.

You would not be able to publish a project plan, so you would just have to keep talking to everyone. You would need to understand what each team does, and what new things they would need to do to support a new business direction. If they did not agree then you would just have to negotiate or find another way.

Even if other teams did support your change, fresh priorities would come along and throw them off course. You would need to keep talking to them, and continually remind them of the benefits of your changes. Sometimes you would have to postpone your changes because other more important work takes over.

Resourcing would be a real pain. You could not just assign skills from a resource pool. You would have to find the individuals who were going to do the work. You would have to explain to each one of them what the change was about, and exactly how you wanted them to contribute. You would need to get their individual commitment for when the work could be delivered, and encourage them to be as realistic about this as possible. You would have to work out with them how they could balance the competing priorities of their current work and the additional work.

If you needed to modify your changes, then it would be chaos. You would have to go around and talk to everyone again, and understand all the impacts, and gain new commitments for when things could be delivered. Moving a few bars on a Gantt chart would be so much easier!

I am not seriously suggesting that we should ban project management. However, we often forget that project management has to boil down to practical realities. We hide behind the formalities of plans, budgets, sign-off, resourcing and change control. But these are only as good as they can be made to work for real. Imagining a world in which project management is banned shows us more clearly the behaviours we need to manage projects successfully.

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

Winnie The Pooh, writers block, and the problems of IT

IT is so mentally demanding that we do not get the opportunity to think how to improve.

Here is Edward Bear, coming downstairs now, bump, bump, bump, on the back of his head, behind Christopher Robin. It is, as far as he knows, the only way of coming downstairs, but sometimes he feels that there really is another way, if only he could stop bumping for a moment and think of it.

This opening paragraph from the Winnie The Pooh by A A Milne sum up so eloquently how we live. We are so busy bumping backwards down the stairs of life that we never get the chance to stop and think of a better way.

I have noticed this recently, writing these newsletters.

When I started, I had decided to take some time out to think through ideas that had been buzzing about in my head, and to gradually turn these into methods and tools that could form part of a business.

These newsletters have been a record of that journey, helping me to develop and articulate the ideas.

But in the past few months, writing these newsletters has got a lot harder. I am a more proficient writer (that just comes with practice), but I have not had such a good flow of ideas.

And I know the reason why: I have been busy.

Little by little, despite our inexperience, we have managed to generate more and more interest in what we do. Instead of having occasional contacts, we are talking to people all the time. And they want difficult things from us - like actual work - not just a chat about ideas.

You might think that all this activity would give me lots to write about. But you would be wrong.

I have found that my mind fills with the immediate demands of the situation: finding customers, creating plans, doing work, meeting deadlines, navigating politics.

This has crowded out the broad, general ideas that used to fill my mind, and contributed to writers block for this newsletter.

Having the time to think gave me insights that I would not have gained had I continued bumping backwards down the stairs of life. It let me critique the approaches and limitations that I had previously accepted, and find new ways through.

As I rejoin the real world, I am losing that perspective. Although I am more focussed, more "switched on", more professional, I have lost some of my free thinking. Inevitably, I have fallen back into accepting the common ways of working, and the problems and the limitations of those around me.

IT is hard and it fills our minds so much that we simply do not have enough mental bandwidth to critique how we work, and how to overcome the problems we face. In so many ways, we are, as an industry, bumping downstairs backwards. We need to find ways to stop bumping, and to free our minds.

I am going to do my bit. I am going on holiday.

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

Process maturity and value

Process maturity models must be supported by a simple view of how value is delivered.

The Capability Maturity Model (CMM) is the best-known process maturity model. It was initially developed to evaluate software providers for US government contracts.

The CMM defines five levels of maturity:

• Level 1 - initial - no defined processes
• Level 2 - repeatable - the organisation generally produces repeatable results
• Level 3 - defined - the organisation has defined standard processes
• Level 4 - managed - the organisation uses metrics to manage processes
• Level 5 - optimized - the organisation optimises and improves processes

In theory, organisations working at higher maturity levels are more efficient and have fewer risks.

CMM was initially targeted at software development. Now there are maturity models for nearly every specialism in IT, such as project management, people management, service delivery, information security, enterprise architecture, and so forth.

Process maturity models are useful for activities that have clear objectives and which are repeatable, such as programming to specification, or day-to-day service delivery. However, process maturity models have many limitations:

• Process maturity models focus on how things should be done, not what should be done. The focus on how, not what, is less useful when objectives are not clear.
• Process maturity models use institutionalised knowledge. Many situations need innovation and personal experience, not just institutionalised knowledge.
• Defined processes can lead to inappropriate solutions. For example, organisations with defined processes for software development tend to see software development and the solution to every problem.
• Defined processes underplay the softer side of management. Success depends more on getting close to the business customer than it does on efficiently churning out code.

Processes try to deal with these limitations. There are processes for gathering requirements, designing solutions, and communicating with stakeholders. But the very fact that these are presented within a process framework makes them subservient to the framework, as if they were just part of the bureaucracy involved in getting on with the real work of programming, or whatever.

I am not against process maturity models, but they are just a tool for delivering value. If you can not see the connection between your processes and value delivery, you can not deliver value.

One way of making the connection is to start with a simple, generic view of how value is delivered. Something like:

• Describe simply what are you trying to achieve.
• Understanding what you really must do to achieve this. This is not "list all the tasks that you can think of putting on a project plan", but is about the mechanisms that must engage to deliver value.
• Break down the required work into manageable chunks.
• Execute the work as proficiently and efficiently as possible.

If you can see how your processes achieve this, albeit in a better defined and more formal way, then there is a good chance your processes will deliver value.

But if your processes are obsessed with formalities and obscure the underlying value mechanism, then the processes, however well-defined and mature they may be, can not deliver value.

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

The rise of the netbook - power to the people

Netbook computers are fast becoming mainstream. Their success shows the power consumers have over the major technology providers.

Netbook computers are small, portable, cheap computers which are optimised for simple internet-based tasks such as surfing the web and email.

The rise of the netbook has been meteoric. A year ago, in mid-2008, they were a rarity. Now there is a huge selection in all the major retailers.

The prehistory of the netbook can be traced back to the One Laptop Per Child (OLPC) project and early small computers by Psion and others. But the first widely sold netbook was the Asus EEE PC, which launched in 2007.

Because they were not powerful, early netbooks from Asus and others ran variants of Linux. Microsoft had announced the end of Windows XP, and netbooks were simply incapable of meeting the demands of Windows Vista.

The Asus EEE PC was so successful that all the major technology suppliers had to take notice. Microsoft, seeing the rise of Linux netbooks as a threat, resurrected Windows XP and licenses it at low cost for netbooks. All the major PC suppliers have brought out netbook models. There are now a huge variety of netbooks on sale, nearly all of them running Windows XP.

Netbook hardware has improved. Early netbooks had 7" to 9" screens and tiny keyboards. Most models now have a 10" screen, and a keyboard which is almost as big as a typical laptop, or in some cases bigger. By my measurements, the width of the main keys on the 10" Toshiba NB200 netbook is greater than on the 15" Toshiba A100 laptop.

Battery life has also improved. Many models now have 6-9 hours battery life, long enough to use all day without a charge.

Netbooks have become mainstream very rapidly. When I bought my first netbook at the end of last year (an Asus EEE PC 901 running Linux), they were still more of a geeky toy than a serious computer. Only half a year later, I am in the process of buying one for my son's school work (likely to be a Toshiba NB200 running Windows XP), and the shops are full of them. Netbooks are still less powerful than "proper" laptops, but many people do not need that power and are looking at netbooks as a convenient alternative to a laptop.

This trend will continue. Netbooks have shown that people demand low cost and portability, and competition will force the major suppliers to meet that demand. In the not too distant future, the distinction between netbooks and "proper" laptops will disappear. There will be cheap, portable computers of all sizes, with enough power for most tasks.

For years, Microsoft and PC manufacturers have been telling consumers that what they need is more advanced operating systems and faster processors. But netbooks have shown that the consumer can, and will, push back with they really want - low cost and convenience. If there is a moral to this tale, it is that the consumer is king.

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

Power*Architect

Power*Architect is a free, open-source data modelling and database design tool that is easy to use and packed with features.

I am working on a data warehousing project, and need to produce data models and database designs. It is a small project, and we can not justify enterprise-class tools, such as IBM Rational System Architect or CA Erwin.

We thought we would use a drawing tool such as Microsoft Visio, but then we came across Power*Architect from SQL Power, which is free and open-source.

Power*Architect is a data modelling and database design tool. Like all such tools, you create a graphical model of your data and define tables, columns and relationships.

Power*Architect does much more than just draw pictures. It generates databases from your design, and supports all the popular databases such as Oracle, SQL Server, DB2 and MySQL. It captures existing database structures so that you can view and change them. It compares databases and models, and generates the scripts required to modify one database to match another, which is very useful during maintenance.

We have been using Power*Architect for a few days. It is very easy to use, and very reliable. It is good at layout, and has easy-to-use print features and reporting tools. We have used it for both logical data modelling, and for capturing existing database structures. We have tested the database creation and modification tools.

Power*Architect does not require complicated installation procedures. It is written in Java, and can be run on any platform. There is a good help system. The model is held in a simple file, in XML format, so you can get at the underlying data if you need to.

There are some drawbacks. Power*Architect does not distinguish between logical and physical models. It does not support sub typing or exclusive links. It only uses physical data types. There is no way of suppressing the posting of foreign keys, which makes models less readable. But we can work around all of these.

Power*Architect has many features that we have not yet tried. It supports Online Analytical Processing (OLAP) designs often used in data warehousing. It maps between source and target databases and generates definitions for Extract Transform and Load (ETL) tools. It profiles data in existing databases, to collect statistics about table sizes and key values.

Overall, Power*Architect is an excellent tool. Although we started by looking for a simple drawing tool, Power*Architect has many other features that will help us in this project.

SQL Power provide a number of other tools, both paid-for and free. The other free tools are Wabit, a reporting tool, and DQguru, a data cleansing tool. SQL Power is also planning a server-based version of Power*Architect, which will make group collaboration easier.

I am hugely impressed by Power*Architect. If you are looking for an easy-to-use, feature-rich data modelling and database design tool, have a look at Power*Architect. It competes well against other tools, and has the great advantage of being free. And it's certainly much better for data modelling than Visio.

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

How does your garden grow?

Like gardening, effective IT depends more on constant attention than it does on grand designs.

I am a very keen gardener, and I am fortunate enough to have a fair-sized garden.

My love of gardening is a big influence on my ideas about IT. Many see IT as an engineering discipline, but I see large-scale IT more like tending a garden.

Although I appear to potter aimlessly in my garden, I am actually very objective. I know what I want from my garden: a pleasant space for the family, somewhere for the children to play, to grow interesting plants, and to produce fruit and vegetables.

I have attended garden design courses, but I am not much of a garden designer. I just don't understand the aesthetics. I focus on the big things, like trees and hedges, and making sure the structure of the garden meets my needs. My garden would not win any fashion prizes.

I am realistic about how much change I can carry out at once. Garden make-overs are entertaining on television, but you can not change all of a large garden in one go.

Instead, I have a vision of how I want the garden to evolve. I carry out small pieces of work that bring me incrementally closer to my vision. I only do big projects, like levelling or creating new borders, when I really need to.

I have a simple rule when I work in the garden. At the end of every day, the garden must be neat and usable and all tools put away. This sometimes slows me down, but it lets me fit the gardening around other priorities without the garden looking like a building site.

Gardens are dynamic, continuously changing. Gardening involves fighting nature and entropy, continuously re-imposing my will. The garden demands continuous attention to remove the weeds, clear our dead and overgrown plants, and keep the soil workable. If I let it go for too long, I know it will be more work later.

Other people approach their gardens differently. Some are more design-lead. Some outsource their gardens to a maintenance service. Everybody has different objectives and priorities. Some people just do not care. But for me, for my objectives, my approach to gardening works. It lets me develop and maintain a large garden that meets my requirements with minimum effort, cost, disruption and stress.

The parallels with IT are obvious. Be clear about objectives. Focus architecture and design on meeting the main objectives simply, without getting carried away with the latest fashions. Set a clear direction, and run small projects to move towards it incrementally, while sustaining business as usual. Maintain systems continuously, and decommission systems completely when they come to the end of their useful life.

Other people have different ideas about IT. Some are more keen on trends in IT architecture. Some outsource everything. Some rely on huge transformation programmes. Some are less convinced of the value of preventative maintenance. Some appear not to care. But as I potter around my garden, I muse that they have got it wrong, and that there are easier, cheaper and more effective ways to run IT.

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

Internet Explorer 8 - time to upgrade

Businesses should upgrade to Internet Explorer 8 to remove the standards compliance problems with old versions.

The saga of Internet Explorer (IE) and standards starts in the late 1990s, when web standards were not well established, and there were significant differences between browsers. At the time, Netscape Navigator had an 80% market share. To compete with Netscape, Microsoft promoted IE (some would say unfairly) by distributing it free with Windows. Microsoft also owned the popular web authoring tool FrontPage and worked with the then-dominant ISP AOL to ensure AOL users had a version of IE. Microsoft was very successful: by 2002 IE had around 96% of the market share. IE was so dominant, it could get away with not following official web standards closely.

From around 2004, there has been a growth in other browsers, such as Mozilla Firefox, Apple Safari, Opera, and more recently, Google Chrome. IE's market share has now declined to around 65%. Web standards have also advanced significantly. These other browsers follow official standards closely. They all display web pages similarly to each other, but differently from IE.

The differences between IE and other browsers are a big headache for web developers. They have to resort to tedious work-arounds to get websites to look the same in all browsers. Many problems — such as unreadable text or jumbled layouts — are caused by the need to write different code for IE and standards-compliant browsers.

Web standards support has been improving in IE, but there are still problems in IE7. However, IE8 was released in March and follows official standards closely. You can create websites that look the same in IE8 and in other browsers, without complexity and messy work-arounds. This simplifies web development and improves reliability and user experience.

Microsoft have handled backwards-compatibility well in IE8. IE8 can display websites designed for earlier versions of IE, either by setting options in the browser, or by using additional metadata added to the website.

Most home users of Windows will accept automatic updates and migrate quickly to IE8. IE8 usage has grown rapidly to around 15% as of the end of June, and will pass the usage of IE6 any day now.

Businesses tend to be more conservative. They assess change more carefully, and need to allocate resources to manage the upgrade. I guess that most IE6 usage is business-related, and it is businesses not home users that will cling to IE7.

The standards compliance advantages of IE8 are substantial. The case for upgrading to IE8 is stronger than the case for IE7. We should:

• Set a policy that encourages standards-compliant websites and browsers, and discourages features and bugs that are specific to earlier versions of IE.
• Consider the long-term advantages of IE8 to balance the cost and risk of upgrade.
• Explain the situation to our business colleagues, and encourage them to accept minor problems during the transition to standards-compliant websites and browsers.

If we all do this, we will help overcome one of IT's less glorious episodes, and reap the rewards of easier web development and a more reliable user experience.

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

Opera Unite - Dawn of a new era?

Although still in its infancy, Opera Unite could start a big shift in how we use IT.

Some years ago, I wrote about a second PC revolution in which PC users create outward-facing services and offer them to the world as easily as they currently create spreadsheets.

That vision has come one step closer with Opera Unite.

Opera Unite, currently in beta testing, is an add-in to version 10 of the Opera browser. It allows you to serve web-based applications from your PC to anyone on the Internet, or your colleague at the next desk, whatever browser they run. It currently supports only a handful of services such as a web server, file sharing, media player and chat. New services can be written in JavaScript. Opera hosts a site for users to upload and share services.

Opera handles the networking. Instead of other people accessing your PC directly, they access a public URL (something like http://computer.yourname.operaunite.com/web_server), which the Opera servers then forward to your PC. You can use the service to run web-based applications without configuring servers, domain names and firewalls, even from behind a corporate firewall.

From our technical perspective, it's easy to dismiss Opera Unite. It isn't hard to set up a web server on a PC, or to use an addressing service such as DynDNS.com to provide an address to it. And of course running web applications from inside a browser on a PC is architecturally inept.

But we dismiss this new direction at our peril. There are many reasons why Opera Unite is significant:

• Don't underestimate the barriers to setting up outward-facing services: technical knowledge, permissions, fear of looking silly, the IT department's work request processes. Opera Unite does away with all of this, and could unleash a flood of suppressed demand for IT.
• People like having their own stuff. There are lots of social websites and hosted business services where people can share things, but there is something deeply ingrained about having things under our complete control. It is one of the reasons PCs are so popular.
• The installable service model could grow hugely. There has a been a lot of interest in Apple iPhone applications and in Facebook applications. There could soon be a huge library of Opera Unite applications ready for anyone to run and offer to the world. (A good starting point would be services which allow collaboration on office documents.)
• The networking is significant. Anyone with Opera Unite can set up a file share or website to colleagues and contacts within or beyond the organisation. It will be easier to use Opera Unite than to follow the official procedures defined by the IT department.

If Opera Unite is successful, and if similar features are built in to more popular browsers, we in IT risk losing control as users abandon centrally controlled IT and take matters into their own hands. We can see this as a threat, or see this as an opportunity, but I do not think we should ignore it.

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

What's really going on 4: putting it all together

The combination of shared understanding of IT, long-term proactive management and evaluative theory is a powerful tool for addressing the problems and opportunities of IT.

Over the past three weeks I have written about how management of people, process and technology is not sufficient, and many IT problems and opportunities are not addressed.

I have suggested that structuring management around whole systems provides a useful common viewpoint. The remaining parts of this mental jigsaw are long-term proactive management and evaluative theory.

We know that it is cheaper and easier to be proactive: to prevent problems rather than fix them, and to grasp opportunities for improvement in a timely fashion.

To give some IT examples, it is cheaper to manage IT systems so that they are useful for longer, rather than to let systems decline quickly and replace them frequently. It is easy to keep systems well-documented, testable and well-maintained, but very hard to recover them once they start to decline. It is easy to plug occasional vulnerabilities in otherwise secure systems, but difficult to implement comprehensive security on insecure systems.

In IT, we find long-term proactive management very hard. It is hard to make sense of everything that is going on across all the systems, and to identify, prioritise and justify the interventions that are needed. Proactive management is at best piecemeal. Inevitably we do not address all of the issues, and costs and risks increase dramatically.

This is where evaluative theory really helps.

You can base management on one of two types of theory. You can use an explanatory theory which describes how the people, processes and technology must be arranged, and then execute on that management. This is effective for common tasks such as project delivery and day-to-day operations. However, this approach requires both management effort to define and ongoing resourcing to execute. It is not suitable for the occasional, discretionary, responsive activities that proactive management demands.

An evaluative theory does not explain how things will be done, but describes what a good thing looks like. It is much easier to define an evaluative theory, and you do not need to do very much in order to manage. Assessment against an evaluative theory quickly identifies and prioritises what needs to be done. Because it looks at outcomes rather than the detail of implementation, an evaluative theory is much easier for a non-specialist to understand.

The combination of evaluative theory and a system view is very powerful. Instead of IT being a fragmented and mysterious complex of people, processes and technology, IT becomes a set systems, each with a set of understandable outcome measures or "qualities" (which is why we call this approach system quality management). This gives insight to make effective, justifiable recommendations for proactive management that can make a significant difference to IT.

What's really going on in IT? We don't have the management disciplines that we need to manage IT effectively for the long term. Our management of people, processes and technology is fragmented and inward-looking. We can fix this. Combining a system view (that everyone can understand) with evaluation (that identifies what needs to be done) gives the clarity and justification that we need to manage IT effectively for the long term.

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

What's really going on 3: thinking of IT differently

Despite the effort put into managing people, processes and technology, IT management is chronically fragmented and inward-looking. We need to think of IT differently.

We need to understand clearly the purpose of IT and how IT delivers value.

The purpose of IT is to provide useful information to the business. IT delivers value because it allows this information to be preserved through time (storage), derived from other information (transformation) or moved from place to place (communication). Higher-order value can be built on top of this, such as decision support, process automation, or enabling business change, but these can all be traced back to these basic capabilities.

We also need a simple structure for thinking about IT that counterbalances the complexities of people, process and technology. Our requirements for this are:

• Easy to understand.
• Shows the connection between what we do and the value that IT delivers.
• Provides a common point of reference between IT and business.
• Provides a common point of reference between different IT specialists.

Value is delivered from IT by the automation of the storage, transformation and communication of information. To get the structure we need, we can split IT down into understandable and manageable units around this information automation capability.

That is what a business application is - a related set of IT capability. We can use this as the basic granularity for our understandable IT structure.

But we need to think much further than just business applications. When we talk of applications, we think of software, as distinct from hardware or infrastructure or support processes. We want to bring all the people, processes and technology of IT into our definition.

For this reason, use the term "system". A system is an interrelated set of people, processes and technology that does something useful for the business. The granularity we need is the same as business applications. But we need a much broader scope, and our definition of system include the business usage of the application, the software and hardware on which it runs, the service and support processes around it, and all the people needed to deliver the IT capability.

Using this definition, "system" meets our requirements. It is understandable and recognisable by both business and IT. It is connected to value because we can consider the value derived from the information that it stores, processes and communicates. We can understand all the people, processes and technology that go to make up the system.

Next week I will cover how we can use this way of thinking to overcome the problems caused by fragmented and inward-looking IT management.

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