"Der Tausch von digitalen Lösungen (Services, Fähigkeiten) ist der Handel des 21. Jahrhunderts; Plattformen sind die Boote der Eroberer"; Markus Warg, CIO.de
Agile software development: yes please!
Traditional (legacy) software development is often characterized by the fact that all requirements for the applications to be developed are collected and considered before the software development starts. These so-called Big Up Front architecture approaches follow the idea that only when all requirements are understood, the best designs, architectures and code can emerge.
The last decades have shown that Big Up Front architecture approaches do not prove themselves. In the time it takes to fully understand the requirements, the customer and market requirements often change so that the elaborated Big Up Front approach to architecture and design no longer fits the customer expectations.
Agile software development is a generic term for the methods (e.g. Scrum, Kanban), with which the software development is to take place faster, more flexibly and more user-oriented. What all agile methods have in common is that they rely on small, self-organizing teams that interact closely with customers and deliver interim results quickly. The "Agile Manifesto" describes the principles of agile software development.
Why is "agile software development" alone not enough?
Agile software development trusts that even the best architectures are created by self-organized teams ("Agile Manifesto"). This may be true with respect to the solution architecture of the specific "feature", but it does not take into account overarching requirements for the (enterprise) architecture, such as with respect to the "user experience" or the interaction of applications.
Platform-based approaches as an opportunity
Service platforms connect actors and enable the integration and bundling of resources (data, knowledge, services, products, skills...) whose application (interaction) generates benefits (e.g. value in use).
If these service platforms have a suitable architecture in the sense of a construction plan, then the advantages of agile software development and a holistically thought-out architecture (the construction plan) can be brought together.
The SDA - Service Dominant Architecture - is such a construction plan. This plan is already considered in the creation of the solution building blocks (software stacks) and the platform. This ensures that the building blocks (like a house or a bicycle) work together.
Little Up Front platform approaches
Each use case and solution building block is given the architecture necessary for the solution to interoperate with the service platform and other solutions.
Up Front Platform Approaches
If it is already clear that the service platform is to be used for a large number of use cases, then it makes sense to start with the platform and then develop it further with each use case and solution module.
SDA as Enterprise Architecture
Enterprise architectures serve as organizational logic for business processes and IT. It forms the design pattern and enables the individual results to fit together as in building a house.
McKinsey visualizes two approaches to aligning teams (e.g., development teams) with the enterprise architecture as shown below.
It is crucial that firstly there is an enterprise architecture and secondly that all teams are aligned to it and that their deliverables are aligned to it. An example of an enterprise architecture is the Service Dominant Architecture.
According to this approach, IfSD.Hamburg supports the understanding of McKinsey (see Buckow et al.) that a "revolution" in architecture management is needed to ensure the alignment of IT with business requirements.
