Many organizations suffer from a complex application landscape, which has a significant impact on the ability to control IT costs and to quickly respond to changing business needs. Hence, understanding how the complexity of your application landscape can be reduced is often a very good starting point if you are looking to optimize IT costs and increase business agility.
The X factor
Many of today’s IT organizations share the same problems, which have negative effects on both the IT organization itself as well as on the business that it supports. One of the most common and important issues is that the yearly costs for maintaining IT assets, e.g. applications and infrastructure, is too high in relation to the amount of money spent on strategic development. Most companies want to decrease both the absolute and relative cost for maintenance, in order to free up financial and human resources for development, as this often adds more value to the business, at least from a strategic and competitive perspective.
Additionally, many companies express a concern regarding expensive, time-consuming and sometimes risky changes in the IT environment. There is often a lack of a good understanding of the complete application landscape and how changes in applications, information and integrations affect eachother. This leads to difficulties in isolating changes, i.e. changing one thing can cause problems that are difficult to foresee. The result can be longer time-to-market for products or services, which can be devastating for the company.
From a business perspective, the problems often have a different nature. It is not uncommon to hear complaints such as “we have to use so many different applications to do our daily work”, “it’s too difficult to get reliable, comprehensive and understandable information from our systems” or “why does it take so long time to implement changes in our IT systems”. These kinds of statements are often proofs of weaknesses in IT landscape, which eventually will lead to decreased business value achieved from of the IT services.
This type of IT related problems are very common and exist in many organizations that rely on IT to run its core business. What if these problems are all symptoms of one common factor? Eliminating this factor would help solving the problems described above, which would result in reduced waste of money and time, and improved business value.
Acando’s standpoint is that this factor does exist, i.e. there is one common root-cause leading to many, and often significant, problems for both the IT organization and the business. The factor is a complex application landscape.
Complexity in your application landscape has many aspects
Complexity is never advantageous, in any situation, and should always be fought. This is especially true when it comes to your application landscape. If you think about it, a simple, well-defined and easy to understand application landscape would not cause the typical problems described above, or at least greatly reduce them. Simplicity, as opposed to complexity, is always beneficial and should be a key goal of any application landscape. Hence, it is important to understand what makes an application landscape complex, so that we know how it can be simplified.
Definitions of complexity in general terms typically states that complexity of a certain system is determined by…
…the number of entities in the system
…the degree of relationships between the entities
…the degree of uniformity among the entities
Entities in a system could be employees in a company, stations in a subway network, transistors in a CPU etc. In our case, this definition means that complexity is to a large extent determined by the number of applications, how many integrations there are between these applications, and how similar the applications are in terms of technical platform, programming language, user interface, etc.
Historically, many companies have focused on implementing new applications to support new business needs. Extending the functionality of existing applications has often been the second option whereas retiring applications has been even more uncommon. Projects named “Implement new system X” have been, and still are, much more common than projects named “Retire old system Y”. The result of this behavior is sometimes a very large number of applications (more than 1000 in some organizations).
The most powerful method to simplify the landscape is to reduce the number of applications. It is not only the most effective method, but it is also often possible to use. In many organizations there is a huge potential to decrease the application density. One way of achieving this is to consolidate applications. Consolidation can be done from different perspectives, for example across geographies, across processes, by functionality, or a combination of these. The best choice depends solely on the present situation and what drives the consolidation.
Retiring applications is a result from consolidation efforts but can also be a separate strategy on its own. The actual need for a certain application can fade out, partly or completely, due business or technology changes. Although the need for the application is very limited or non-existing it is still deployed and consumes human and infrastructure resources. Another driver for retiring an application is that the value it delivers is too small in relation to the costs associated with it.
In large organizations it is common to see many instances of a specific application. This problem is typically related to geography, where it is believed that factors such as performance, user interface language and local flexibility of functionality requires separate instances of the application. For example, each sales company within a global organization might have a local instance of the global CRM application to maximize response times and make it possible to have user interfaces in the local language.
Multiplication of instances makes it more time-consuming and difficult to maintain and manage the application. Based on similar experiences from different companies, however, it is often possible to overcome these types of problems in a single-instance environment using modern technologies and an adapted system architecture. In these cases it is therefore beneficial to consolidate instances.
With an increased number of applications you also typically need an increased number of application integrations. The integrations need to be developed, maintained and supported, which consumes resources and costs. If not done correctly, application integrations are also often the source for information related errors. Going back to the generic definition of complexity, we know that reducing the number of relationships between entities will simplify a system. In other words, architecture decisions resulting in less application integrations will result in a less complex application landscape. Eliminating point-to-point integrations as far as possible by establishing a common integration platform is very important in order to control and limit the effects caused by a complex integration landscape.
Another effective strategy to reduce complexity in any generic system is to isolate entities from eachother. Translated to an application landscape, isolating applications means that they should be made as autonomous as possible, i.e. an application can function on its own without depending on other applications. This can be very difficult to achieve since applications are often dependent on information from other applications. However, smart architecture decisions can increase the level of autonomy.
Using many different application platforms and technologies also tend to accelerate complexity. Landscapes built on both legacy and modern technologies are generally more difficult to maintain and develop, for example when it comes to integration and user experience. Consolidation of technologies and platforms is a proven way of reducing overall complexity in your application landscape. By developing and deploying applications on the same set of technologies and platforms, they become easier to develop, maintain, support and use, since it will require competence in fewer areas, a more common look-and-feel, less platform licenses, application integration is generally simplified among other benefits.
A slightly different perspective, but possibly equally effective, is to simplify the application itself. Too many applications are developed to meet functional requirements that are no longer necessary, or might never have been. Analyzing the current usage of the most central and frequently used applications in detail can be a quick and very effective starting point of the simplification process. A simplified application will reduce waste of time for both the end-user and the IT organization.
The increased availability and adoption of Software-as-a-Service and cloud computing solutions can both aggrevate and reduce complexity. These relatively new application delivery methods have made it much easier for any person or group of persons within the company to start using a new application without involving the IT organization. In addition to increasing the number of applications in the landscape, if such an application is adopted by a larger part of the business, the IT organization will eventually need to support it, integrate it etc. On the other hand, actively migrating a set of applications to a cloud environment in a structured way can help to greatly simplify the in-house application landscape, or at least move the problems caused by complexity outside of the organization.
As seen, there are several different factors that contribute to complexity of the application landscape. Therefore, to reduce the complexity it is these factors that one must focus on.
Invest in EA and PPM
Two well-known disciplines can be used to effectively tackle the factors causing complexity: Enterprise Architecture (EA) and Project Portfolio Management (PPM).
Understanding the complete application landscape, its strengths and weaknesses, and how it supports the business becomes crucial in order to effectively control and reduce complexity. The solution to this challenging task is spelled EA. The main purpose of EA is to optimize process, organization, information and application structures and relationships to support desired business changes. Hence, it becomes clear that an effective EA function is very important, or sometimes even necessary, to optimize the application landscape and fight complexity.
EA can help transforming a complex landscape into a less complex landscape, but equally important, EA also holds methods and tools to prevent falling back to the original situation. If EA is not implemented correctly, there is a very high risk that continuous changes will result in a gradually increased complexity over time. The key part of the solution to this is EA Governance. EA Governance ensures that changes to the application landscape are sound, by validating each change against the target architecture blueprint and EA policies and standards.
Consequently, it is clear that having good knowledge about all new and on-going projects is a prerequisite to make EA effective. This is where PPM comes into play. The main purposes of PPM are to ensure that the organization “does the right things”, i.e. good projects are prioritized over bad projects, and that “things are done in the right way”, i.e. the selected projects are executed efficiently.
By making the PPM function collaborate and exchange information with EA, significant synergy effects can be realized. PPM can support EA with key information about project proposals and the progress of on-going projects, which EA can use to quickly identify project decisions that are not aligned with the EA plan as well as projects that need additional EA support or review. Another benefit achieved by integrating EA with PPM is that the portfolio of EA transformation projects can be optimized using PPM, which will speed up implementation and reduce overall risks. Further, making the EA policies and standards part of the project prioritization process is a powerful way of reducing and preventing application landscape complexity.