IT Trends Impacts (Part 1)
Context evolution and their impacts
It is clear that new IT trends tend to strongly destabilize the already fragile process implementation. These changes, each one in its own way, seem to announce a programmed end of process approach such as organizations experience today. Should we abandon it? This chapter highlights the nature of changes, their impacts and the possible responses to these upheavals.
The illustration below shows how evolutions exert pressure on processes:
Business contraints evolution
Either to grow or face competitive pressure, businesses are in constant motion: they release new products, reposition on new markets, take higher commitments in order to seduce new customers or retain existing ones. Agility and operational excellence are key success and even survival factors for these businesses.
IT Service, at the heart of business strategies, must also contribute to operational agility and excellence. IT changes are more frequent and their nature tends to change. A lot of these changes must take place while keeping IT Service available for users or external customers (e.g. order taking and other online services encountered in various business sectors).
Change Management historical processes based on long and very structured preparation requiring Service interruption, are no longer adapted.
IT Service Lifespan
This very changing context leads businesses to consider shorter life spans for IT Service. Constant strategic repositioning lead businesses to invest in temporary (even “disposable”) solutions, with lighter IT systems in terms of solutions, complexity and cost.
These choices lead organizations to reconsider Change Management process constraints. They accept fewer norms and controls aimed at anticipating risks and maintaining availability when they are not economically justified in their eyes. Given IT Service lifespan, organizations prefer to invest in adequate Incident Management, which, in their opinion, fully compensates the risks taken on change preparation, in a reactive manner.
Evolution of Architectures and Technologies
New application architectures, also called “software packages”, based on functional or business logic (e.g. SOA), make evolutions or implementation of correctives more independent, according to modules. “Highly available” infrastructure architectures (e.g. totally redundant equipment, “load balancing”, etc…) make it possible to consider maintenance or change operations without IT Service interruption.
Facilities brought by technology show that changes can be carried out more easily with less risks. In time, stakeholders in charge of change can reasonably expect to get rid of the constraints of a structuring process and abandon most of the precautions taken.
Evolution towards Virtualization and Cloud computing
Virtualizing most IT resources (servers, warehousing, networks, workstations, applications, etc…) fundamentally changes IT Service availability for end-users. Also everything appears easier because there are no more physical deployment constraints. New approaches about virtualized resource supply through PLCs (orchestrators) and self-service portals which surf on trends such as Cloud Computing and mobility (and concepts such as “Bring Your Own Device”), make change seem easier than before. Change, historically perceived as specialists matters, become simple “standard change”, managed on demand.
However, if deployment is simplified, design still remains complex. Risks of error not only persist, but on the contrary, can be more easily deployed through implemented automatisms. So, if change models must adapt to new data circulation technologies, embedded quality control principles must absolutely be preserved, in order to ensure IT Service stability.
Evolution of Organizations
As a result of the vital position of IT Service at the heart of business strategy, IT organizations themselves undergo change. Business Units re-appropriate Design duties to manage them as close as possible to their goals. Delegating a strategic business project to an IT department culturally remote from business, is a thing over the past. We often observe that Design departments, as they become key elements of business agility, split into several Business IT departments attached to the Business Unit itself. In parallel, infrastructure departments and all competence centers independent of a business skill (e.g. pure development) merge into a “Shared Service Centre” becoming internal operators, or even subsidiaries or external resources (see next paragraph).
This situation implicitly entails difficulty in maintaining transverse Change Management and Release Management processes. The more each business IT management gets close to its business, the more its methods become specific again and lose coherence (in return for proximity gained). Processes used to manage change and release operations also become different and the guarantees they bring become unequal. Except if there is a managerial commitment to maintain methods of uniformity.
The growing evolution of IT Service outsourcing
The heavy trend towards outsourcing of IT department operations considered as non critical, leads to the same conclusions as above.
Outsourcing impacts all functions without exception: operations (Service Desk, workstation management), engineering (networks, server and warehousing management), design (application development, ERP integration), application support (Third Party Application Maintenance). The introduction of “as a Service” (IaaS, WaaS, SaaS)* supply modes speeds up outsourcing of various IT Service contributions towards customers.
Again, as a direct result, the Change Management process fails to cover the whole change spectrum in a uniform way. This requires transparency and interfacing with suppliers, which is not obvious in many cases.
Then, even if customer and supplier processes are interconnected, the question of their compatibility is raised. Outsourcers generally use standard processes, compliant with ITIL framework recommendations. This means that the processes used are standardized for all their customers, but does not imply that they are compatible with their customers' processes. A maturity evaluation** (even a certification) does not guarantee the supply of the value level expected by the customer. The question is: is the customer ready to adapt to the supplier's standards?
IaaS : for Infrastructure As A Service, WaaS for Workplace As A Service, SaaS for Software As A Service.
** The big difficulty is to identify what a maturity level means in terms of actual value added. In practice today, neither ITIL maturity audits, nor ISO 20000 certifications guarantee the real uniformity of good practices and maturities reached. This is due to the fact that even if a process activities, rules and deliverables exist, their content and performance vary from one organization to another. This is a major problem for a company IT department to make promises to customers (through SLAs), and in parallel, to have to make sure that all internal as well as external contributors are aligned on these promises (OLAs and UCs). This point still becomes more critical when several suppliers contribute to the supply of the same IT Service, because aligning them together is still more delicate. That is why the author asks: Is the customer not the one who adapts most in this context ?
Figures A and B below show where outsourcing impacts IT Service supply
Figure A: reminder of the various elements, part of an IT Service
Figure B: shows IT Service supply scope that can be outsourced (dotted boxes), and that kept completely under internal IT management (on light blue background).
Any change made on a component requires coordination and alignment of methods and commitments of the various contributors, in order to maintain service levels. From the customer's point of view, any failure has an impact on IT Service.
Evolution of development methods
For the same reasons linked to the competitive context, IT organizations always look for new agility sources. In recent years, Design and Development activities have also moved towards “agile” approaches (referring to the Agile Manifesto): Scrum, Devops, etc…
Their common characteristic is their new way of considering change management:
► Searching for a higher iteration of development cycles to increase frequency of change on smaller scopes performed in parallel, and above all released quicker and quicker.
► Higher integration between development and operational teams (to merge into a single team), leading to more flexibility between roles, for greater reactivity on evolutions.
Direct consequences are:
► The notion of process slowly disappears with the separation of roles (between change initiators and those who control them).
► Search for reactivity and speed of execution as well as lack of separation of roles lead to a strong reduction in stages and control rules in order to shorten release times
► Unless stakeholders are fully aware of their responsibilities, freedom of access and action (facilitating agility) can turn out to encourage direct updates in live environments,.
► The same search for reactivity alleviates build constraints (architecture, technologies, development methods), for the benefit of greater creativity, but limits incitement to “re-use” and associated effort savings.
Illustration of differences in approaches between the industrial processes of the ITIL framework and Agile methods.
Warning about interpretation:
The author stresses that there is no point in opposing two approaches but rather in putting into perspective the undeniable benefits as well as the associated risks of each one. Agile methods are neither presented as immature or potentially dangerous. The author mainly stresses that stakeholders need to be mature and highly accountable, to avoid drifts. A standard few organizations are able to reach today.
Copyright © 2013 - PRACT Publishing
► No link
► Change & Release ...