Taming the IT systems complexity hydra

ing away complexity with formalization, models and tools In order to provide these different levels of abstraction, and the expression of contracts at module boundaries, appropriate models of the systems have to be relied upon to cope with complexity. There is a dire need for formalized semantics to facilitate better analysis of the system and its properties, and the derivation of formal proofs for (at least some of) them. It is currently, however, near impossible, or at least prohibitively expensive, to mathematically formalize and completely prove large IT systems: they are too complex. However, we do know how to reason about functional correctness of programs and some smaller parts, modules, can be formalized and proven. This partial verification is currently the norm, to provide levels of assurance, mastering part of the complexity. A lot of hardware has no formalized semantics. The hardware models for software development are thus inaccurately specified. So, it is difficult to formally ensure correctness: verified software would even in a way be built on (shifting) sands... Fortunately, this is changing. ISAs (instruction set architectures) are being (more) formally specified [3], and include ARM [10,11], RISC-V [12,13]. Software systems too will increasingly rely on formal methods. This is already happening; for example, the Isabelle proof assistant [14] is commonly used in the writing of seL4 OS [15], while Coq [21] is for the formal verification of the Compcert compiler [22]. Executable specificaTAMING THE IT SYSTEMS COMPLEXITY HYDRA

• IT complexity is threatening the quality and control of crucial systems that can affect the lives of many businesses and people in the EU.
• Taming IT complexity is vital for quality (safety, security, performance, sustainability, trustability, resilience) and cost (time to market and maintenance), hence competitiveness of EU industry.
• There is no silver bullet against complexity, not even AI.
• Modularity is key to mastering complexity.Modularity demands components, containers, contracts, specifications, services and orchestration.
• Formal methods, models, can harness (part of) IT systems complexity.
• The EU, like the rest of the world, is in dire need of educated, highly skilled IT specialists.

Key recommendations
• The EU should support efforts to tame IT complexity, for the sake of quality (safety, security, performance, sustainability, trustability, resilience) and cost (time to market and maintenance), hence competitiveness of EU IT industry.
• The EU should promote research on methods and tools on modularity, components, containers, contracts, specifications, services and orchestration.
• The EU should promote research on formal methods and tools for modelling IT systems and their functional properties (what they do, the algorithms) as well as their non-functional properties (how they do it: time, energy, security...).
• The EU should train more highly skilled IT specialists.
The complexity of IT systems, on both the hardware and the software side, keeps growing exponentially and creates an everbigger challenge.It is already the case that some systems can be considered as no longer completely understandable, hence no longer mastered, not only by their users but above all by their designers, developers and maintainers.This state of affairs cannot go on, so it is crucial for the EU that complexity be mastered, for users, by its IT system providers, in all its dimensions.This article provides an overview of the many sources of complexity that make it similar to the mythological hydra, and presents solutions we deem important to cut off its ugly heads and/or tame this beast.

