In a recent conversation with Christoph Witte from JavaSpektrum, I shared my thoughts on the current state of enterprise architecture (EA) and its role in product-oriented IT. You won’t be surprised to know that I believe EA is integral in this process, but as I explain in this interview, it must also continue evolving in order to differentiate digital services and unlock competitive advantages in crowded markets. And for EAs throughout industries, the shift to a product organization means communicating more effectively with architects, developers, and business.
Others I’ve spoken to recently, including E.ON’s Head of Global Technology Architecture, Markus Rink, share my opinion. After his company acquired the renewable energy division of RWE, E.ON’s biggest rival in the German energy market, Rink gained considerable first-hand experience in using modern EA principles to optimize IT landscapes for digital excellence. His efforts positively impacted architectural domains ranging from technology and security, application and data, to experience and product — and, it is worth noting, with an efficiency that can only be attributed to what I call “actionable EA.”
Before reading my interview with JavaSpektrum (an excerpt of which I’ve shared in both German and English below), I invite you to read E.ON’s story for background. If there’s anything you’d like to discuss me with in person, please reach out at @christ_andre or at linkedin.com/in/andrechrist.
Christoph Witte: Aren't the features you just described, such as monitoring, cost control, and repository, more part of the traditional toolbox of enterprise architecture management (EAM) and the watchdog function that many IT and business professionals have come to value in the eyes of enterprise architects?
André Christ: In the context of COVID-19, this is partly true. However, the last area, the transparency of applications for all employees via a portal, already clearly points to the more modern role of EAM. This is more about active support and collaboration with IT and the business side. We see this especially with customers who are currently working on cloud transformations or other large projects such as the switch to SAP S4/HANA. It's not primarily about controlling and governance, but rather about connecting departments across the board or about ensuring that business departments understand the transformation roadmap and can provide feedback on it. With a restrictive enterprise architecture, such projects can no longer be managed at all.
CW: Do the majority of the architecture departments still act as watchdogs over the portfolio or have they already changed their position?
AC: I can only speak from the experience we have had with our customers working with our collaborative product. On average, 50 active users per month work with our tool in the client companies. If you now consider that there are usually two to three architects per company, it becomes very clear that these companies also work very collaboratively with other departments. For those who develop a lot themselves, business engineers, software developers and project managers use our tool in addition to the architects. For those who rely more on standard software, we find IT controllers, buyers, process analysts, for example.
CW: Does the enterprise architecture continue to differentiate itself and does this differentiation help in leaving the classic role of the guardian?
AC: Differentiation based on the needs of the company will certainly help. However, the extent to which the function is broken down strongly depends on the level of maturity of the architecture and on the task at hand. I recently had a conversation with a chief architect (Markus Rink, Head of Global Technology Architecture at E.ON) whose company currently has to deal with a very large merger. He sees differentiation in technology- & security architecture, in business-, application- and data-architecture as well as in experience- & product-architecture.
CW: Are there any other developments that contribute to a more modern interpretation of the EA role?
AC: The change from a project to a product organization. In the first, at the beginning of a large project, a target architecture is defined that is to last for several years. After that, development takes place and architecture and development have little to discuss with each other. This is different with the product approach. You start with a minimal viable product, which is further developed in terms of design and functionality, but also in terms of architecture. The reason for this is that a pilot product is only used by a few people, whereas a mass product aims at many users and therefore needs a completely different architecture. In other words, in a product organization you have to exchange ideas much more often. The dialog between architecture, development and the business side is necessary because otherwise the product cannot function. (See here for a recent blog article about the shift to a product-centric IT).
CW: Let's talk about cloud. More and more services are being developed cloud native or "serverless", often on the platform of a hyperscaler. Does architecture management still play a role at all in such scenarios? Do these user companies, which work very closely with a cloud provider and use its Platform-as-a-Service, still consider architecture management at all?
AC: Architecture remains important on the one hand because many companies are pursuing a multi-cloud strategy, and on the other hand because clouds rarely exist in their pure form, but mostly use hybrid approaches, i.e. only a part of the workloads resides in the cloud and other parts remain on-premises. Architecture plays an important role here, just think of security and authentication or data management.
Our analyses show that only 26 percent of business applications are in the cloud. And architecture plays a central role in this transformation. Questions about the selection of cloud services or questions about the transformation of the application itself must be answered. It rarely makes sense to simply lift and shift an on-prem application to a virtual instance in the cloud. Therefore: The architecture will not disappear, but the architects must adapt significantly. Without an understanding of what various cloud architectures offer, enterprise architects will no longer be able to provide sufficient support for their companies.
Christoph Witte: Gehören die Funktionen, die Sie gerade beschrieben haben, wie Monitoring, Kostenkontrolle und Repository, nicht eher zum traditionellen Werkzeugkasten von EAM und der Wächterfunktion, die Enterprise-Architekten in den Augen vieler IT- und Business-Mitarbeiter ausgezeichnet haben?
André Christ: Auf den Kontext Covid-19 trifft das teilweise zu. Allerdings weist der letzte Bereich, das Bereitstellen von Applikationen für alle Mitarbeitenden, schon deutlich auf die modernere Rolle von Enterprise Architecture Management (EAM) hin. Da geht es eher um aktive Begleitung und Collaboration mit der IT und der Fachseite. Das sehen wir vor allem bei Kunden, die sich zurzeit mit Cloud-Transformationen beschäftigen oder mit anderen großen Projekten wie dem Umstieg auf SAP HANA. Da geht es nicht in erster Linie um Controlling und Governance, sondern darum, Abteilungen übergreifend miteinander zu verbinden oder darum, dass Fachabteilungen die Transformations-Roadmap verstehen und auch Feedback dazu geben können. Mit einer restriktiven Enterprise Architecture kann man solche Projekte gar nicht mehr bewältigen.
CW: Fungiert die Mehrzahl der Architekturabteilungen noch als Wächter über das Portfolio oder haben sie sich mehrheitlich bereits anders aufgestellt?
AC: Ich kann nur aus der Erfahrung sprechen, die wir mit unseren Kunden gemacht haben, die mit unserem auf Kollaboration ausgelegten Produkt arbeiten. Im Durchschnitt arbeiten in den Kundenunternehmen 50 aktive Nutzer pro Monat mit unserem Tool. Wenn Sie jetzt noch berücksichtigen, dass es pro Unternehmen in der Regel zwei bis drei Architekten gibt, dann wird sehr deutlich, dass in diesen Unternehmen sehr kollaborativ auch mit anderen Abteilungen gearbeitet wird. Bei denen, die viel selbst entwickeln, nutzen neben den Architekten Business Engineers, Softwareentwickler und Projektleiter unser Tool. Bei denen, die mehr auf Standardsoftware setzen, finden wir unter den Nutzern zum Beispiel IT-Controller, Einkäufer, Prozessanalysten.
CW: Differenziert sich die Enterprise Architecture weiter aus und hilft diese Ausdifferenzierung beim Verlassen der klassischen Wächterrolle?
AC: Eine Ausdifferenzierung, die sich an den Bedürfnissen des Unternehmens orientiert, hilft sicher. Wie weit sich die Funktion aufgliedert, hängt jedoch stark vom Reifegrad der Architektur und von der jeweiligen Aufgabe ab. Ich hatte kürzlich ein Gespräch mit einem Chefarchitekten, dessen Unternehmen zurzeit einen sehr großen Merger bewältigen muss. Der sieht eine Ausdifferenzierung in Technology- und Security-, in Business-Application- und Data- sowie in Experience- und Product-Architecture.
CW: Gibt es noch weitere Entwicklungen, die zu einer moderneren Interpretation der EA-Rolle beitragen?
AC: Der Wandel von einer Projekt- in eine Produktorganisation. In der ersten wird am Anfang eines großen Projekts eine Zielarchitektur definiert, die mehrere Jahre Bestand haben soll. Danach wird entwickelt und Architektur und Entwicklung haben nur noch wenig miteinander zu besprechen. Beim Produktansatz ist das anders. Da beginnt man mit einem Minimal Viable Product, das sowohl vom Design und der Funktionalität, aber eben auch von der Architektur her weiterentwickelt wird. Allein schon deshalb, weil ein Pilotprodukt nur von wenigen Leuten benutzt wird, ein Massenprodukt aber auf viele Nutzer zielt und deswegen eine ganz andere Architektur braucht. Das heißt, in einer Produktorganisation muss man sich viel öfter austauschen. Der Dialog zwischen Architektur, Entwicklung und Fachseite ist nötig, weil das Produkt sonst nicht funktionieren kann.
CW: Stichwort Cloud. Es werden immer mehr Services Cloud – native oder „serverless“ entwickelt und das häufig auf der Plattform eines Hyperscalers. Spielt in solchen Szenarien Architekturmanagement überhaupt noch eine Rolle? Stellen diese Anwenderunternehmen, die sehr eng mit einem Cloud-Provider arbeiten und dessen Platform as a Service nutzen, überhaupt noch Architekturüberlegungen an?
AC: Architektur bleibt zum einen wichtig, weil viele Unternehmen eine Multi-Cloud-Strategie verfolgen und zum anderen, weil es selten Cloud in Reinform gibt, sondern meistens hybride Ansätze greifen, also nur ein Teil der Workloads in der Cloud residiert und andere Teile weiterhin on-Premises sind. Dabei spielt Architektur eine wichtige Rolle, denken Sie da nur an die Themen Security und Authentifizierung oder Datenmanagement.
Unsere Analysen zeigen, dass erst 26 Prozent der Business-Anwendungen in der Cloud sind. Und in dieser Transformation spielt Architektur eine zentrale Rolle. Es müssen Fragen nach der Auswahl der Cloud-Services oder Fragen nach der Transformation der Applikation selbst beantwortet werden. In den seltensten Fällen ergibt es Sinn, einfach eine On-Prem-Applikation per Lift and Shift auf eine virtuelle Instanz in die Cloud zu verlagern. Deshalb: Die Architektur wird nicht verschwinden, aber die Architekten müssen sich stark verändern“. Ohne ein Verständnis dafür, was die verschiedenen Cloud-Architekturen bieten, können Enterprise-Architekten ihre Unternehmen nicht mehr ausreichend unterstützen.
/EN/Reports/Thumbnail-Obsolescence-Gartner.png?width=140&height=100&name=Thumbnail-Obsolescence-Gartner.png)
/EN/White-Paper/EN-IDC-Inforbrief-Application-Rationalization-Portfolio-Management-Thumbnail_v2.png?width=140&height=99&name=EN-IDC-Inforbrief-Application-Rationalization-Portfolio-Management-Thumbnail_v2.png)
