Sustainable IT isn't about low-power hardware and recycled paper. It's about recognising the importance of the ongoing management of IT.
It's a pity when really useful words get hijacked.
One such word is "sustainable". If you search for "sustainable IT", you get references to power consumption and going green. But sustainable means "able to keep going". And power consumptions is only one very small part of keeping your IT going.
In the full sense, "sustainable IT" encompasses everything you do to keep IT going indefinitely.
There are many parts to this.
You need to consider continuity of service. In the short term, this includes effective and repeatable processes for service delivery.
In the longer term, this includes everything you need to do to keep the service running smoothly. It includes managing performance. It includes ensuring that systems stay on current versions. It includes constant management of security. It includes plans for system recovery.
You have to sustain value through time. In part, value is sustained by sustaining service. But there is more to it than that. You have to start with IT that has a clear value, and avoid pet projects that have no proper business case. You have to add to the value, by being aware of and responsive to changing business conditions. If you have change request processes that are too good at saying "no", you will undermine the sustainability of value.
You have to think about sustainability of cost. This includes running costs, such as the choice of low-cost hardware and software, low power consumption, and good utilisation of resources. For example, you can use virtualization to make better use of the server resources that you have.
Cost sustainability includes replacement costs. If you let systems grow old prematurely, you incur replacement costs sooner. If you select and manage systems for longevity, and design them so that you can replace the ageing pieces independently, replacement costs can be hugely reduced.
IT must be able to keep going though organisational change. This includes user and support personnel changes. Properly managed, easy-to-use systems with good documentation survive these sorts of changes much better.
IT must also be able to survive major organisational changes, such as mergers and acquisitions. This is hard, but having IT with clear purpose and strong ownership makes this much easier.
I am sure I have missed out a lot, but you get the idea. Sustainability permeates the whole of your IT management effort. Everything you do, other than running projects and day-to-day service delivery, is about managing IT so that it can keep going. You need to use "sustainable" in the full sense, so that you have a good word to describe this responsibility.
Even if you are only concerned about energy, you need to think about all types of energy consumption through the whole life of your IT. You need to think about the energy costs of disruption and replacement. You need to make sure your IT delivers as much business value as possible per kilowatt-hour. You need to reduce the energy-consuming activities associated with retraining and reorganising, such as travel. To achieve "sustainable IT" in the narrow sense, you have to think about "sustainable IT" in its fullest sense.
© Copyright 2009 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Tuesday, 24 February 2009
Tuesday, 17 February 2009
All killer apps tend to FOSS
Free and open source software is constantly improving, and becoming more of a challenge to paid-for, closed-source software. Where will it end?
In my company, we decided some years ago to use free and open source software (FOSS) where practical because it is easier to manage in the long term and strategically significant (see Free software - never look back and Cheap IT turns competition upside down).
FOSS is even more compelling today than when we made that decision.
To illustrate, we recently bought new servers to help with our development and testing. We installed the CentOS 5.2 Linux operating system (basically a free clone of Red Hat Enterprise Linux).
Installing Linux is a easier than it used to be. All the server administration functions - such as firewalls and service management - are easy to manage through the GUI. It was easy to set up, and has worked perfectly.
We need multiple development and test environments. We used the Xen virtualization software that comes as part of CentOS to create virtual machines running inside the main CentOS server to give us as many test machines as we need. Virtualization is of course available in paid-for software, but we found Xen simple, and there are no licensing restrictions on the Linux instances that we run.
It is not just on servers that FOSS keeps getting better.
Over the last week, I have installed the desktop version of Ubuntu Linux, used OpenOffice.org version 3 to recover a corrupt Microsoft Word file that Microsoft Office could not read, installed the MuseScore music composition software as a free alternative to the (very expensive) Sibelius, and installed the latest and greatest version of Gimp.
Slowly, steadily, FOSS keeps getting better. The advantages of freedom (both freedom of cost and freedom of action) are gradually outweighing the functionality and support advantages of paid-for software. Where will it end?
I have some observations.
- All killer apps tend to FOSS. FOSS works well for operating systems, systems software, and widely used applications.
- However, there are still huge opportunities for both FOSS and paid-for products. There are thousands of smaller niches where neither FOSS or paid-for products dominate.
- Commercial software co-exists with FOSS by providing "value add" such as additional functionality, hosting or support. Many leading FOSS products are now owned by organisation that provide a paid-for option as well (we could call this FOSS+).
It is an interesting time for us in IT, who are consumers, advisers and providers of software. As consumers and advisers, we should always consider FOSS, and weigh the freedom and cost advantages of FOSS against the value-add of the alternatives. If FOSS is not appropriate, FOSS+ may provide a good combination of freedom and added value. We have many options, such as FOSS for development and FOSS+ for production.
As providers, we need to consider our options carefully. FOSS can be a useful channel, or a serious competitor.
I really do not know where all this will end. Paid-for software is far from dead, and maybe both approaches will continue indefinitely. All I am sure is that it won't end any time soon, and we will be discussing free and paid-for software for many years to come.
© Copyright 2009 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Tuesday, 10 February 2009
Why we should talk about systems
When discussing IT with our non-IT colleagues, we should not start with details of technology, or business concepts like processes and drivers. We should usually start by talking about "systems".
One of my sons really enjoys sport. Because he is so active, he gets more than his fair share of bumps and bruises. He fell badly onto his knee and it swelled up. We took him to the doctor, who sent him to the local hospital for an X-Ray.
At the hospital, the radiographer found his details. The details said he lived at an address we haven't lived at for more than ten years. We would have thought that the records would have come from the local doctor, or from a nearby larger hospital, where our son had been more recently.
To give another example, I used to work for one of the UK's largest retailers. We were taken over by a mail order group. One of the reasons they gave to their investors was that they were acquiring us for our "customer database".
In the IT department we thought this was very funny. Being a large retailer, we had a large number of customers (a large "customer base"). We had a lot of detail about what our customers bought (a "sales database"). But we didn't have a "customer database" holding names and addresses of people for mail order.
These two anecdotes illustrate how we in IT we should talk to our non-IT colleagues.
We should not talk about technical detail. In the hospital example, there will be detail about data stores, interfaces, archiving and purging that meant the hospital had the wrong records. In the customer database example, there are details about sales data processing, mainframe and UNIX servers, and a SQL Server database for understanding customer behaviour.
But neither should we start by talking about business processes and drivers. We should not initially discuss data accuracy responsibilities and processes for managing patient records. In the customer database example, we should not start by talking about increasing customer reach or the value of sales data analysis.
Why not? Our responsibility is to advise on the IT. We need to start with the obvious. In the hospital example, the starting point is, "The system is wrong". We can then work out from this with questions, such as "Who owns the system?", "What patient data is held in the system?", "What rules does the system have for keeping data up to date?"
In the customer database example, the starting point is "We do not have a system that stores customer names and addresses". We do not have to talk about technology, or about broader business aspirations.
There are times when we need to talk about business concepts or about technical details. But most of the time IT is much simpler. Our non-IT colleagues have a notion of "IT systems". We can use that as the starting point for communication. We can talk about what information systems store, process and communicate, and systems boundaries and scope.
And our son? He has Osgood-Schlatter disease, which is temporary swelling of the knees common in over active boys of his age. He's fine.
© Copyright 2009 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
One of my sons really enjoys sport. Because he is so active, he gets more than his fair share of bumps and bruises. He fell badly onto his knee and it swelled up. We took him to the doctor, who sent him to the local hospital for an X-Ray.
At the hospital, the radiographer found his details. The details said he lived at an address we haven't lived at for more than ten years. We would have thought that the records would have come from the local doctor, or from a nearby larger hospital, where our son had been more recently.
To give another example, I used to work for one of the UK's largest retailers. We were taken over by a mail order group. One of the reasons they gave to their investors was that they were acquiring us for our "customer database".
In the IT department we thought this was very funny. Being a large retailer, we had a large number of customers (a large "customer base"). We had a lot of detail about what our customers bought (a "sales database"). But we didn't have a "customer database" holding names and addresses of people for mail order.
These two anecdotes illustrate how we in IT we should talk to our non-IT colleagues.
We should not talk about technical detail. In the hospital example, there will be detail about data stores, interfaces, archiving and purging that meant the hospital had the wrong records. In the customer database example, there are details about sales data processing, mainframe and UNIX servers, and a SQL Server database for understanding customer behaviour.
But neither should we start by talking about business processes and drivers. We should not initially discuss data accuracy responsibilities and processes for managing patient records. In the customer database example, we should not start by talking about increasing customer reach or the value of sales data analysis.
Why not? Our responsibility is to advise on the IT. We need to start with the obvious. In the hospital example, the starting point is, "The system is wrong". We can then work out from this with questions, such as "Who owns the system?", "What patient data is held in the system?", "What rules does the system have for keeping data up to date?"
In the customer database example, the starting point is "We do not have a system that stores customer names and addresses". We do not have to talk about technology, or about broader business aspirations.
There are times when we need to talk about business concepts or about technical details. But most of the time IT is much simpler. Our non-IT colleagues have a notion of "IT systems". We can use that as the starting point for communication. We can talk about what information systems store, process and communicate, and systems boundaries and scope.
And our son? He has Osgood-Schlatter disease, which is temporary swelling of the knees common in over active boys of his age. He's fine.
© Copyright 2009 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Tuesday, 3 February 2009
The day Google broke the Internet
The recent problems with Google are a wake up call to keep the Internet as a tool of freedom, and not let it become a tool of control.
The entire Internet broke for about 30 minutes on Saturday 31 January, or so it seemed to many people.
My father was one of them. He telephoned to say that he could not get on to any website, that they had all been labelled harmful. He joked that it was a takeover by a totalitarian regime, who had banned all his favourite web sites.
What really happened was rather less sinister. Google maintains a list of badware sites that are known to contain scams, viruses and other malware, and warns users before they click from their search results onto these sites. It is a very useful feature. But for a short time on Saturday, it blocked all websites.
Apparently it was a simple human error. Something as simple as adding a "/" to a list of badware sites.
The problem is that Google has become fundamental to the Internet. Not only does it have an 80% share of Internet search, people now use it instead of the address bar. Instead of typing http://news.bbc.co.uk, people type "bbc news" into Google. So this was not just a problem with search. It was, to many people, a complete breakdown in the Internet's addressing system.
From our technical perspective, it is easy to make excuses for this sort of problem. We have all seen, or even caused, big IT interruptions. We know it was only a temporary application problem, and not a fundamental problem with the Internet.
But this technical perspective blinds us to something more serious. From its inception, the internet was designed to be resilient, to cope with the loss of servers and the loss of network connections. The addressing system is similarly resilient, based on multiple name servers without a single point of central control.
All this engineering was undone, albeit only temporarily, because somebody added a "/" to a list of badware sites.
This is a wake up call. This simple human error shows how fragile the Internet could become. The vast majority of Internet search, addressing, email, chat, mapping, and so on, are now controlled by a small number of large players. It may not have been the act of a totalitarian regime, but Saturday's incident shows how this concentration of control could be used to take over the Internet.
I have nothing at all against Google, but the Internet is too important to have this sort of failure and to run this sort of risk. I do not believe the answer is more control and regulation, but more of what the Internet is built on: standards, and multiple, independent implementations.
We, who have at least some knowledge of the Internet, have a serious responsibility. We must use and promote standards, especially standards that encourage multiple, independent but interoperable implementations. We must avoid single points of failure and single points of control, however convenient and benign they are. Only this will keep the Internet working, and keep the Internet free.
© Copyright 2009 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
The entire Internet broke for about 30 minutes on Saturday 31 January, or so it seemed to many people.
My father was one of them. He telephoned to say that he could not get on to any website, that they had all been labelled harmful. He joked that it was a takeover by a totalitarian regime, who had banned all his favourite web sites.
What really happened was rather less sinister. Google maintains a list of badware sites that are known to contain scams, viruses and other malware, and warns users before they click from their search results onto these sites. It is a very useful feature. But for a short time on Saturday, it blocked all websites.
Apparently it was a simple human error. Something as simple as adding a "/" to a list of badware sites.
The problem is that Google has become fundamental to the Internet. Not only does it have an 80% share of Internet search, people now use it instead of the address bar. Instead of typing http://news.bbc.co.uk, people type "bbc news" into Google. So this was not just a problem with search. It was, to many people, a complete breakdown in the Internet's addressing system.
From our technical perspective, it is easy to make excuses for this sort of problem. We have all seen, or even caused, big IT interruptions. We know it was only a temporary application problem, and not a fundamental problem with the Internet.
But this technical perspective blinds us to something more serious. From its inception, the internet was designed to be resilient, to cope with the loss of servers and the loss of network connections. The addressing system is similarly resilient, based on multiple name servers without a single point of central control.
All this engineering was undone, albeit only temporarily, because somebody added a "/" to a list of badware sites.
This is a wake up call. This simple human error shows how fragile the Internet could become. The vast majority of Internet search, addressing, email, chat, mapping, and so on, are now controlled by a small number of large players. It may not have been the act of a totalitarian regime, but Saturday's incident shows how this concentration of control could be used to take over the Internet.
I have nothing at all against Google, but the Internet is too important to have this sort of failure and to run this sort of risk. I do not believe the answer is more control and regulation, but more of what the Internet is built on: standards, and multiple, independent implementations.
We, who have at least some knowledge of the Internet, have a serious responsibility. We must use and promote standards, especially standards that encourage multiple, independent but interoperable implementations. We must avoid single points of failure and single points of control, however convenient and benign they are. Only this will keep the Internet working, and keep the Internet free.
© Copyright 2009 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Subscribe to:
Posts (Atom)