Is the Windows registry a bad design? Judge for yourself.
As somebody who designs software, I am cautious of criticising other people's design. It is hard to understand all the requirements that have fed into a design, and all the issues that the designers have had to resolve. Any of my observations are surely things the designers must have thought about, and any problems I find surely less serious than the alternatives.
One of the heated debates that crops up now and again is the design of the Windows registry. The registry is a collection of files that act as a database of configuration information for Windows.
I would not like to criticise a core component of such a successful product. So instead, let me tell you what happened, and you can judge for yourself.
I was using a Windows XP machine at home, trying to get some PC TV software working, when Windows crashed, and I needed to reboot.
When I tried to reboot, I got a message saying that the registry was corrupt, and that Windows could not boot.
Is it good design that an error in an application should be able to corrupt the operating system so badly that it will not reboot?
I looked up the error message. Apparently I should be able to recover a non-corrupt version of the registry by using the command-line recovery console.
I tried this, but I have an original equipment manufacturer (OEM) copy of Windows which came with the PC. If you run the recovery console on OEM Windows, it mysteriously sets up new password-protected accounts and locks you out.
I do not know why this is, and the Microsoft pages provide no explanation. I suspect it is something to do with licensing, and that Microsoft consider that protecting their licensing is more important than my time, my data and my right to use the products that I have bought from them. I never saw "Warning: this is a crippled version of Windows that lacks critical recovery capabilities" on the box. Is it reasonable to remove the recovery capabilities from OEM versions?
I had to reinstall the operating system. It only took an hour or two.
I did not have to reformat the disk, and all my data and program files were still there after the reinstall. Some of the programs, such as OpenOffice.org, worked fine. But not Microsoft programs. I had to reinstall Microsoft Office because it relies on registry entries that had been wiped out during the reinstallation. Another hour or two.
Should recovering from a corruption in one application wipe out the configuration of another?
To help you decide whether the Windows registry is a bad design, I will summarise. The Windows registry is a single point of failure. It is a source of significant and unnecessary coupling between applications and the operating system, and between one application and another. The Windows registry makes Microsoft software harder to recover than its competitors. Important recovery capabilities are deliberately switched off on a very large number of PCs.
Is the Windows registry a bad design? I am cautious of criticising other people's design, so I will let you judge for yourself.
© Copyright 2007 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Tuesday, 31 July 2007
Tuesday, 24 July 2007
System governance in pictures
System governance can be summarised in just three pictures.
The scope of system governance can be illustrated using gear wheels.
This example shows the forces driving and restraining the implementation of a business process management (BPM) approach to better align IT systems with business requirements and to make IT more responsive.
The main drivers are a lack of responsiveness in IT and a need for new process support. Existing systems could be better exploited, and there is a need to improve the viability of existing systems.
The main restraining forces are cost and the difficulty of working with existing legacy systems. The IT organisation may not be confident to lead business process work. A BPM strategy may not have the long-term support it needs to be a success, and change is hampered by a lack of system knowledge.
On balance, the restraining forces are greater than the driving forces.
System governance changes this picture.
System governance makes existing systems more viable, which increases the driver to exploit them better, but reduces the pressure to increase their viability.
System governance increases knowledge of existing systems, makes them easier to work with, and provides a framework for the long-term support for BPM. System governance demonstrates how well the IT organisation meets existing responsibilities, and builds confidence for contributing to business process management.
On balance, the driving forces are greater than the restraining forces and BPM becomes viable.
We can use different force field diagrams for different situations, to show the different ways in which system governance delivers value. In each case, the contribution of system governance is to strengthen positive forces and to weaken negative forces.
Lastly, the way that system governance works can be summarised as a feedback loop.
IT decision making - from strategy to design - specifies the work required to implement and change IT systems. System governance completes a feedback loop from systems back to the decision making process, which guides decisions to better manage systems for the long term.
© Copyright 2007 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
The scope of system governance can be illustrated using gear wheels.
- System governance is a core technique, in the same way that architecture, project portfolio management, and frameworks such as CMMI or ITIL, are core techniques.
- System governance can contribute in many different ways. It can contribute to cost reduction, change management, organisational alignment, service delivery, compliance and quality. You can pick and choose which areas you want to apply it to.
- You can start using system governance in one area, and this helps you apply it in another area. For example, you might start using system governance to manage outsourced service delivery, but doing so helps you managing quality in projects.
- System governance is an ongoing, cyclic process, not a one-off exercise.
This example shows the forces driving and restraining the implementation of a business process management (BPM) approach to better align IT systems with business requirements and to make IT more responsive.
The main drivers are a lack of responsiveness in IT and a need for new process support. Existing systems could be better exploited, and there is a need to improve the viability of existing systems.
The main restraining forces are cost and the difficulty of working with existing legacy systems. The IT organisation may not be confident to lead business process work. A BPM strategy may not have the long-term support it needs to be a success, and change is hampered by a lack of system knowledge.
On balance, the restraining forces are greater than the driving forces.
System governance changes this picture.
System governance makes existing systems more viable, which increases the driver to exploit them better, but reduces the pressure to increase their viability.
System governance increases knowledge of existing systems, makes them easier to work with, and provides a framework for the long-term support for BPM. System governance demonstrates how well the IT organisation meets existing responsibilities, and builds confidence for contributing to business process management.
On balance, the driving forces are greater than the restraining forces and BPM becomes viable.
We can use different force field diagrams for different situations, to show the different ways in which system governance delivers value. In each case, the contribution of system governance is to strengthen positive forces and to weaken negative forces.
Lastly, the way that system governance works can be summarised as a feedback loop.
IT decision making - from strategy to design - specifies the work required to implement and change IT systems. System governance completes a feedback loop from systems back to the decision making process, which guides decisions to better manage systems for the long term.
© Copyright 2007 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Tuesday, 17 July 2007
IT process definition
Defining processes makes new ideas, techniques and products much more credible, and forces you to think through practicalities.
One of the great things about running a small business is that you can admit mistakes. You do not need to spin a tale about how you were right all along. There are no political repercussions, and as long as you have not let your customers down, no commercial impacts either.
Well, I was wrong. Last year, I was convinced that system governance did not need any significant process definition around it (see System governance: less is more). I have spent years of my life fighting with unwieldy methodologies, and did not want to burden our new technique with similar bureaucracy. I thought that the tool and materials we had produced were enough. Any organisation could weave system governance into what they do, without us defining processes for them.
Over the past year, I have spent some time working with a large systems integrator, who have rich processes defined for every aspect of their IT. Although some processes seem a bit bureaucratic, they do give predictability and control to the work. If we want to be successful in presenting system governance to companies like this then we have to show how it can fit into their rich and mature processes.
To address this, I spent some time writing a System Governance Handbook. This contains a complete set of processes for implementing and working with system governance, including roles, techniques, report templates, meeting agendas and training needs.
Defining processes has been much more valuable than I had imagined.
Having a complete "how to" guide shows that we are not just a tool vendor. We can now show a much more complete solution, which helps us present a much more credible offer.
Defining processes has forced us to think through system governance much more carefully. We have had to think through how to set objectives for system governance, and how to make system governance part of the decision making process of the organisation. We have had to consider how to deliver compelling investment cases out of system governance. We have had to think through an effective implementation process. Defining processes has turned an interesting idea into a ready-to-go practical proposition.
We have not completely abandoned our original ideas (perhaps I am succumbing to spin here). We have tried to keep unnecessary bureaucracy out of the processes. And we fully expect organisations to tailor the processes, and take the bits they need and weave them around their own processes.
But I have to admit to a change a heart. In hindsight, I can see that many of the proposals I have presented over my career would have benefited from more emphasis on process, and less emphasis on the nuances of the idea.
If you are struggling to get a new idea, technique or product accepted, spend some time thinking through processes for working with it. It will help you be more credible. It will force you to think about practicalities and interactions, and spot the problems and opportunities that you will face. And don't worry if doing so means you have to admit a mistake - I think you're in great company.
© Copyright 2007 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
One of the great things about running a small business is that you can admit mistakes. You do not need to spin a tale about how you were right all along. There are no political repercussions, and as long as you have not let your customers down, no commercial impacts either.
Well, I was wrong. Last year, I was convinced that system governance did not need any significant process definition around it (see System governance: less is more). I have spent years of my life fighting with unwieldy methodologies, and did not want to burden our new technique with similar bureaucracy. I thought that the tool and materials we had produced were enough. Any organisation could weave system governance into what they do, without us defining processes for them.
Over the past year, I have spent some time working with a large systems integrator, who have rich processes defined for every aspect of their IT. Although some processes seem a bit bureaucratic, they do give predictability and control to the work. If we want to be successful in presenting system governance to companies like this then we have to show how it can fit into their rich and mature processes.
To address this, I spent some time writing a System Governance Handbook. This contains a complete set of processes for implementing and working with system governance, including roles, techniques, report templates, meeting agendas and training needs.
Defining processes has been much more valuable than I had imagined.
Having a complete "how to" guide shows that we are not just a tool vendor. We can now show a much more complete solution, which helps us present a much more credible offer.
Defining processes has forced us to think through system governance much more carefully. We have had to think through how to set objectives for system governance, and how to make system governance part of the decision making process of the organisation. We have had to consider how to deliver compelling investment cases out of system governance. We have had to think through an effective implementation process. Defining processes has turned an interesting idea into a ready-to-go practical proposition.
We have not completely abandoned our original ideas (perhaps I am succumbing to spin here). We have tried to keep unnecessary bureaucracy out of the processes. And we fully expect organisations to tailor the processes, and take the bits they need and weave them around their own processes.
But I have to admit to a change a heart. In hindsight, I can see that many of the proposals I have presented over my career would have benefited from more emphasis on process, and less emphasis on the nuances of the idea.
If you are struggling to get a new idea, technique or product accepted, spend some time thinking through processes for working with it. It will help you be more credible. It will force you to think about practicalities and interactions, and spot the problems and opportunities that you will face. And don't worry if doing so means you have to admit a mistake - I think you're in great company.
© Copyright 2007 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Tuesday, 10 July 2007
Breadth-first IT management
We make IT hard because we get into too much detail too soon. We need a broad but shallow approach to IT management.
In computer science, searching algorithms can be defined as depth-first or breadth-first. Loosely speaking, depth-first gets right into the detail of one area first, and then if it does not find what it is looking for, moves on to the next. Breadth-first looks across all areas, and then works its way down gradually.
Something similar happens in IT management. We constantly suffer from information overload, and I think this is because we attempt depth-first IT management. We get into too much detail too soon, rather than standing back and looking more broadly at the problem.
As an example, what should we do to make IT more responsive?
It is really hard to find good, impartial, high-level information on the web.
To support system governance, I have been putting together a new website, governant.com, with one page summaries across the breadth of IT management topics. This has been much harder than I thought it would be. It is hard to find source material. Most information on the web is too detailed, too biased toward a particular product, or not based on real, practical experience. It is hard to draw out the key insights, and keep away from personal or commercial bias.
The hardest thing of all is to have the confidence to write only a summary. I worry that readers might think I do not know any more. I worry that readers might think I am patronising. Our attachment to detail is very ingrained. Having tried to write some, I understand why broad, high-level information about IT management is so hard to come by.
This is an important issue for IT. We focus too soon on one solution. We drown ourselves in detail. We need to learn to look more widely. We need to value the generalist mindset and the concise summary, without undermining the valuable contribution of the specialist.
We need depth in IT, but we need breadth first.
© Copyright 2007 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
In computer science, searching algorithms can be defined as depth-first or breadth-first. Loosely speaking, depth-first gets right into the detail of one area first, and then if it does not find what it is looking for, moves on to the next. Breadth-first looks across all areas, and then works its way down gradually.
Something similar happens in IT management. We constantly suffer from information overload, and I think this is because we attempt depth-first IT management. We get into too much detail too soon, rather than standing back and looking more broadly at the problem.
As an example, what should we do to make IT more responsive?
- A server administrator might recommend symmetric multiprocessing systems and VMware virtualization to allow changing business volumes to be accommodated easily.
- A designer might recommend SOAP, .Net and web services that allow existing functionality to be recombined to support changing business process needs.
- Support staff might recommend tools to analyse the cyclic complexity of legacy systems to identify candidates for preventative maintenance.
- An IT personnel manager might recommend competency frameworks for multi-skilled resources and strategies for flexible sourcing.
- An enterprise architect might recommend mapping the whole of IT to the TOGAF framework to identify areas for improved responsiveness.
It is really hard to find good, impartial, high-level information on the web.
To support system governance, I have been putting together a new website, governant.com, with one page summaries across the breadth of IT management topics. This has been much harder than I thought it would be. It is hard to find source material. Most information on the web is too detailed, too biased toward a particular product, or not based on real, practical experience. It is hard to draw out the key insights, and keep away from personal or commercial bias.
The hardest thing of all is to have the confidence to write only a summary. I worry that readers might think I do not know any more. I worry that readers might think I am patronising. Our attachment to detail is very ingrained. Having tried to write some, I understand why broad, high-level information about IT management is so hard to come by.
This is an important issue for IT. We focus too soon on one solution. We drown ourselves in detail. We need to learn to look more widely. We need to value the generalist mindset and the concise summary, without undermining the valuable contribution of the specialist.
We need depth in IT, but we need breadth first.
© Copyright 2007 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Monday, 2 July 2007
What is Application Portfolio Management?
Application Portfolio Management (APM) is set to become the next big thing in IT. But different vendors have a very different view of what it is.
If you search for Application Portfolio Management (APM), you will find two things: industry analysts such as Gartner and Forrester making very bold claims about the value of APM; and leading tool vendors positioning their products as APM tool sets.
What is APM, why is it so valuable, and what should you do about it?
APM starts with the realisation that your existing IT applications are a major asset and a major cost. They underpin the IT services you provide. They are the starting point for any IT changes you make. You spend 70% or more of your IT budget running and supporting your existing applications.
Despite their importance, applications get little management attention. We put our effort into managing change, and day-to-day service delivery. We rarely make applications themselves the object of our management.
If we focus on managing applications, we can begin to get a grip on this major business asset. We can make a case for proactive maintenance that can cut support costs. We can escape from the trap of legacy systems. We can reduce risk. We can make change easier. We can transform our application portfolio to better meet the needs of our business.
All APM approaches have similarities. They all involve building an inventory of applications, and assessment and analysis to drive business decision making.
There are differences of emphasis between different APM offers. Some are low level, and are based on automatic code analysis. Others emphasise large-scale transformations. Others are more allied to project portfolio management (PPM). In many cases, these differences reflect the background of the vendors; the APM offers are built around, or incorporate, other products.
To deliver most value, I believe that APM needs to be separated from other disciplines.
I firmly believe that APM is the next big thing. It reflects IT's coming of age - moving from a dash for growth to a more mature management of what we have. When you look at APM, have a look at system governance too. Even if you decide that system governance is not for you, it will at least provide good food for thought as you evaluate other vendors.
© Copyright 2007 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
If you search for Application Portfolio Management (APM), you will find two things: industry analysts such as Gartner and Forrester making very bold claims about the value of APM; and leading tool vendors positioning their products as APM tool sets.
What is APM, why is it so valuable, and what should you do about it?
APM starts with the realisation that your existing IT applications are a major asset and a major cost. They underpin the IT services you provide. They are the starting point for any IT changes you make. You spend 70% or more of your IT budget running and supporting your existing applications.
Despite their importance, applications get little management attention. We put our effort into managing change, and day-to-day service delivery. We rarely make applications themselves the object of our management.
If we focus on managing applications, we can begin to get a grip on this major business asset. We can make a case for proactive maintenance that can cut support costs. We can escape from the trap of legacy systems. We can reduce risk. We can make change easier. We can transform our application portfolio to better meet the needs of our business.
All APM approaches have similarities. They all involve building an inventory of applications, and assessment and analysis to drive business decision making.
There are differences of emphasis between different APM offers. Some are low level, and are based on automatic code analysis. Others emphasise large-scale transformations. Others are more allied to project portfolio management (PPM). In many cases, these differences reflect the background of the vendors; the APM offers are built around, or incorporate, other products.
To deliver most value, I believe that APM needs to be separated from other disciplines.
- APM must be a management-level discipline. Anything that starts with code scanning is unlikely to be sufficiently high level to justify and drive through significant change.
- APM must be separate from PPM. The ongoing management of applications is different from the management of projects.
- APM is a fundamental, ongoing discipline. It is not just a one-off exercise to support a transformation.
I firmly believe that APM is the next big thing. It reflects IT's coming of age - moving from a dash for growth to a more mature management of what we have. When you look at APM, have a look at system governance too. Even if you decide that system governance is not for you, it will at least provide good food for thought as you evaluate other vendors.
© Copyright 2007 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Subscribe to:
Posts (Atom)