IT system users don't like complexity: developers must hide it
From the user point of view, complexity has to be hidden so as to provide an easy, pleasant user experience.IT systems have very much improved and even done well to hide the nitty gritty details for basic levels of use but the complexity for users tends to move to higher levels of use.Users increasingly want to have access to multiple functions and services, from various providers, spread all across the world, and all of this at the same time, possibly on multiple and varied terminals (from smart watches to desktops, via smartphones and tablets), presented to them in a simple and convenient way.
Multiple installed applications go against simplicity.Users need as-a-service meta-applications, that is to say, aggregators of multiple applications, to save them from the connection and coordination issues associated with accessing the various applications.In addition, these aggregators cannot just present users with a juxtaposed view of the various application results: they must be smart integrators that process and manage the complexity of the various results and present them in a more synthetic, and easier to understand way.Good examples of such meta-applications, which currently tend to be domain-specific, are price aggregators and comparators (for travel, hotels, etc.), and virtual personal assistant capabilities like Alexa Skills.models.Hybrid platforms are also emerging.Heterogeneity is thus probably more prevalent than was generally expected.As a consequence, the hardware environment is evolving extremely rapidly, even faster than in the era of Moore's law.This increasing hardware complexity is now an emerging crisis.The (incomplete) documentation amounts to 9000 pages, with a table of contents of 100 pages, is written in informal English and periodically amended by errata.This, for many chips, every few weeks [3].How can humans cope with such a diluvial amount of information?Is this huge engineering effort worth it?Since hardware has no formalized semantics, how can we ensure it is correct?Is verified software built on the shifting sands of possibly incorrect hardware?Bugs occur, safety or security breaches too, making attacks by various aggressors easier.
IT systems are full of complexity: the sources are varied For IT system developers, complexity springs up in all corners of IT systems development, for both hardware and software, and its various aspects call for different kinds of solutions.This section presents an overview of the root sources of IT complexity that we deem important.
In hardware, since Dennard scaling has stopped, processor systems have become tightly-interconnected multi-cores (exposing parallelism with and without concurrency), fitting in an increasing number of accelerators (exposing heterogeneity), aggregated in variably deployable units (exposing statelessness) and networked (exposing geographical distribution and decentralization), for ease of access via the web (exposing asynchrony).Fieldprogrammable gate arrays (FPGAs) are based on radically different programming This explosion of complexity is matched in software, which contains many sources of complexity at all levels of the software stack.
The system development ecosystem is an immense maze consisting of scores of methodologies and their derived tools (Figure 1).Programming languages alone are also a source of complexity (Figure 2).Historically, statically typed languages used to be the most popular ones.Then dynamic languages became popular (Ruby leading).Now languages are more mixed [4].As a result, today more than 8000 languages exist, from the generalist languages addressing a wide range of needs to more specialized, targeted languages, or even DSLs (domain specific languages) fully tailored to one specific domain of application.A large number of them are still in active, live use, creating a modern-era technological Tower of Babel: This multiplicity and heterogeneity of languages also creates huge complexity, in terms of their interaction and developers' ability to master them, etc.What are the tools available to manage this complexity when using different languages in the same codebase (e.g.how do you diff)?
At the same time, the various languages exist for a reason, while addressing different needs.A good illustration here are DSLs that help tackle the peculiarities of some application domains in better ways than general purpose languages, hence in a simpler way.
Software libraries provide off-the-shelf capabilities, or features, that developers like to reuse to build systems from existing parts rather than reinventing the wheel.Yet the library ecosystem is huge.Which library to choose when wanting to add a feature is a rather informal, ad-hoc process, and may be a complex one when faced with many alternatives.Library versions also have to be taken into account, because compatibility issues between versions of the various libraries create an intricate web of dependencies.
Application code itself can be quite complex, just because of the inherent complexity of the problems it solves.Admittedly, this kind of complexity seems more useful than certain other kinds, yet it has to be managed.Application code complexity can also come from the coding style and/or the language used.Terseness can sometimes lead to obfuscation, while some verbosity may help understanding, hence lower complexity (see Figure 3).A balance thus has to be found.
In addition, with the growing pervasiveness of the use of computer systems in virtually every aspect of our daily life, the production side of the IT community is faced with complexity factors that add to the classical functional complexity.These factors comprise non-functional properties such as energy, time and other resource constraints, ever-advanced human-computer interaction, the weaving of cyberspace into physical reality, as well as continuous delivery within continuous operation.All this results in many   [9] TAMING THE IT SYSTEMS COMPLEXITY HYDRA systems being composed of complex webs of dependencies that are easy to break and hard to maintain.Furthermore, there are still issues that have not been completely solved by the IT community.Among them, how do we measure and value software quality?Which non-functional properties or metrics have to be considered?How do we value non-functional properties like speed, low-energy, high-security?Another of the crucial and complex aspects in the IT ecosystem is the importance and variety of legacy.Legacy is the heritage of the past, composed of existing operating systems, libraries, languages, development tools and hardware.Legacy represents a huge amount of code, estimated in 2000 at over 100 billion lines of code, most of it COBOL [6,7].Legacy hinders the taking of new directions, yet it cannot just be done away with.Indeed, the service provided by large existing legacy systems must still be provided, so disrupting them is not an option.New languages and libraries must be able to interoperate with legacy ones.New software must often run on old hardware or old OSes, which multiplies the possibilities and tests to be done, the compatibility patches to write, for no other usage than having an IT system work in yet another particular context.Furthermore, in order to reduce cost and time to market, it is much better and very common to reuse existing elementseven code parts found in public repositories on the web -to extend or modify existing systems, than to start each development from scratch.Indeed, legacy code, despite all its drawbacks, still makes it possible to tackle problems without reinventing the wheel, by reusing old, tested and tried, libraries that have been very fine-tuned and well debugged over the years, thus removing a lot of the complexity of new developments.
The issue there is thus not so much the existence of legacy as its intrinsic quality and the complexity to integrate it into new developments.Tradeoffs are thus of the essence when reusing legacy code.
Overall, all these sources of complexity add up, as do the size of the elements composing the system: the bigger the system in terms of functionalities, the greater its complexity.Similarly, outside of the purely technical complexity, the greater a system, the greater the team needed to develop it, the greater the complexity of the development process and its management.

