The pitfalls of productivity

What are the trade-offs of rapid development tools?

Religion and folklore have plenty of cautionary tales of taking the appealing, short-term option, and not thinking about the future. I worry about this when I make bold claims about the speed of creating solutions in Metrici. I need to be more open about the trade-offs.

There is nothing magical about reducing development time. The methods Metrici uses are much the same as those used in other tools (though I like to think we have crammed more into a single platform). But each time saving method has a trade-off.

Delivering solutions as software-as-a-service (SaaS) means there is no infrastructure to buy and configure, no software to install, and common features like user management and security are already in place. SaaS is simpler and cheaper for most solutions. The trade-off is that you have to entrust your data to someone else.

Automation of database and user interface (UI) makes developing a solution as simple as describing the definition and structure of the data. This saves a lot of time, especially for solutions like assessments and management information systems which have transient or frequently changing data definitions. However, generic data structures are not as efficient as specific data structures for large volume transaction processing. The UI can be tailored, but if you have to tailor everything, it would not be as quick as using a more UI-centric tool.

Metrici provides a basic UI and data structure framework for solutions, and you add code for things like calculations and UI tailoring. This is much faster than writing a base program that controls all the database access and user interface. The trade-off is that you have to fit your solution into the pattern of the platform, which in Metrici's case is a web-based application.

Being able to redefine the components you use for development is common in lower-level languages, like LISP and Java, and Metrici similarly exposes high-level development components for modification. For example, if your solution requires a particular sort of graphs, you can create new types that simplify creating them. Making complicated things simple greatly reduces development effort, but you do need to spend time understanding existing components and how to write new ones.

Like a lot of content management systems, Metrici allows data and definitions to be versioned. This means that you can change things without impacting what is already there, which makes it much easier to build solutions incrementally, and much quicker to modify solutions later. But version-managed data structures are more complicated than they would otherwise be, and the trail of old versions means that you never fully remove earlier (and possibly erroneous) data.

To get the benefits of rapid tools without long-term regrets, you have to understand the mechanisms they use and the trade-offs. Metrici is no exception. The mechanisms Metrici uses - SaaS, automation, framework, components, change management - make it a productive platform for many data gathering, content management, record keeping and reporting solutions. As much as I believe they are worthwhile, there are of course trade-offs. If you want a rapid development tool you need to think carefully about the trade-offs, and be wary of promises of short-term productivity, even if they come from me!

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

Know your USP

Defining your product's unique selling proposition (USP) is not the same as listing its features.

At Metrici, we want to reposition our product. Currently we position Metrici as a professional assessment platform. It gathers and manages complex data from surveys and assessments, and analyses and reports on the data in multiple ways. We emphasise its flexibility, allowing you to quickly configure a solution that meets your precise needs, rather than make do with a solution that only does part of the job, while avoiding the cost of bespoke development.

We want to reposition Metrici as a more general platform. As well as surveys and assessments, you can use it to create databases, web content, reporting systems, document management, and pretty much any application you can imagine.

Repositioning our product puts us in competition with everyone. As well as competing with Excel and bespoke development, we will come up against large platforms: SaaS platforms such as SalesForce.com, content management platforms like Joomla and Drupal, and broad business platforms like Lotus Notes and Sharepoint.

To have any hope of competing, we need to promote our unique selling proposition (USP). We need to know "what's different about Metrici" if we are to have any hope of convincing customers.

Being faster and cheaper and more versatile is not enough. There are lots of things that make Metrici fast: it is web-delivered, database and user interface definition are automated, and you can rearrange how the tool works to best suit the solution you are creating. These are great features for us because they allow us to present solutions in many situations. However, customers are only buying for a single situation. The fact that we can quickly configure Metrici to be, say, a document management system, does not necessarily mean that it is a better document management system than others or that it is quicker to configure the final solution in Metrici.

Instead, our USP is that we can deal with the unknown. We need to present this carefully. Presenting it as "Metrici - for the man who doesn't know what he wants" won't get us very far. Here are some better examples of what I mean:

• Where the business requirement is not known, and you need to evolve the solution gradually through time.
• Where the investment case is not established, and you need to start small and grow the solution as and when the case is better defined.
• Where sources of funding are not known, and you need to start the solution very cheaply.
• Where business support is not established, and you need to build the solution to get support for the solution.
• Where you don't know how you are going to find the time to create the solution.
• Where the needs of your customers keep changing.
• Where you do not know what tools can meet all your requirements.

Put another way, the USP of Metrici is that it is the opposite of traditional systems development. Traditional systems development requires an established business case, stable, signed-off requirements, buy-in from users, ample funding, long timescales, and a well-understood architecture. If you have all those things, maybe Metrici isn't for you. Our USP is that we can help when you don't.

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

Video game training

Could video games provide a good model for how we structure technical training?

One of our problems at the moment – and it is a good problem to have – is scaling up our ability to meet client demand for solutions based on our Advisor platform. We need to increase our pool of skilled people to keep up with demand.

Advisor is built on some fairly unique concepts, so we can not take on ready-trained people and will have to train people ourselves.

Unlike many tools, there is not a distinct set of technical skills that solution builders need. Advisor functionality is defined within Advisor's own data structures, and solution development involves using Advisor's features to create, extend and redefine these data structures to meet specific needs. Developing solutions for clients is just an advanced use of the tool.

To try to reflect this in a learning or training plan, instead of defining separate technical training, I have arranged the use of Advisor into a series of levels, each of which builds on the one before. By luck rather than design, skills in Advisor fall neatly into ten levels.

• Level 1 – Basic usage
• Level 2 – Data maintenance
• Level 3 – Account administration
• Level 4 – Data type maintenance
• Level 5 – Data management
• Level 6 – Configuration
• Level 7 – Programming
• Level 8 – Metadata
• Level 9 – Branding and style
• Level 10 – Solution structure

After the ten levels, improvement is more to do with design skills than knowledge of the tool. There are three levels of mastership.

• Master 1 – Solution builder – able to build a complete solution.
• Master 2 – Tool builder – able to build a solution that is designed to be extended, tailored or configured by others.
• Master 3 – Innovator – able to map the characteristics of Advisor to business problems creatively.

This structure makes it easier to understand what training people need. For example, people developing new content need to have achieved level 4. People developing different types of components need to have achieved levels 7, 8 or 9. People leading development need to have achieved Master 1, 2 or 3 depending on whether the solution needs to be extendable and whether it is a new type of solution.

This way of structuring skills and training is useful for the specific needs of our product. It communicates how skills need to be developed through a number of small steps, each of which builds on the ones before. But it is different from most technical training. In most technical training, you go on a course and come out with a certificate. But what I think we need is more like a video game, where you work your way through the levels to gain more skills and more recognition. For many people, this is a familiar way to think about skills and achievement. If we want to attract and give recognition to new developers, perhaps we need to rethink how we train them.

Why programming takes so long

Some things that look simple can take a very long time.

Over the past week I have been working on something that is much harder than it looks, and I though it might be interesting to share the experience.

The requirement was to paste data in from Excel. This seems like a simple requirement: it is something we do every day, and lots of programs support it.

At a more detailed level, I needed to meet lots of technical requirements.

