Architecture management as a key competence within the framework of IT architecture

For many years, companies in almost every sector mainly viewed architecture management as a tool to standardize applications. Here, the main focus lay in the attempt to consolidate an application environment that had grown historically and heterogeneously as consistently as possible for few standard applications and thus develop efficiency potentials in the company. This approach proved successful: Despite the addition of new functional requirements, the large number of different application instances generally decreased and as a side effect operations – due to less complex interfaces – became more stable and secure.

In recent years – sooner or later, depending on the industry – we in turn see a countermovement. The desire for more flexibility and above all more agility pushes the aim for comprehensive consolidation slightly into the background. In many places the development of application architecture is shaped by the increasing integration of smaller purchased application instances, third party services as well as more and more in-house development. This development is driven in part by bi-modal approaches that consciously allow “speedboats” that frequently do not have to fit the existing “supertanker”. The idea behind this is that of, as an example, 100 “speedboats” set out to sea only a small number will return to the harbor anyway and it would therefore be a waste of time and money to align every initiative in advance with the major “supertanker” solution. A further driver is the interoperability with third parties, for example manufacturers and providers of SaaS solutions as well as business partners whose services need to be integrated. The result is a system landscape that may be more flexible and agile, but at the same time is less heterogeneous and more complex to operate.

So how can we ensure that we are not – as happened in the 80s and 90s – creating tomorrow’s problems today and how can we prevent today’s architecture development and IT architecture from being the foundation for multi-million consolidation projects a few years from now?

As always in life, reasonable and goal-oriented planning is key, even in times of flexibility and agility. The first important step is to gain an up-to-date overview of the system architecture. This should be a matter of course, but is not applied in practice everywhere. The following indicators at least offer clues to whether the current architecture development is structured or chaotic:

  • Interconnection: What is the average cohesion of the application environment in relation to functionality? If the interconnection is high, it increases complexity and bears the risk of circular references. The loose coupling design paradigm should be used as consistently as possible.
  • Hierarchy: Is four-tiered architecture used extensively? If necessary, a lack in stringency of a layered approach can be compensated by introducing an Enterprise Bus. However, this is more of a stopgap.
  • Modularization: Is there a recognizable modularization? If modularization is too fine-grained, this leads to an increased number of interfaces that in in turn need to be maintained and can result in a weaker performance.
  • Penetration of “late binding”: „Late bindings “ increase flexibility. Generally, the amount of necessary bindings should be decreased by optimizing module groupings.
  • Customizability: This means adaptability without working on the source code directly. Key users on the technical side can carry out adjustments quickly and flexibly using customizing options.
  • Integrated development environments: Do automated deployment and test infrastructures for business critical applications exist? That’s the only way DevOps will work.
  • Web-Standards: How high is the share of components with web standards, for example http? In new developments the focus needs to be on the implementation of web standards and the use of sustainable technologies.

Further indicators, such as incident behavior, cycle time of changes, the share of systems with a single point of failure etc. can sharpen the image and identify needs for action.

The main requirement for good architecture – whether in construction or IT – is clean and systematic planning by a competent architect. This is easier said than done (lack of specialists hits this profession particularly hard), but it’s worth it!