Impacts of complexity
The consequences of complexity in IT systems, coming from the above-mentioned sources, are very simple: high levels of complexity mean high costs, and high risks.High complexity brings high development costs, because of the size of the teams needed to develop the systems, and of the time needed to do so.It also incurs high risk of delays in the process, risk of poor quality in the system (risk of bugs leading to malfunctions), lack of speed, lack of safety and lack of security.The same applies of course for ongoing maintenance of complex existing IT systems, and for their evolution, with added difficulty that the original knowledge of the system designers and implementers is often gone.
In a nutshell, complexity must be tamed, in order to keep the IT system under control.
Fortunately, various solutions exist, or are within reach with reasonable efforts, to tackle the various heads of the complexity hydra.

Modularity does manage complexity, with additional benefits
Modularity at various levels is the main key found by humans to mastering complexity and to the reuse and integration of hardware or software legacy, especially across programming languages.The elements to (re)use have to be properly architected so as to be taken as whole modules, properly contained and encapsulated.On the software side this implies isolating the implementation inside the proper module (class, object, library, container…) and exposing only the right amount of interfaces at the boundaries of the module, to provide (micro-)services.Clear contracts must thus explicitly define the behaviour of the interfaces exposed at the boundaries, both inward and outward.Enhancing module/container interface specifications, so that they help assess semantic conformance at build, integra- It should take the form of enforceable contracts covering both functional (i.e. the algorithms) and non-functional (e.g.time, power and energy, security and safety, etc.) properties.
This kind of modularity would be especially apt to current IT systems, which are generally extremely connected and distributed over the web.It matches very well with the microservice paradigm, an enabler of modern, heterogeneous software composition.Indeed, an individual microservice is a small self-contained application that has a single responsibility (which gives it a clear and distinct role in a composition), a fully-self-contained and preferably lightweight stack (which allows its software dependencies to be always fully satisfied), and which can be deployed, scaled and tested independently (which facilitates software evolution) [1].The "microservices" architectural style yields a single application from the coordination of a suite of unitary services [2], each of which exposes an application programming interface (API) outside of their codebase, which is invoked using asynchronous (crucial to loose coupling) web-based service requests (key to reachability).Microservices can run isolated from others in containers, using hypervisors to segregate them.This provides more resilience in case of hacking, since contaminations should be blocked between containers.
Software applications and infrastructures will increasingly be aggregates of heterogeneous artefacts with a variety of deployment requirements.Controlling them can hardly be done in a merely declarative way or scattered in a maze of uncorrelated and independent scripts.Languages and tools for orchestrating collaborative distributed and decentralized components are thus needed.
In addition to helping integrate different (possibly legacy) elements, modularity is key to boosting the repairability of IT systems.Being able to replace a part (be it a software or a hardware one) with another when it is found to be faulty, or when it becomes obsolete, is a power-ful way to extend the lifespan of an IT system.Although this seems obvious, when thinking of e.g.automobile parts, this is a concept less developed for hardware in IT systems.Software parts are more often upgraded, with many OSes, libraries and applications having new versions released with patches and/or improvements, thanks to these updates being mostly automated, hence very easy, on the user side.
By repairing hardware parts or modules, IT system lifespan can be increased, thus decreasing their global ecological footprint both in terms of raw resources and carbon impact.
By patching/upgrading software, IT system quality can continuously be improved, thus avoiding the costs and inconvenience of faulty behaviour, especially with respect to safety and/or security.
Modularity is also key to more easily developing new IT systems, allowing reuse of hardware or software modules and making it possible to create whole new product lines with limited effort.A well-known example is printer product lines, which clearly rely on modularity and componentization to produce a large variety of similar but not identical products to tackle a variety of consumer needs, thanks to a limited set of common subparts.There, modularity clearly decreases financial expenditure and time to market, which provides several competitive advantages.
Like for reusability of (legacy) elements, modularity for repairability requires clear interface contracts, specifications, at module boundaries, since the mechanisms are the same.Again, these contracts and specifications must take into account the non-functional properties as well, so as to carry enough information to ensure the proper composability of the modules, especially in the long term, with various evolutions of the system, hence evolutions of the other surrounding modules.These contracts must also be easy for developers to master and to deal with, especially when taking into account the shortage of skilled IT professionals in the EU.At the same time, these contracts must be amenable to formal verification and/or proofs.
Carrying enough information, while at the same time providing a good level of abstraction to hide away the details and not go in the way of composition, is an issue that must be tackled.It implies being able to have different levels of abstraction in the models and the tools, so as to be able to zoom in or out, depending on the level of details needed at the level of composition considered.These levels allow different views, with more or less information being provided, while keeping the underlying information complete, with no loss.