• It has to support both the format used when you paste directly out of Excel (where values are separated by tab characters), or when you export a comma separated values (CSV) file.
• CSV data contains lines of values separated by commas, with quotes around values that contain special characters. But there are lots of variations. For example, in continental Europe where a comma is used as a decimal point, CSV files can use semicolons instead of commas.
• The program usually has to interpret the format of the incoming data automatically, but also needs options to specify what separator and quote characters are used.
• The program needs options to ignore blank lines, or lines that are intended as comments.
• Different technologies have different rules for new lines. Windows uses a carriage return character followed by a line feed character; Unix uses just line feed; and some Apple systems use just carriage return.
• Pasted data and CSV files may have column names as the first row. The program has to cope sensibly if there are more data than columns.
• The program needs to output data to programs which have different formatting needs. Some need cleaned-up CSV. JavaScript programs need the data in JavaScript Object Notation (JSON) format. Other programs need Extensible Markup Language (XML), optionally using column headings as the names of the XML elements.

What looked like a simple requirement has ended up complicated, and is a few days work even under ideal conditions. To develop the new component I used existing components as much as possible, particularly handling the XML and JSON output. The only thing I had to program from scratch was the logic to interpret the data. I have a lot of experience of this type of code. I am completely familiar with the development and test environment. But even under these near-perfect conditions, the component required 750 lines of code, 450 lines of test code, and took me 20 hours to develop. If it was an area I was less familiar with, or where I had fewer existing components, or where the development and test environment was unfamiliar, it would have taken me many times longer, perhaps around 100 hours.

Now that we have this new component, we can now use it to meet other seemingly more complicated requirements really quickly. It only took me about four hours to develop a new bulk emailer component with it (for sending out and following-up on surveys). And I can add that component to new solutions in a matter of minutes.

The time taken to add a new feature depends hugely on the components available and the developer's experience of the situation. Sometimes things that look simple take ages, and things that look hard take no time at all.

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

Problem density

Problem density could be a valuable new concept for measuring IT.

The term "problem density" cropped up in conversation with a colleague. I had not heard the term before, so I searched for it on the Internet. The term is used occasionally in healthcare to measure the the number of problems that patients have. It is particularly used to assess drug addiction, where the patient may have many problem associated with their addiction.

Problem density could be a good concept for us to use when measuring IT. Most of the measures that we use are measures of general "goodness", or of compliance to standards or defined processes. We tend to use percentages or maturity levels. These are OK, but it is easy to lose focus on what is important. The scales that we use do not emphasise the situation well. What does 50% compliant mean? How much worse is maturity level 2 than maturity level 3? Bounding the numbers in a range (0 to 100, or 1 to 5, or whatever) does not give enough emphasis on what is really important.

Measurement of the number and severity of problems would give much easier-to-understand figures. Saying that one situation has a problem density of 1 and another has a problem density of 10 is easy to understand. Although it is an arbitrary scale, you can see that one situation is ten times worse than the other. It is also more accurate. We know that some situations give us hugely more problems than others, which is difficult to capture on a 1 to 5 maturity scale.

Problem density can be applied to both business and IT situations. We could devise scales for aspects of IT, such as measures of systems, projects, services, suppliers, and so on. But we could apply it to business situations too. We could measure business issues, such as task complexity, data errors, operational problems, rework, and so on, by devising a problem scale.

Solution density is the corollary of problem density. When we implement new solutions, whether they are procedures or systems or a mix of both, we can measure the breadth, complexity and variety of problems that they are intended to solve.

Comparing solution density to problem density would be a really useful analysis. IT solutions are intended to address problems, but they also introduce problems. Taking a ratio of the problems they solve (solution density) to the problems they cause (problem density) gives us a really useful management tool for identifying what systems are worthwhile. Looking back at my time working as an integration architect, this would have been really useful. I could have used it to illustrate how a lot of integration solutions have a solution to problem density lower than one, meaning that they cause more problems and complexity than the problems that they are intended to solve.

I will try introducing problem density into the IT measurement work we do. It will be interesting to see whether problem density is a more useful management tool than the measures we usually use.

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

The ideas amplifier

Computers don't just automate our ideas, they make them bigger.

I have often wondered why computer systems work. I have been developing a new data load feature for our software. It involves a fairly complex mixture of data management, dependency resolution, change detection and version control. I have designed it carefully and am testing it as I go. But how do I know it will work when I have finished?

I have had this thought many times before. I have written lots of computer systems and by-and-large they work. They do what I want. The design and programming achieve the aims set out for them. But, philosophically, why is this? What is it about computers that allow us to translate our ideas into machines that meet our requirements?

In part, computer systems work because of the sort of people we are. IT attracts people with systematic, consistent minds. We work over problems in our heads and find ways through. We translate those methods into computer programs, and out come working computer systems.

It is not just the sort of people we are. I was trying to mend a garage door the other day, and only succeeded in jamming it and needing to take a hammer to it. I might have a mind to get computers to do my bidding, but not the physical world. In what way are information systems different from physical systems?

The nature of information partly explains why computer systems work. Computers store, process and move information, and information is a much more flexible and forgiving medium than garage doors. We can fiddle around with the rules for storing, processing and moving information until we get a recipe that works. But there is more to it than that.

The final part of why computer system work is their ability to repeat our recipes tirelessly. Computers can consistently and efficiently repeat the instructions we give them, and so apply our ideas to much larger problems.

This amplification allows us to develop small programs that do big things. In my example load program, I need to synchronize large, interconnected structures across two instances of the software. But although that is a big requirement, I only have to think through the rules for a single piece of data, and can rely on the computer to apply my recipe reliably to large and complex data sets.

As well as helping us deliver technically, computers allow us to amplify business ideas and exploit them in whole new ways. Take Twitter for example. There's nothing particularly clever about noting down a few thought for other people to read. But by using computers and the Internet, this simple idea is amplified into something which is not only much larger but different in kind. The simple idea of writing down thoughts has turned into a responsive and inclusive global news and opinion system.

When we think of how computers add value, we need to think of this amplification effect. I often write how computers are just machines that store, process and move information. But maybe I am guilty of oversimplification. Their ability to do this quickly, reliably and on a large scale gives a whole new dimension. Computers don't just automate our ideas, they make them bigger.

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

Toolbox for IT Topics Project and Portfolio Management Blogs Edit Entry Mobile WiFi Access Points

If you need Internet connections when you are away from home or the office, a mobile WiFi access point could be just the solution you are looking for.

A mobile WiFi access point is a mobile device that provides a WiFi network that you can use to connect other devices, like laptops and iPads, to the Internet. It is basically a mobile phone with the talking bits taken out, optimised to connect to the Internet and provide a WiFi network.

Mobile wireless access points are a compelling option in many situations. Imagine one or more people away from home or the office, with devices that they want to connect to the Internet.

A mobile access point makes sense when there is more than one person. A single access point can serve multiple devices, so rather than having the cost and complexity of multiple Internet connections, just use one.

Some mobile phones provide WiFi access points, and this can be a very simple way of accessing the Internet from other devices. However, some operators block the use of this feature, or make it unreasonably expensive. If more than one person needs Internet access, then accessing it through one person's mobile phone is not very useful because when they go out they take the Internet with them.

Some devices can access the Internet directly through built-in mobile networking. This is fine if it is your only Internet device. But if you need the Internet on more than one device, having a single mobile access point is likely to be cheaper and less effort.

Mobile WiFi access points can be a cheaper option than fixed-line broadband. In the UK, it is possible to keep yourself connected to the Internet for under £50 per year through mobile broadband. However, for anything other than light users (i.e. anyone who watches much video over the Internet), fixed-line broadband would usually be a cheaper option.

I have been trying out a mobile access point. When I went on holiday, I used to connect my laptop to the Internet using my mobile phone. However, my sons are now of an age when they can't imagine going on holiday without adequate Internet access. I bought a ZTE MF60 (about £65), and using this I can get up to three months Internet access for about £11 by buying pay-as-you-go data SIMs for the Three network. The device is extremely simple to set up - just put a SIM in, turn it on, and access with WiFi using the security key printed on the inside of the battery compartment. Depending on the strength of the mobile signal, this can be much faster than either my phone or my fixed-line broadband at home. I can use a different SIM card to access a different network operator, for example using a local operator to get cheap Internet access abroad.

