Application of agile approaches has now become standard. Iterative development of program systems and agile project management are the order of the day. Agile development methods are just as widely accepted as traditional methods, such as the waterfall model.
Significant tension is opening up for IT organizations in this connection: they risk being torn apart in the tension between the management of their highly standardized legacy IT, the introduction of agile solutions and high pressure of expectation from users and end customers.
Highly optimized enterprise IT / legacy IT
As central service providers, many IT organizations are largely aligned with cost optimization and efficiency and with the provision of a stable, secure service.
- Areas that do not belong to the core competence are bought in in the form of outsourcing or nearshoring/offshoring. Heavy pressure on standardization, transparent product catalogs, stringent requirements management and generally a rather reactive approach as an overall organization go along with this.
- The core systems (“legacy IT”) are often extremely complex with many facets to support key business processes and communication with their environment via a multitude of different interfaces. Usually they have been developed on the basis of waterfall models. Not least because of the complexity of cross-system feature developments, the legacy systems follow defined release cycles which allow coordinated deployment.
Agile individual solutions, disruptive developments
For the development of new, individual, defined systems, many IT organizations have introduced agile procedures – in line with the mainstream – and have had their first experience of their application.
- These systems usually represent flexibly changeable, end-customer-related functions, are usually insular solutions and follow their own rules, requirement pathways and release times. They are clearly delimited with just a few interfaces.
- The agile solutions constitute a world in themselves with their own tool chains, specifically aligned quality management, separate interactions with users with different role models. Product owners, backlog, CI/CD (continuous integration/continuous deployment), DevOps, tribes and squads are just a few of the associated organizational and technical elements.
- From an overall IT perspective, they are mainly “propped up” on the highly integrated systems and contrast the previous standardized processes.
High expectations
This service structure is often confronted by diametrically opposed expectations and requirements of internal departments and external challenges:
- departments want IT to act as an innovation partner. They expect proactive, flexible action and agility and high speed in the introduction of marketable solutions. Technically, this usually means cloud-based provision of functions.
- Factors from the world outside the company act as additional drivers: changes in market and customer behavior, the need for rapid responses to external forces (e.g. Covid-19) and the resulting new, partly disruptive business models. The pressure of increasing digitization and new technological trends is another factor.
- Declarations of faith and value judgements such as “agile is good”, “waterfall is out”, “you’ve only got things right if you are agile” act as additional pressure points.
Resulting tension
One of the main challenges is permanent functional provision of the systems from a general perspective, i.e. coordination of functional and usable releases and their functionality from an end-to-end perspective, including integrated service management from an end-customer viewpoint.
In the areas of service management and service delivery in particular, agile setups and principles are diametrically opposed to the requirements of the legacy IT. The introduction of overarching functions (i.e. those that bring legacy and agile under one umbrella) is extremely complex:
What works in which system at what point? What functional conditions must be considered, what interdependencies exist? What can be tested and when? What can be deployed and when? What (characteristics of) features fit together? What is already in place, what is (still) deactivated? How do the releases for the legacy IT and their timings fit with the continuous integration/continuous deployment pipelines of the agile world? What can be put into production when? Which system chains or stages are required in what form? What happens if there are problems, how does (L1/L2/L3) error analysis work, what about rectification of errors and integration of resulting corrections? How do service management and interaction with relevant users and customers work? Who takes care of what?
As long as just a few systems are affected, the situation remains manageable. However, the complexity increases rapidly the more (agile) systems and interfaces that are in play.
If the above questions are not resolved adequately, the areas of tension mutate into a powder keg and the question is: when will IT blow itself apart?
If it is not possible to meet these expectations adequately, users try to organize their own solutions. As a result, decentralized (shadow) IT units often emerge in departments, frequently with unclear IT governance.
And yet their procurements and implementations – which are often uncoordinated and incompatible with company standards – have to be integrated into the enterprise IT at the end of the day – with a lot of work from the point of view of the enterprise IT and with trade-offs and a loss of flexibility from the point of view of the decentralized IT.
A lose-lose situation.
Failure is not an option – so what can be done?
Many IT organizations are either aware that they will soon be confronted with this complex set of tensions or are already in the midst of them and sooner or later they will need reliable answers about how to deal with them and strike an appropriate balance.
There is a multitude of options and approaches for solving the challenge described above. What is clear is that the starting situation is different in every company and various requirements have to be met.
An analysis of the individual situation is therefore the starting point for effective steps towards a solution which deals with specific requirements and allows implementation of the optimal design. This usually consists of a mixture of adaptations of organizations and processes, plenty of architectural work, clear definition of key processes such as system development, service management and project management, intensive planning and close integration of and interaction with departments, and can even go as far as the development of a two-speed IT with clear governance and corresponding management commitment.
ResultONE has answers and model solutions and can help you to overcome your specific challenges – get in touch with us today!