Abstracting away complexity with formalization, models and tools
In order to provide these different levels of abstraction, and the expression of contracts at module boundaries, appropriate models of the systems have to be relied upon to cope with complexity.
There is a dire need for formalized semantics to facilitate better analysis of the system and its properties, and the derivation of formal proofs for (at least some of) them.It is currently, however, near impossible, or at least prohibitively expensive, to mathematically formalize and completely prove large IT systems: they are too complex.However, we do know how to reason about functional correctness of programs and some smaller parts, modules, can be formalized and proven.This partial verification is currently the norm, to provide levels of assurance, mastering part of the complexity.
A lot of hardware has no formalized semantics.The hardware models for software development are thus inaccurately specified.So, it is difficult to formally ensure correctness: verified software would even in a way be built on (shifting) sands… Fortunately, this is changing.ISAs (instruction set architectures) are being (more) formally specified [3], and include ARM [10,11], RISC-V [12,13].
Software systems too will increasingly rely on formal methods.This is already happening; for example, the Isabelle proof assistant [14] is commonly used in the writing of seL4 OS [15], while Coq [21] is for the formal verification of the Compcert compiler [22].Executable specifica-TAMING THE IT SYSTEMS COMPLEXITY HYDRA tions put in the code (i.e.contracts) should also be increased, proving both a means to document the intent of the code, its specification, and to help its verification by automated tools.In addition, these specifications should provide information not only about the program functional aspects (what it does, the algorithms and functions), but also about what is currently called its non-functional properties (how it does it), like time and reactivity, power and energy, safety, security, etc.There lies a real current challenge: programmers and support tools should be able to express, manipulate, and reason about these nonfunctional properties, to yield static proofs of functional as well as non-functional correctness, to make runtime decisions, to support runtime assertions to check that the necessary properties hold during execution, and that they have adequate semantics to handle violations so that safety conditions are restored.
Efforts along these lines already exist and must be supported.It is necessary at the same time to also pursue less formal but more practical efforts aiming to improve the quality of the developed system elements and modules, in a very concrete and practical way, helping developers cope with some parts of the complex-ity.The MDE (model driven engineering) methodology [16], including the wellknown UML (unified modeling language) [17] adopted by the OMG (object management group) computer industry standards consortium [18], and the related modeling tools (e.g. the Eclipse Papyrus Modeling Environment [19]), have been for a long time making progress in that direction and should be supported.
However, the advance of formal methods in IT systems has been hindered by past and current market realities.Indeed, business constraints (time to market, cost of production) and the programmers' mindset have generally focused on delivering functionalities to customers, since this is what sells.Integral correctness is rarely pursued by design; more often it is sought as a product of quality assurance activities, either performed retrospectively or in parallel to development, but not sufficiently ingrained in it.While some enterprises do specialize in providing tools that help the quest for correctness, their success has never even remotely approached that of organizations providing functionalities to the end user, such as the likes of Facebook or Twitter.Still, the potentially negative impact of this situation is huge, for loss of value, increase of risk, and spread of threats, and should be acted upon with a more vigorous quest for quality.The fact that some very famous IT companies provide end-user licence agreements that, in essence, remove any responsibility on their part should the product not work, means that the cost of such failures falls to the customer rather than to the provider, which is a very uncommon practice in other business domains.Regulations against this could strongly help the quest for quality, by putting a higher price on the damage caused by poor quality IT systems.Mandating liability for IT systems should thus be a priority for the EU to boost the quality of its IT systems.
Coping with complexity of formal methods may be an issue for developers/designers, but it will be a simpler one to solve than directly managing the full complexity of hardware and software.With tools getting easier to use, good programmers should have no problem mastering formal tools.