Mobile WiFi is cheap and simple and works well. It could be just the solution you are looking for.

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

Hobgoblins

Should our methods and processes be consistent?

A foolish consistency is the hobgoblin of little minds. This famous quote from Ralph Waldo Emerson explains the difficulty many of us have with admitting that we have been wrong in the past and that we see things differently now.

I suffer from plenty of foolish consistency. I notice it with these newsletters. I agonise about what I write just in case it is inconsistent with what I have written before. But really I should have the confidence to write each piece afresh, with the best ideas I can muster, and not worry that I might contradict what I wrote before.

This week my mind has been anything but consistent. This week two very different thoughts have been floating about in my head.

My first thought is that we should move away from engineering-led development. I enjoy writing, and the really good thing about writing is that it is so flexible. You can jot down some notes, write a few paragraphs, do a bit of an edit, rearrange the document, and so on. Systems development is so rigid by comparison, designing systems and data, writing complete programs, testing. Surely we could take a more fluid approach, jotting down ideas and following parts of the solution through, without the whole engineering-led rigmarole.

My second thought is that it is really important to develop software properly. I get involved in configuring a lot of assessment solutions. Most of the time the solution design is trivial - ask some questions, show some results - and we spend our time working on the wording and formatting of questions and outputs. But we have picked up some work recently that is centred around a database, with assessments feeding in and out. I have been thinking how we need to do some more formal analysis and design, to make sure we have the data designed properly, and understand the processes around the solution.

These two ideas are inconsistent. On one hand, I want to move to a more fluid approach to development, on the other a more rigid, engineering approach. When the two ideas surfaced at the same time I didn't know what to think. Which idea was right?

Of course I could make the ideas consistent. My first thought was about how to develop: being more intuitive, following what seems important, building iteratively. My second thought was about the fundamentals of the solution, understanding the solution's purpose and structure before you start. I could argue that I wasn't being inconsistent, and that really I was looking at different things.

But perhaps it is foolish to look for consistency. As much as I can try to make these ideas come together it would be wrong, and I should recognise that they are inconsistent, different approaches. Management is all about picking the right response. Sometimes we need hard engineering, sometimes a more fluid approach. Different approaches have different advantages in different situations. To be really effective, we need to be inconsistent.

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

Hooray for marketing

Marketing may seem vacuous to our technical minds, but when it works it's magic.

Last week we were exhibiting our Advisor software at a Gartner show. We were not there under our own brand - we were presenting the software through a partner's brand, promoting capabilities that we had jointly developed with them.

We got a lot of interest in Advisor because we were presenting it for a very specific use. The show was about outsourcing and related subjects. We were presenting Advisor as a tool to gather facts about vendors and perform vendor compliance assessments. There were a lot of people at the show who identified with this need, and we have a lot of interesting leads to follow up.

This was a good example of marketing working well. Our partners had done their homework, and had discussed the "hot topics" with Gartner. Vendor management is very much in fashion, and a lot of organisations are starting to clarify vendor management roles and processes. Rather than present Advisor as a general tool that can help in lots of ways, we decided to focus on just one area, and by doing so created a lot more interest.

In the past our marketing has not been so focussed. We have had mature and effective system governance assessments for years, but, as someone once replied to us, "it's not our priority right now". However good the idea in principle, it isn't what people recognise and it is too broad an idea to meet their immediate needs.

Over the years I have learned two things about selling:

• It is better to present a good solution to a little problem people recognise than to present a great solution to a big problem people do not know they have.
• For tools, the ability to be flexible and cope with real world messiness is really important, not for its own sake, but because it allows you to deal with specific, nuanced needs in a very focussed way.

I don't think there is anything wrong with presenting a general-purpose tool as a specialist tool. It would be dishonest to present something we have not got, but we do have a real offer in this area. We have spent many years getting Advisor to the point that it can support these types of assessment and advisory requirements, and our partners have many years experience of outsourced services and vendor management. Creating products in Advisor may not take much longer than it would to mock them up in PowerPoint, but the difference is that we have functioning products that capture subject matter expertise and which can add significant value to organisations.

Going forward, we need to do more of this sort of marketing. People are interested in products that solve the problems they have and exploit the opportunities they recognise. Advisor is a semi-blank canvas, and it can add value to many different situations, but to deliver that value we have to research the specific situations that people recognise, and present specific solutions in those areas. This is the essence of marketing, and when it works it's magic.

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

As a parent, you have to learn to let go.

I really felt that today. My five year old daughter has been learning to ride a bike. Today she was finally ready to go by herself, without stabilisers and without being held. My wife and I took turns running along holding her, and then letting her go to cycle by herself.

Professionally, we need to let go too. When we have created something, we have to let it go, to give it a chance to survive by itself in the big wide world, without our constant care and attention. If something is to grow and be successful, it has to outgrow its creators.

I have another big piece of letting go to do this week. We are exhibiting our Advisor software at the Gartner 2012 EMEA Outsourcing & Strategic Partnerships Summit in London. We have to push our software out into the big, wide world.

It is hard to let go because we are not doing it alone. We have partnered with another company, and are presenting our software through their brand. Working with other people means taking on a lot of other ideas. It means letting go of how we might like to think of the software, and accepting the experience of our partners on how best to present it. We have to trust our creation, our baby, to the care of someone else.

Selling software is very different from building it. To sell successfully, you have to be confident, even brash and pushy. This is very different from the quiet, geeky world of software development. I know that how we are selling it is for the best, and is something we have to do, but it does not mean that it comes easily.

What is the alternative? Much as I would love to polish software all day long, to make it ever more elegant and efficient, there is no point unless it does valuable things. And it is never going to do valuable things until a lot of people use it. And we are never going to get a lot of people to use it unless we sell it to them. We have to engage in the most effective sales process we can, however foreign it seems to us. We have to let go of how we think of the software, and submit it to someone else's sales process.

Of course I worry, just like I worry about my daughter on her bicycle. I worry that people won't like it. I worry that it won't work. I worry that it won't stack up against other products. I worry that we won't be able to explain to people just how wonderful and special it is. But I have to face these worries, and do it anyway.

Today, my daughter managed to ride her bike. A bit wobbly, but no crashes and no tears. One of those truly delightful moments of being a parent.

On the professional side, I will have to see what this weeks brings. All being well it will be a resounding success, and we will see our products making their own way in the world. But even if things don't go OK, letting go is still the right thing to do.

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

IT's ethos

Many of the problems in IT stem from a lack of professional ethos.

Most professions have a reasonably well-defined ethos. For doctors, the well-being of the patient is the core focus. For lawyers, it is representing the best interests of the client. For retailers, it is customer service.

There is no professional ethos in IT. We do not all agree on the purpose of our profession. Is it to deliver services smoothly? Is it as an agent of business change? Is it about guarding information assets? Is it about exploring and exploiting new technology?

The lack of consistent ethos means there is conflict in most IT roles. Here are some exaggerated examples:

• Support staff who are intimately familiar with systems become a barrier to change. Support staff rightly see their job as understanding systems so that they can fix problems and make changes for their users. But because they are intimately familiar with the systems, and because their jobs revolve around them, support staff are too defensive of the status quo and do not have the vision required for major change.
• Developer's pursuit of novelty and elegance detracts from the need to focus on tangible deliverables. It is important to innovate, both exploiting the value that new technology can bring, and finding simpler and more efficient ways to achieve aims. But developers, especially the more geeky ones, get carried away with trying to build the perfect solution, and lose sight of the main objective of providing valuable (but often boring) business functionality.
• Service delivery's customer service ethos, although not conflicted with itself, is very limited. It does not include major business change, and does not include the deep, detailed improvements to software that developers perform.
• Even senior leader's pursuit of change undermines good management. Largely because of the conflicts in IT, organisations engage senior leaders to define and push through major change. But so often the vision of the change is not matched by a capability to govern or a realistic view of what is involved. In hindsight, many major initiatives are fecklessly overambitious, they fail to deliver on their promises, and leave the next senior leader with a legacy of complexity and political embarrassment.

Although other professions have conflicts, the conflicts are worse in IT because of the lack of ethos. There are always conflicts between those fascinated by the technicalities of the profession and those focussed on making money, there are problems when the ambitious overcommit the organisation, and problems with the limited perspective of people stuck in the same role for too long. But in other professions, there are commonly held views that act as a reference point and to which everyone has to at least pay lip service. In IT the problems are worse because there is no such common ethos.

IT is too young to fix this problem. Other professions have had centuries to work out their ethos. This has involved subdividing the professions into more coherent, less conflicted sub-professions, like pharmacists, surgeons, family lawyers, merchandise buyers, and so on. IT is very young and has changed hugely in its short life. An ethos will evolve, but don't expect it any time soon.

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

One day all software will be built like this

Products that are developed in themselves are initially hard to work with but eventually become much more powerful than conventional products.

A colleague was explaining the differences he saw between our software, Metrici Advisor, and another product he uses. "In Advisor, every thing is the same. In [other product], we do development in Visual Studio, we configure the product in special admin screens, and the user uses a totally different set of screens. But in Advisor there is no distinction, you do all development, configuration and use in the same tool. It's not wrong, but it is different and it takes some getting used to."

Technically, Advisor is a homoiconic web platform built on an enhanced triple store. In simple terms, this means that it is an up-and-running service on the web, Advisor's functionality is written in Advisor itself, Advisor can hold any data, and there are no limits to what Advisor can do. This is particularly useful in our target market, of professional assessment products, where data structures and functionality differ subtly from one situation to the next.

Building a system this way has its challenges. The main challenge is needing to create all the functionality of the tool in the tool itself. Over the past year or so we have been "bootstrapping" Advisor, developing functionality to create questions and questionnaires, to manage assessments, and to analyse and report on results.

Although it is challenging, having a product written in itself gives us huge opportunities. We are dealing with only one set of technologies, not three. We can build development and configuration functionality which precisely meet the needs of specific solutions. As we develop new functionality in the tool, it becomes available to all parts of the tool, and enhances our ability to create yet more features. From a slow start, the capability of the platform and our development speed increases exponentially.

To give an example, we have recently been developing functionality to package and install products in client accounts. But because of the way Advisor is built, we can use this functionality elsewhere. To help our own development processes, we have used the new functionality to create "meta products", products for developing products. These include our latest features and best practices as a ready-to-use development environment, even including a skeleton for the product itself. Because of Advisor's structure, functionality to solve one problem (improving speed and reliability of commissioning accounts for clients) directly solves another (making development of new products easier and faster).

