While fixing bugs and adding new features to get a program ready for release, we don’t usually think about where it all goes. For us, software is just a patient on the desktop who needs to be dissected, completed, changed, cured and got working.
Most of the methods we use to guarantee software quality stem from this worldview. We spend so much time on good architecture, object oriented approach, MVC, code formatting and comments that we often wonder is where do the horrible programs come from? Beautiful programs should have long ruled the world.
But if we’re completely honest, they do. There are millions of beautiful, charming and inspiring pieces of software around the world! The problem is that as developers, we judge their beauty from a professional point of view just as a surgeon would say a person is beautiful by looking at their internal organs, while the rest of the world applauds curvy blondes.
How do you make developers create code that isn’t just quality but also useful to the users? Many people have tried to answer this question, but so far, the English government has been the most successful. The idea it is based on was quite simple – to gather information on enough projects, divide them into successful and unsuccessful ones, determine the criteria that define them and create a set of rules thereof. Needless to say, there were more than enough organization automation projects to do so. An assembled group of experts (after first promising the distribution of pink elephants (https://www.pinkelephant.com/), carefully processed the statistics and created the ITIL library. The library is becoming more and more popular, it has already been through two reincarnations (the freshest and most popular version is ITIL V3) and most importantly, it explains what the user needs, how they should organize their entire IT-infrastructure, and how to evaluate from their point of view, what is beneficial, what is harmful and what is useless. The best part is that it works regardless of whether the user knows their desires and can verbalize them. If, of course, they are at all interested in using IT in their business.
The basis of ITIL
The first thing we encounter when getting to know ITIL are the common concepts and terms which may be quite different from expectations. ITIL itself is a library of recipes applicable for organizing IT. The method of managing IT services based on these recipes is known as ITSM (IT Service Management). ITIL v3 consists of several fundamental books, which cover the organization of various spheres of work within a company’s IT-infrastructure.
A key concept of ITIL and the basis of the rest of its ideology is the Service. ITIL v3 defines a service in the following way: A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. Take note that in this case, value means the achievement of an interim goal during the work process. This definition is very different from the generally accepted definition of Service as used by developers (An extended set of functionality in the web).
Not only and not necessarily a set of software functionality. Roughly speaking, we think that a new gun model is a new way to hunt, but for it to really become a new way to hut, we need to first unpack, adjust, load, and then the hunter must use it. All this is considered by ITIL to be an integral part of service.
A way of providing Value to the customer. Clients don’t use software because it’s simple, convenient to use, or due to its beautiful architecture, they use it because it provides them with value, which is in turn limited by the production process in the context of which the customer thinks. Test yourself. Answer which sorting algorithm is better, Quicksort or the traditional bubble method? What about cases when there are less than ten elements? Or when you just need it to explain sorting principles themselves?
“Free of risks and troubles” is another important point. All the developers’ hard work, which is so hard to assess and control from the point of view of the development process, is judged by users with just one fault proof scale – whether or not their workflow is free of risks and troubles. How long has it been since we ourselves wrote angry forum posts about the lack of a Start button in the new Widows version? Did you think then about the obvious improvements in the functionality and reliability of the OS? How often do you show understanding with real world support services when you have a blackout or when your internet is down?
The structure and place of ITIL
The following picture is an illustration of the areas covered by ITIL 3 methodologies:
This way, ITIL’s main goal is to derive value from the existing infrastructure’s workflow. However, since in real life the existing infrastructure is never enough, ITIL also covers forming requirements for new software, and includes its acceptance, testing and commissioning processes.
The structure of ITIL v3 consists of five fundamental books and looks thusly:
Let’s look at their content in more detail...
Service Strategy is the first of the ITIL fundamental books, which concerns the strategic questions of this concept and how to approach them. When you understand a service, you also need to understand the principles behind the service approach, development strategy, financial and economic aspects of the strategy. The Case theorem is used as the basic approach for understanding a service’s usefulness. Options for strategy formulation and further strategic development are usually chosen from the following:
Strategy as a perspective;
Strategy as a position;
Strategy as a plan;
Strategy as a template
According to the authors of ITIL, the most important areas for the formation of an integrated strategy are:
Definition of objectives, where the objectives are strategic assets, which give the company a competitive advantage, the development of proposals in the IT area to increase this advantage and the implementation and promotion of these proposals;
Financial and Economic aspects, including financial, investment and service management.
Organizational aspects: the management of user needs, ways of organizing employees in the IT field, and ways of organizing service to collaborate and participate in the support of various business processes;
Implementing strategies guided by the concept of a service’s life-cycle, which includes issues of design, development, operation and continuous improvement of services provided to the user, as well as assessing and monitoring their quality.
Note that from the point of view of the strategy, using software and equipment and adding IT to the company are neither an end in itself, nor necessary. Moreover, if the software is unique, it still has to compete with “empty software” and there are many cases when the absence of a piece of software within a service is preferable to its users and more beneficial for the company.
Service Design details the principles that should be used in the proper development of IT infrastructure. In the process of designing services, among other things, we determine the need for new software. We define a set of primary requirements, choose a contractor. Choosing a contractor is usually done by finding the balance between:
The service’s functionality (business- and system);
Its cost (Including financial, production and human resources);
The time in which the service must be ready for operation.
Apart from the software requirements, service design usually involves answering questions such as those about its launch and management in the future. The design process itself is usually organized based on the RACI matrix (Responsible, Accountable, Consulted, Informed), which states that the participation of each person in a task can be of four types:
Responsible – the participant takes part in working on the task;
Accountable – the participant responsible for the task (only one should exist);
Consulted – participates as a consultant;
Informed – should monitor the progress of work and receive information on the progress.
In some cases, the extended RACI-VS matrix is used, which adds the following roles:
Verifies – Person or group, who check compliance to certain criteria;
Signs off – A person who registers goal completion and decides on when to release the product (this role is compatible with the Accountable role).
There is actually one more variation of this matrix, RASCI, which includes:
Supportive – people, who ensure the support of the main workflow.
Another reason why we don’t usually know much about ITIL is that the library doesn’t formalize the development process. For us, it can be Agile or Waterfall or something else but for users, it’s just a black box which swallows requirements and produces ready software. Nevertheless, there’s a whole book devoted to what to do after the software comes out of the black box – Service Transition.
The main aim of the service transition process is the deployment and commissioning of new versions of services into the general office environment. The basis of the process is usually a formal agreement, which should be documented and used whenever the service is deployed. It is important primarily because an incorrect service transition process can bring serious financial loss to the enterprise using it. Why do I underline the fact? The most important things for us are software’s functionality, algorithms, database structure, things like that, but users are most interested in DATA. In the user’s hands, data structures aren’t filled with abstract values like “123”, “test”, “hello”, “helloworld”, “test again”, but real life facts which are translated into money. And since, as I’ve mentioned before, software always replaces something, the problem of adapting old data for new models should always be closely attended to, if possible, from the very start of development.
The moment software is deployed is when the user’s interests are most at risk – that’s when he gives your product the most valuable thing he has – INFORMATION.
The transfer of software to release is usually accompanied by several testing stages and is often connected with the use of continuous Integration tools. There are some de-facto differences about what can be considered the end result.
Developers consider the end result to be a signed act of transfer and the final payment.
Clients consider the end result to be the use of software as it was intended.
Achieving both of these results is the desired outcome of the project. Some of you may be thinking about situations where the developers hand over a program and disappear leaving their clients to struggle. To be fair, there are other possibilities, such as users working on an old version, not noticing any bugs and saying no to new features. The best situation to have is somewhere in the middle.
The main goal of organizing the service transition process is to avoid protracted, antagonistic conflicts between teams, caused by a lack of understanding and, most likely, different corporate interests. In order to prevent and resolve conflict, you can use both formal documents (SLA, TA, etc.) and informal initiatives to eliminate misunderstandings and increase the overall conceptual context between the development and operating teams.
Service Operation is our clients’ internal material which still holds a lot of interesting information. From our point of view, what’s worth looking into isn’t the set of methods for organizing the work of users with the software but its output regulations and documents. There may be, for example, regulated recipes for circumventing bugs that the developers never got around to fixing. However, the main purpose of analyzing information about what is actually happening in the company during its operation is to understand how successful and useful the software implementation was, where its bottlenecks are, etc. The book is interesting and useful in general, particularly to provide an understanding of where and how the software is used in real life.
Continual Service Improvement
The last of the books in ITIL v3 is dedicated to self-reflection - tracking what processes go on in your organization and increasing the quality of used services. The most important tenet of the book is that the improvement of corporate IP must take place constantly and continuously. The methodologies used to achieve it are extremely varied. They include measuring the technical performance of IT services, their effectiveness interacting with users, their lifecycle phases such as the PDCA and SWOT. Knowledge of CSI principles helps us analyze what is happening within our clients’ IT infrastructures, suggest decisions, win their trust and make software that is difficult to say no to. Provided, of course, that the client regularly shares their IT infrastructure monitoring data.
All this is, of course, entertaining (albeit somewhat speculative) but why do developers need to know about lowly user concepts? Our job is to worry about the quality of the code!
Maybe that’s the way things ought to be but reality is quite different. Users don’t care about any of our technical holy wars. Moreover, it turns out that there is a much larger chasm between developers and users then we initially thought and crossing it is something not every software product can achieve. I believe it’s time to start thinking about how to make our software more useful for the user and ITIL can help with that.