To tame the hydra, you need tamers: the role of IT education
Mastering all this complexity indeed requires many highly skilled IT specialists.
Educated designers use proper design methods and tools, producing high qual-ity architecture and modular systems.Educated programmers program well and produce good implementations, even with poor languages.It is a fallacy to believe that to build significant IT systems, uneducated programmers can simply use tools in a kind of copy-paste way, not fully understanding what they are doing and what are the fundamental underlying concepts, and yet still produce good quality systems.Learning and mastering the fundamental concepts is key to good decision making in IT system production.

"Controlling complexity is the essence of computer programming. " [5]
Brian Kernighan At the same time, it is necessary to have tools that can present the proper level of abstraction, hiding the details when they are not needed.Easy programmability is thus a must-have goal.Tools must improve.Graphical programming was an interesting track to ease programming and bring it to the masses to some extent, with visual programming languages [20].However, so far, graphical programming is still not scalable, strongly limiting its usefulness in commercial application building.The UML modelling language, with its graphical representation, goes to some extent in the graphical programming direction (but certainly not for the masses), and has made it possible for professional IT systems developers and designers to better represent the systems, hence to master complexity in a better, yet still incomplete and imperfect, way.
Machine learning can also be seen as an interesting track to help in IT system production.It has the capacity to learn heuristics, hard-coded control loops, policies, and help implement them in an automated or semi-automated way, thus saving significant amounts of time.It could also help with some architectural choices, based on the specifications.However, we should not think machine learning will write all of our programs for us anytime soon.All the hard, system-wide problems will remain: security, correctness, reliability, availability.In addition, although AI or its currently fashionable incarnation, deep learning, could help take away some of the complex-ity of programming IT systems (chopping off one head of the complexity hydra) by for example writing automatically some parts of programs (e.g.[23]), the use of machine learning could make it much more difficult to analyze the correctness, hence the safety and security, of IT systems, thus increasing the complexity of these stages (thus growing news heads for the complexity hydra)...So all these problems will have to continue to be addressed mainly by skilled human IT specialists.
Unfortunately, the latter are in scarce supply in the EU, with numbers being insufficient to fulfil the needs of our economy; this greatly hinders EU innovation and competitiveness.The need for a sizeable community of educated professionals capable of developing IT systems and who understand the fundamental concepts that underpin IT systems, must be addressed.

Conclusion
The complexity of IT systems is a monstrous hydra that cannot be left unattended.To tame it, and therefore ensure the good quality of the EU's IT systems, as well as the competitive advantage of its IT systems providers, there is no silver bullet.On the contrary: the answer is multifaceted, as much as complexity is multifaceted.Concretely, the EU must steer the way we design, develop and maintain these systems in more modular ways, using the practical power of containers, encapsulation, contracts, microservices and orchestration, as well as the formal power of verification, proofs, and correctness checking methodologies and tools, and explore how new technologies such as artificial intelligence can help.The EU must also have a large workforce of people skilled in IT systems, to tackle the challenges of today and those of tomorrow.

Figure 1 :
Figure 1: A sample of the developer's technology landscape in 2014.Things have not improved since.Source: DevNetworks Sought enhancements: asserting correctness.

Figure 3 :
Figure 3: Complexity is not only depending of the size of the code, this example shows a complete program.How it works was explained in a book of 170 pages.Can you guess what it is doing?[9]