Advisor has a very specific combination of features: a full web platform (a ready-to-use service, not just some web tools), homoiconicity (the tool's functionality is defined in the same data structures that the tool itself maintains) and triple stores (able to hold any data in any structure). Using the tool every day, I am constantly amazed by the power of this approach. It is almost magic, and far exceeds our original design goal of building a more flexible assessment tool. I fully understand other people's scepticism, but based on my experience I think that tools built on these principles will inevitably overtake others because of their simplicity, flexibility and development speed. One day all software will be built like this.

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

Enforcing data security

You can improve data security by implementing fine-grained security at the lowest level of data access.

Most attempts to secure data are flawed because they rely on developers and administrators doing their job properly. Administrators apply security at the level of whole files or database tables. Inside applications, programs have access to the entire database and it is up to the developer to implement security rules. If the administrator or developer makes mistakes or are acting dishonestly the security of the data is compromised.

One way around this is to apply fine-grained, system-enforced security. Done right, this means that administrators can not grant access outside of the owner's intentions and developers can not introduce features that can be exploited.

I can give a real-life example. I have been working on a new feature in our Advisor software to hold page-specific user preferences. I developed what I thought was a working solution. The solution created an object for each user's preferences, and on this held user preferences indexed by the page to which they applied. The solution seemed to work well, and I could store and access page-specific user preferences.

When I tested the solution as a different user it did not work. The test page kept showing the first test user's preferences. I was momentarily stumped.

The solution did not work because it broke system-enforced security rules. Advisor has fine-grained rules about who can access which data. If you create data, nobody else can see it unless you grant them access, and you can not grant access to people outside your account. Page content is built under the authority of the owner of the page, and if you create preferences for a page owned outside your account (for example, a page in a shared question library), there is no way that the page owner can see or be granted access to your preferences.

Once I understood the problem it was easier to understand what I needed to do. Page-specific user data is a way for the user and the page owner to share user preferences for the page, but they can not pass data between them directly. They therefore need a trusted third party to act as a go-between. I developed a feature that stores preferences centrally and allows access to the preferences by either the user or the page owner. I set this up under the ownership of the global admin authority, who has the special authority to make features available to all users.

The in-built security stopped me accidentally creating something that could be exploited. Although it was frustrating at the time, the problems I hit forced me to think. The eventual solution is secure - it separates user preferences (which have to be shared) from substantive data owned by the user or page owner, and gives both parties only the minimum access they need to a shared area, using a trusted go-between.

Where data security is critical, a similar solution could work for you. The key parts of Advisor are that it passes all data access through a layer which enforces fine-grained data ownership and authority controls and that it limits how widely authority can be granted in the system. Could something like this improve your data security?

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

The new architecture

To create the next generation of IT architecture we need to think beyond our current engineering mindset.

Historically there have been many constraints on IT. Computers used to be very much slower and very much more expensive. Physical resources, such as disk, memory and network, were always in short supply. Programming was very labour-intensive.

IT architecture has largely been an attempt to create effective engineering solutions to overcome these constraints. There have been huge improvements in the cost and speed of hardware. We have created technical solutions to the hardest parts of IT, such as databases, development environments and middleware. We have created shared, layered, virtualized architectures to make the best use of expensive resources. We have built up hugely functional operating systems with a wealth of modules to make it easy to reuse work that has gone before.

There are now many fewer constraints on IT. We can create highly-performant, fully-functional environments at the press of a button. We can choose from vast libraries of pre-written software, including specialised system software such as databases and middleware. Networking is ubiquitous. Costs for all parts of IT have been falling for years.

We now have the opportunity to create new IT architectures based on what we really want, not on overcoming constraints. However, we IT professionals are not the best people to understand what the new architecture should look like. We are so steeped in the way things are currently done that we find it almost impossible to think differently. We have argued for so long for the architectures we have now that it is almost impossible for us to take the radical, bold steps that would make huge changes to IT.

I am as tainted by the past as anyone. I have a vision of what IT could be, but I fear it is still an engineering vision, based on overcoming constraints. My vision of the new architecture is one where we replace our major engineering structures with structures that align to the business organisation. In my vision, we do away with layered architectures in favour of independent, self-sufficient systems that fit within the boundaries of the organisation structure. Every system can support any sort of access, from any device, or from any other system, without additional layers. Functionality isn't hard coded into the system, but pre-written modules can be added to any system, or new functionality and data added in intuitive ways to the running system. All necessary controls, such as security and version management, are handled by the system themselves, but, like any other functionality, can be delegated to other systems if desired.

To create the next generation of architecture, we need to think outside of the engineering box. We need to imagine what computers could be without any constraints of performance, cost or capability. We need to think what would serve people well, but we also need to think what people can understand, manage and control. To really take IT forward, to create tomorrow's architectures, we need to see it as much more than just engineering.

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

What can IT learn from CE?

Can we make IT as flexible as consumer electronics?

I recently bought some new gadgets. I am usually reluctant to commit to new technology, but faced with rebellion from my family about our ancient TVs, the family computer, and a phone that they were embarrassed to see me with, I took the plunge and replaced loads of stuff. I bought a new Android phone, a large screen smart TV, a new PC, and a new PC monitor/TV.

From a functional perspective, these devices are very similar. The Android phone can do anything. The smart TV can access the internet and run apps. Using Skype I can make phone calls from the PC or the TV. I can play movies on any device and stream to any other. I can attach a keyboard to the TV and use it as a word processor. Even the "dumb" monitor runs Linux and can be hacked to run programs.

It is useful that any device can do anything. It gives a lot of flexibility, allowing you to rearrange devices as your needs change. You do not need to buy extra devices for features you do not use very often.

However, just because you can do anything on any device, it does not always makes sense to do so. Trying to use the web on the TV is not as comfortable as a PC. The built-in recording capability on the TV is not as functional as a dedicated machine. The phone isn't really cut out as a video streaming server. And so on. It makes sense for different devices to specialise in different ways.

Most business systems lack the flexibility of consumer electronics and are difficult to keep aligned with ever-changing business needs. To be more flexible, we need to adopt two principles:

• Each system should be self-sufficient, with all the features it may need in any situation. Every system should be able to manage users, manage permissions, maintain master data, integrate, import, export, report, log, monitor, provide web-based and mobile interfaces, support add-ons, and so on. This gives lots of flexibility and removes the need for lots of peripheral systems for secondary features, but also allows dependencies between systems where it makes sense to do so.
• We should configure each system to use only the features that reflect the system's role in the organisation. We might decide that some systems act as the masters for data, and others are slaves fed from it. We might have some systems that specialise in reporting, or in providing external web interfaces. Just like consumer electronics, it is a mistake to configure any one system to do everything, which would create a monolithic architecture which is impossible to manage.

This is hard. Traditionally, systems are acquired as narrowly focussed packages or from systems development projects with narrow requirements. System boundaries and functionality are an accident of history, and many systems are not self-sufficient. The overall architecture is very rigid, and is a major constraint on business change. And even where platforms are flexible (such as Microsoft Sharepoint), we don't have the methods to properly decide what each instance should do. If we want to make IT as flexible as consumer electronics, we need a new IT architecture.

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

Precision and simplification

We should value simplification more than precision.

We are very good at being precise. Computers are unforgiving about ambiguity, and being precise is a requirement for a job in IT. We have to tease out nuances of meaning so that we can build solutions that truly match requirements.

Sometimes we take precision too far. A few years ago I was working on a large redevelopment project, and had the task of bringing together the work of the other architects into a coherent body of documentation. In the application architecture document, the architect had written that you could come up with different lists of applications according to how you defined what an application is, whether by function, or technology, or users. He had even drawn up a little logic table showing how different definitions would give different application lists.

Precise though this was, it was worse than useless. The point of architecture is to make sense of all the possibilities and to present the solution as coherently as possible. Explaining that you could do it differently is a statement of the obvious, not a useful solution.

Instead of being precise, we should try to simplify things so that they are easy to understand and to manage. In the example above, it would have been much more useful to assert a list of applications with brief descriptions, and then explain how the applications co-operate to meet the solution requirements.

One good place to start our simplification is to revisit the distinction between an application, a process and a service. There are some official definitions of these. ITIL defines them:

• Application - Software that provides functions that are required by an IT service.
• Process - A structured set of activities designed to accomplish a specific objective.
• Service - A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.

TOGAF defines them slightly differently:

• Application - A deployed and operational IT system that supports business functions and services; for example, a payroll.
• Process - A process represents a sequence of activities that together achieve a specified outcome, can be decomposed into sub-processes, and can show operation of a function or service (at next level of detail).
• Service - A logical representation of a repeatable business activity that has a specified outcome.

These definitions are precise and clever but our ability to define them precisely blinds us to a major flaw. In an ideal world, our processes, applications and services would be aligned and the distinction would not matter. A service (customer view) is provided by a process (provider view) supported by an application (IT view). Our ability to distinguish between the three means we tend to build more complicated solutions, with a many-to-many mapping between applications, processes and services. A less precise definition would drive us to simpler, better aligned solutions.

In the past we have been hampered by the sheer difficulty of acquiring IT capability. But things are different now, and we can easily create IT to whatever structure we want. We need to move away from the precise, nuanced distinctions of yesterday, to simpler, more understandable and easier to manage structures.

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

Assessments are awesome

As well as gathering facts and supporting decision making, an effective assessment process clarifies objectives, encourages collaboration, and builds buy-in for change.

Most of my work these days involves helping organisations carry out assessments. I get involved in different sorts of assessments - shared services, information security, governance, transformation initiatives, and so on. But whatever sort of assessment we are doing, we get a whole load of benefits over and above the primary objective of the assessment itself.

Defining what we want to know clarifies objectives. At the start of most exercises, the objective for the process is generally high-level and vague, such as "identify opportunities for improving shared services". As part of the assessment process, this objective is broken down into specific questions to be answered, and rules about how the answers will be treated. This forces a detailed analysis of the objective, for example classifying opportunities for improvement, or articulating rules for compliance. Even before we start gathering information, we have created a more detailed view of what the organisation is aiming for.

The fact-gathering process is a major knowledge-sharing exercise for the organisation and helps the organisation collaborate more closely. Assessment involves building definitive lists of whatever is being assessed, such as projects, or systems, or IT services, and answering standard questions for each item. The process is very collaborative, and is often the first time the organisation has worked closely across different teams. As well as understanding more about each other's areas, the assessment process creates loads of opportunities for tactical improvements.

Assessment gives management confidence to act more decisively. In the assessments I have been involved in, management often have a good grasp of what needs to be done, but they are held back by two things: they can not back up their "gut feel" with facts; and they are not confident that they fully understand the areas that have not recently been the focus of their attention. Assessment helps both of these. It shows how management's high-level perceptions of the situation can be traced back (or not) to real facts. It also demonstrates that the less well known areas have been examined. Effective assessment makes it much easier for management to be confident of their decisions and justify further investment.

Assessment helps build buy-in. People are often concerned about change, but asking them their opinions and getting them involved in fact-finding warms them up to the process. People who could be hostile to change become very enthusiastic for assessments because they see it as a way of getting their views across to management.

At the end of the process, the assessment delivers on its primary objective, such as identifying areas for improvement, assessing compliance, providing details for a transformation programme, or whatever. But along the way it delivers much more - a more detailed sense of direction, closer collaborative working, more confident and better justified decisions, and greater buy-in. On a personal level, although assessments may appear dull, it is a much more interesting and rewarding activity than it may seem. When you get into them, assessments are awesome.

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

Minimal IT strategy

The minimal IT strategy summarises how a business can manage its IT to improve long-term cost, risk and responsiveness.

Information technology - asset and liability

Information technology (IT) is a critical business asset. It improves business efficiency, and allows business to operate in ways that would not otherwise be possible.

IT is also a liability. IT adds cost and risk to business, and constrains the ease with which business can change.

To maximise the added value of IT, IT liability must be minimised. The best way to minimise IT liability is to minimise the size and complexity of IT and the demands on the IT department, while still delivering the required business efficiency and capability.

In order of priority, the three major ground rules for minimising IT are:

1. Be clear about the role of IT in business and align IT with business responsibilities. This makes sure that IT is properly controlled and does not become an end in itself.
2. Maximise the longevity of IT investments. This reduces the cost, risk and disruption associated with IT replacement.
3. Exploit existing solutions and implementations where possible. This reduces the amount of IT that has to be acquired, implemented, operated and maintained.

Business alignment and the role of IT

It is important to distinguish between the role of IT and the role of the IT department. The role of IT itself, the role of the computers and the networks, is solely to automate the handling of information. The IT department has a wider role advising business on IT, providing IT services, and analysing and managing business change associated with IT.

These roles must not be confused. IT itself is not a driver of business change, and attempts to use IT to force business change waste money and leave a legacy of underused IT that continues to be a source of cost, risk and constraint. To avoid this:

• Business ownership, direction and decisions will be established before IT solutions are considered.
• Business process change will be defined prior to IT change.
• The way in which IT will add value by automating the handling of information will be established before any IT acquisition or implementation commences.

It is also vitally important that IT is understood and governed by business managers.

To ensure that this is the case, IT capability will be structured into systems the ownership and capabilities of which fall clearly within the boundaries defined by business organisational structure and responsibilities. Similarly, connections between systems will reflect meaningful business information and hand-offs of responsibility through business processes. Clear and effective business ownership of all business systems and connections between systems will be strenuously enforced.

Structuring systems and connections to reflect business structure will be given a higher priority than technical efficiency. No attempt will be made to optimise business unilaterally by modifying IT structures; IT change will always follow and support business change, not lead it.

Longevity of IT investments

The longevity of IT is critical because reducing the frequency of major IT change reduces the annualised cost, risk and disruption associated with major IT change by exactly the same amount. This recognition permeates all decisions about the acquisition, development and management of IT systems.

Where IT systems are developed in-house, the priority for development, in addition to meeting immediate business requirements, is to ensure that the solution has the qualities and characteristics that allow it to be managed for a long period at low cost and low risk, and with flexibility to allow the solution to change with time. IT management will put a high priority on deliverables which have a significant impact on long-term management, such as modular design, documentation and automated test routines. The IT department will recognise and reward behaviours that increase long-term improvements in cost, risk and responsiveness, and not incentivise individuals to compromise this in favour of short-term project goals.

Where packaged IT systems are considered, the main focus of technical evaluation will be on the ability to continue to run the system without excessive cost, risk and disruption, a large part of which is to avoid being forced into difficult upgrades or reacquisitions by vendor policy. To achieve this, a large margin of preference will be given to open source solutions, and to solutions where usage conforms to viable multi-vendor standards. Similarly, a large margin of preference will be given to open source and standards-based operating systems and system software, and to non-proprietary standards-based hardware.

The business and technical environment in which IT operates changes constantly. As a general principle, it is cheaper and less risky to keep IT up-to-date than to suffer the greater expense and disruption of complete replacement of systems that can no longer operate in the changed environment. This principle will be applied in all cases, rather than dilute management effort by looking for exceptions.

Given the complex and dynamic nature of IT, it is easy to lose visibility of changes and their impact. To address this, a process of periodic evaluation and proactive maintenance will be applied to all IT systems, to ensure that they are kept continually up-to-date.

Where IT does eventually require replacement, the old IT will be aggressively and completely decommissioned, to avoid the ongoing cost, risk and constraint that would otherwise come from keeping it running.

Exploiting existing solutions and implementations

When making business system and technology acquisition decisions, we will always look to exploit existing solutions and implementations.

• Packaged software will favoured over in-house developed software.
• General-purpose applications will be favoured over completely bespoke applications.
• Software-as-a-Service will be favoured over in-house installed software.
• Cloud-based and on-demand infrastructure will be favoured over in-house infrastructure.
• Virtual infrastructure (servers and storage) will be favoured over physical infrastructure.
• Shared solutions will be favoured over individual solutions.

In each case, however, greater priority will be given to meeting business requirements, ensuring that the structure of the IT reflects real business structures and responsibilities, and ensuring that IT can continue to run indefinitely at low cost and low risk, and without constraining future business change.

Publication note: this is a double-length "summer special" edition of the Minimal IT newsletter. I shall be taking some time off over the summer, and the Minimal IT newsletter will return in a few weeks time.

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

Back to basics: Conflicts

Identifying areas of conflict opens up debate and helps us explore ways to deliver more value.

Over the past few weeks I have covered what I believe are the most important aspects for minimising your IT estate and IT demand, which is the key to long-term improvements in cost, risk and responsiveness.

I have covered:

• Focusing on the basic value proposition of IT: automating the storage, calculation and movement of information.
• Structuring IT so that it is easy to own and to manage.
• Managing IT proactively.
• Emphasising the qualities of delivered systems, such as documentation and testing, rather than development speed.
• Exploiting standards and open source.
• Using generic applications to reduce short-term and long-term costs.

Individually these ideas might not seem contentious, but taken together they form a controversial agenda. If you were to summarise a typical IT strategy, it would in many respects be the exact opposite:

The organisation will use IS to re-engineer business processes and create new business opportunities. All business data will be held on a single database to ensure a single version of the truth. Support costs will be strictly controlled to direct the maximum proportion of the IS budget to new systems, and rapid application development methods will be used to deliver new solutions quickly. We will partner with leading industry vendors, and enable business change through enterprise-grade commercial packages and in-house development.

It is useful to identify these conflicts with the mainstream view because it opens up and legitimises debate.

I also see a couple of conflicts within minimal IT. Some attempts to minimise IT estate and demand will increase it in other areas.

The first conflict is around proactive maintenance. Proactive maintenance works best when staff have a strong sense of ownership around systems. However, this can lead to an IT-led agenda, where the direction of the solution fits the interests and needs of the maintainers more than the users. I have seen the situation where staff do not bother with things like documentation and testing because they are so familiar that they do not see the need for it. And the architecture of closely-owned systems can be compromised when it is bent too much around one system, rather than more general standards. A strong, personalised sense of IT ownership can undermine the structure and discipline needed for effective long-term management.

The second conflict is around generic applications. Generic applications remove a lot of development cost and ongoing cost, and allow the organisation to focus more closely on their specific needs. However, the long-term manageability of solutions built on generic applications is problematic. You are very much at the mercy of the vendor, and you could be driven into replacement and upgrade activity that delivers no business value.

These internal conflicts within minimal IT do not worry me. If everything fitted together neatly, if I could present a perfect vision of minimal IT, I would be more worried. Real life is messy, and a world view without compromise is always suspect. Conflicts show us where we need to debate and to achieve balance. The more that we identify and articulate conflicts, the more we can improve how we manage IT and the value that we deliver.

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

Back to basics: Extreme reuse

Our prejudices stop us achieving the highest levels of reuse.

When we talk about reuse, we usually mean reuse of code. This could be low-level reuse, such as libraries, or higher levels, such as frameworks and services.

Reuse at this level is valuable. It helps deliver sophisticated systems faster. Provided that you manage it well, you can reduce long-term costs and risks by exploiting reusable libraries, and this contributes to minimising your IT.

Valuable though this is, this is not extreme reuse. Extreme reuse is when you don't write your own code at all, but use code that has already been written and, ideally, reuse system instances that are already running.

The most obvious example of extreme reuse is to implement packaged software, rather than write your own. Where there is packaged software that meets your needs and budget, it makes sense to use it.

But packaged software can have problems. They may be no packages that meet your needs well, or packages that have many more features than you need, which means it is more complicated to learn and to use. Packages can be very expensive. Using packages can give you a long-term dependency on a supplier which undermines your ability to control your own destiny.

How can we get the extreme reuse advantages of packages without the problems?

I think the answer is "generic applications". This is software, ideally provided as an on-demand service, which is generally capable of a broad range of IT requirements, and which you can quickly configure to your specific needs.

There are lots of different sorts of generic applications.

The commonest is Excel. Many businesses are run on Excel. Although we in corporate IT might look down on this, it is a way of meeting requirements closely at low cost.

Microsoft Sharepoint has some of the characteristics of a generic application. You can quickly build many types of information system based on Sharepoint.

Other software can be bent to many purposes. SalesForce.com has grown from its sales background into a more general tool. Even our own Metrici Advisor can be configured to support pretty much any business requirement.

We don't exploit generic applications anything like as much as we could. Large numbers of home-written systems and ill-fitting packages could be replaced by relatively simple configurations of generic applications.

There are challenges with this, especially with long-term management, which I will cover next week. Despite these challenges there is a large untapped potential. The main barrier is our attitude within IT.

Exploiting generic applications runs up against our prejudices. We feel that they must be second rate because they are not proper packages, neither are they proper bespoke systems. These prejudices apply both within the IT department and across the broader business. We want to protect our position as the purveyors of expensive packages and exquisitely tailored solutions, and our business colleagues want systems that are reassuringly expensive or which are unique to them. To exploit generic applications, to achieve extreme reuse, and to minimise our IT costs and risks, we have to overcome our own prejudices.

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

Back to basics: Standards and open source

Standards and open source are fundamental to reducing the costs and risks of your IT.

Everybody agrees that standards are a good thing. People like open source software because it is free. What is less clear is the effect that standards and open source have on long term IT costs and risks.

One of the main causes of excessive IT demand is technology refresh. This is IT demanding IT; costs and risks without business value. If the functionality of a product is based on standards there is less need to keep to the latest version. And when you do decide to upgrade, the impact is less because the new version will work the same way as the old.

For example, versions of Internet Explore (IE) before IE8 did not follow web standards closely. Upgrading from IE6 to IE7 and from IE7 to IE8 was important because of changes to how the browser works, but the upgrades were difficult. Because IE8 follows standards closely, there is much less of a need to upgrade to IE9, but many fewer issues with doing so.

One of the criticisms of standards-based software is that it represents the lowest common denominator and does not have all the bells and whistles of proprietary software. But if you want to minimise the costs and risks of your IT, this is a good thing. Using more stable, conservative products means that there is less to go wrong, and less opportunity for vendors to force you into expensive upgrades. And with standards, you are not stuck with one vendor. Once you are on IE8, you can switch to Mozilla Firefox or Google Chrome really easily.

The costs of open source software - free - can be very tempting, though in some cases that is offset by higher staff costs to understand implementation. What is more significant is the long-term dynamics of open source software. Because there is no vendor making money from upgrades, there is much less commercial pressure for you to take major, disruptive upgrades. Instead, there will be small upgrades to fix bugs and incrementally improve the product. It is easier to keep on current versions of open source software, without the hassle and expense of occasional major upgrades.

One of the arguments in favour of proprietary software is that you get more "out of the box". I am not sure that is true - modern Linux distributions contain hundreds of software packages. Where I think they differ is the ease in which you can opt for less. It is easy to get a minimal Linux server, which is just what you need for an efficient, secure and low-cost production environment. But with Windows you are stuck with a much larger footprint of functionality whether you need it or not. And all of that needs securing and upgrading. To minimise the extent to which IT demands IT, you need the option of using a much more stripped-down environment.

To minimise cost, risk and disruption, you need to be in control of the software that you use. Standards and open source achieve this in a way that proprietary software, however effective, can not.

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

To improve responsiveness, risk and cost, you need to stop obsessing about systems development.

We are obsessed with systems development. There are huge bodies of work about structured methods. There are huge bodies of work about agile development.

These are all very well and good. They help you deliver new solutions quickly, at low cost and with low risk. However, maintenance costs for IT systems are higher than development costs, and frequency of system replacement is the big multiplier for IT development costs. If you are trying to minimise unnecessary IT, maintenance and longevity are much more important than development.

It is about focus. The focus of all development methods is the same, whether they are traditional, waterfall, structured methods or newer, iterative, agile methods. Their focus is on the development process itself: they attempt to meet requirements with minimum cost and at lowest risk. This is a good aim, but the wrong focus. The costs, risks and responsiveness of systems development are only a very small part of the overall costs, risks and responsiveness of IT. To achieve minimal IT, our systems development should focus on reducing overall costs, risks and responsiveness, and not just optimising the the development process itself.

The key is to think about what the systems development process delivers - systems - rather than the processes by which it delivers them. To get closer to minimal IT, you need to focus on the qualities of the product of systems development, not the qualities of the process.

Other than meeting requirements, the important qualities of systems that are influenced by development are the ease with which systems can be maintained and modified. The three most important are to have a structure to the system that makes it easy to modify, to have automated regression tests that allows change to be made confidently and quickly, and to have documentation which helps people understand the system and which is easy to keep up-to-date. Without these the system will constantly demand more resources than it needs - IT demanding IT without delivering business value.

Processes are important. But the processes used for development are inconsequential when compared with the processes used during maintenance and support. If your maintenance and support processes preserve and enhance the structure, tests and documentation of the system, the system will continue to be responsive, change will be cheap and low-risk, and the system will last for a long time. Conversely, if you don't preserve these during support and maintenance, then your systems will quickly degrade, and become difficult, expensive and risky to change. You will quickly be forced into an expensive redevelopment or acquisition.

To achieve significant cost savings, you need to stop thinking about systems development. Instead of worrying about how quickly and cheaply you can deliver projects, worry about how long your systems last and how cheap they are to maintain. Put your efforts into maintaining effective, non-bureaucratic standards for automated tests and documentation. This is a far better way of improving responsiveness, risk and cost than obsessing about systems development.

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

Back to basics: Proactive IT management

The only way out of the mess of IT is to manage IT proactively.

We understand the term "legacy". As IT gets older it loses its structure, becomes harder to work with, does not keep up with new technology, and does not comply with new standards and regulations.

To me, legacy is the biggest issue in IT. Legacy makes IT difficult to work with and adds hugely to the cost of change. But most significantly, most IT change exists to replace legacy, not to meet new business requirements. Think about the major IT projects in your business. Are they totally new, or is a large part of their purpose, and the majority of their workload, to replace old, difficult, non-compliant IT? Legacy is the greatest driver of demand for IT. But it is value-less demand – IT demanding IT. To get closer to minimal IT, and to significantly reduce IT costs, we have to tackle legacy.

Tackling legacy is not a technical issue. We know what to do. We need to upgrade, refactor, replatform, maintain documentation and tests, manage bugs, and so on. For a small amount of investment, we can keep IT running smoothly without the huge costs and disruption of major legacy replacements. So why don't we?

There are two reasons. First, it is very hard to identify what needs to be done. How can you keep track of everything on all of your IT all of the time? It's almost impossible keeping things on supported versions of operating systems, let alone subtler issues such as ensuring effective business ownership and keeping documentation up-to-date. Second, even if we do identify what to do, how can we possibly justify proactive maintenance? How can it ever take precedence over business-driven change?

I think there is a solution to this problem, using a method which I call "system governance". This gives visibility and justification for proactive maintenance, without incurring a significant management overhead.

If you want detail, follow the links from System Governance for white papers and a process manual. But in summary, to tackle legacy you need gather the right body of information that:

• Presents IT as a set of systems, (see last week's newsletter) because this provides the best management view of IT.
• Is sufficiently high-level to be relevant to management, and sufficiently low-level to connect to the detail of IT.
• Covers everything that is important about your IT: how it is used, service and support, risks, development, technology, and breaks these down into meaningful high-level questions. The business value of each question needs to be expressed.
• Assesses each system against each question, capturing enough narrative to provide context to the assessment.
• Applies consistent calculations to identify what needs to be done, with links to question definitions and narrative to provide justification.

Whether you use exactly this approach or not, you need something like this to tackle legacy. You can not build your way out. If you do not have the information to manage IT, all your new projects, systems, architectures and technologies will themselves be legacy in a few short years. The only way out of the mess of IT is to manage IT proactively.

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

Back to basics: The importance of structure

To overcome the really big problems in IT we need to change how IT is structured.

The first really big problem is that IT projects are difficult, expensive and full of risk. The second is the legacy of old systems which are difficult to work with, run on out-of-date technology, and don't do what business needs.

Although these problems seem very different they can be traced back to a common cause: we structure IT for the convenience of technologists, not for the convenience of business and IT management.

In the past, IT has been expensive and technically difficult. We have found ways to make the best use of expensive resources and to make IT easier to implement. We have arranged IT into shared technical layers (network, operating system, database, application software, user interface) to exploit economies of scale and expertise. We have encouraged sharing of IT capabilities to reduce cost, and use common databases to allow different applications to share data.

We have successfully created structures which are optimised technologically. Buy they are misaligned to business and to long-term IT management needs. Most organisations are hierarchies of semi-autonomous departments defined by function. But IT is structured totally differently, as shared layers of technical capability.

If you follow the trail of cause and effect, nearly every major problem in IT has roots in the IT structures that we typically use. It is very difficult to make the connection between a business change and the required IT changes. This leads to IT-led business solutions, rather than business-led IT solutions. Everything is interconnected, and it is hard to identify and justify what needs to be done to keep IT current and manageable. Systems slip into unmanageable legacy. The sharing and connections between systems are so complicated that every change has a huge knock-on effect. The complexity of IT and the lack of effective business control leads to large, expensive IT projects that are prone to failure.

Read more on IT problem cause and effect.

IT is now much cheaper and we have developed much better ways of managing it. We have the opportunity to move to more aligned IT structures. The ideal is a set of separate, encapsulated capabilities which are meaningful in business terms and which provide appropriate units for IT management.

Although it is technically easy to move to a more aligned structure it is emotionally and politically hard. We have spent decades defending the structures that we have.

The first argument against aligned structures is that it makes it much harder to connect systems. However, modern methods of integration, particularly messaging middleware and web services, allow separate systems to work together seamlessly.

The second argument is that aligning IT to business structures preserves the inefficiencies of current business operations. However, a set of understandable, separate, but closely integrated systems is the best basis for enabling business to optimise processes.

To achieve minimal IT, we need to bend technology around structures that make sense to our organisations and which help us with the really difficult problems of long-term IT management. We need to move on from the structures of yesterday.


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

Back to basics: How IT creates value

Understanding how IT creates value lets you deliver smaller, simpler, cheaper and more usable IT.

But there is a problem: we do not understand how IT creates value.

If you read a typical IT project proposal, you would think that IT creates value by implementing technology and changing business processes. But implementing technology does not of itself deliver value. And although IT can help businesses work in different ways, of itself it does not change how businesses work.

Because we do not understand how IT creates value we make IT much harder than it needs to be. We implement more technology than we need to in the vague hope it will be more useful. We also muddle the delivery of IT with other value.

For example, it is important to manage stakeholders in a project. Because we do not understand how IT create value, we try to manage stakeholders by treating everyone's political agenda and wish list as requirements. Many of these requirements can never deliver value as part of an IT system, but because we do not have a way of identifying and communicating this we include them anyway. This adds to implementation and ongoing maintenance costs, increases complexity and undermines usability.

To get closer to minimal IT, we need a different model for how IT creates value.

The model is very simple.

IT delivers value when it gives you information that helps you do something faster, cheaper, more accurately or more reliably, or that helps you do something you could not otherwise do.

However, IT can not create information from nowhere. And an IT system which only shows you information you have just entered would not create value. To create value, IT must add value to information in at least one of three ways, and typically a combination of all three.

• Store. IT adds value to information by storing it so that it is preserved through time, more accurately than our memories and more conveniently than paper.
• Calculate. IT adds value to information by transforming and combining information to derive new information.
• Move. IT adds value by moving information through physical space, giving us information entered by other people or stored or calculated by other IT.

This simple model provides a very clear way of expressing the value of IT. The value of IT is the additional speed, cost reduction, accuracy, reliability or capability that is delivered by storing, calculating or moving information.

You can use this model to assess demands on IT and identify those that create little value.

The big enemy of IT value creation is the IT project. Of course we need to organise work, and co-ordinate IT changes with the business changes they supports. However, projects take on a life of their own, and the requirements of the project itself, which are often political and temporary in nature, become requirements on IT. You can use this model to weed out requirements that are nothing to do with IT, and which need to be managed separately from the IT delivery process. You can use it to identify the 20% of requirements that will deliver 80% of the value, and focus on those to deliver much smaller, simpler, cheaper and more usable IT.

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

Minimal IT: Back to basics

The best way to improve cost, risk and responsiveness in IT is to reduce the number of systems, the complexity of systems, and the unnecessary demands on the IT organisation.

I started writing these newsletters in 2005 because I was frustrated by waste in IT.

I am not frustrated by how we provide IT. Technology is faster and cheaper, and we have effective methods for creating, developing and operating IT systems.

I am interested in a different part of the cost equation. Costs can be calculated as a cost of supply per unit of IT multiplied by the amount of IT. My frustration is that we are very bad at managing the amount of IT: the number and complexity of systems and the demands put on the IT organisation. We have addressed efficiency, but we have not addressed the multiplier.

You can see evidence of excessive IT everywhere:

• Systems bloated with little-used features.
• Multiple systems doing the same thing.
• Unused CPU, network and storage.
• Unnecessarily complicated interfaces between systems.
• Legacy systems that are difficult to maintain.
• Expensive replacement systems which do little more than the old ones.
• Politically-motivated projects that deliver little value.
• Upgrade projects forced by vendor support policies.

All of these are symptoms of excessive size and complexity or excessive demands on the IT organisation. They cost money and take time but deliver little business value.

To make further gains in cost, risk and responsiveness, we need to systematically reduce the amount of IT we have. We need to deliver the same business value from a smaller, simpler footprint of IT systems and activities, or, as I would call it, we need minimal IT.

How important is this? If we had no more IT than we absolutely needed to support our businesses, and if the IT organisation only took on the minimum of work required to keep IT aligned to business needs, how much simpler and cheaper would IT be? My personal guess, for which I offer no explanation or evidence, is that there is a theoretical minimum of IT which is about one percent of what we typically have. It is very hard to get to the theoretical minimum, but I think it is reasonable to aim at delivering the same business value on about ten percent of the current amount of IT. That's a ninety percent saving on total IT costs.

To make these savings, we need to look in places that we currently ignore, and we need to challenge many widely-held beliefs. We won't get close to minimal IT by repeating well-worn platitudes; we need radical new ways of thinking.

I write these newsletters to force myself to keep thinking about minimal IT. Over the years I have covered six major themes:

• Understanding how IT creates value.
• Structuring IT systems effectively.
• Managing IT proactively.
• Following effective development practices.
• Adopting open standards and open source.
• Exploiting generic applications.

Over the next few weeks I will summarise each of these to build a more complete picture of how we can get closer to minimal IT.

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