Analog zur Architektur im Bauwesen gibt es auch in der IT schon lange eine Funktion, die sich mit den wesentlichen Komponenten eines (IT-)Systems, den Zusammenhängen zwischen diesen Komponenten sowie den allgemeinen Richtlinien zur Entwicklung und Weiterentwicklung des Systems beschäftigt. Durch Architekturplanung und Umsetzungskontrolle soll sichergestellt werden, dass Lösungsdetails in kohärenter Weise entwickelt bzw. verändert werden und dass dabei übergreifende Prinzipien beachtet werden. Als Unternehmensarchitektur wurde die Architekturfunktion vor ca. zwanzig Jahren auch auf „das Geschäft“ bzw. das Zusammenspiel zwischen Geschäft und IT-Unterstützung ausgedehnt. Je umfassender und komplexer der Gegenstand wird, umso wichtiger wird es, sich weiterhin auf Wesentliches zu konzentrieren. Unternehmensarchitektur beschäftigt sich deshalb nicht mit einzelnen (IT-gestützten) Geschäftslösungen, sondern mit deren Gesamtheit. Analog zum Bauwesen ist dafür der Begriff Bebauungsplanung passender als Architektur. Es geht darum, aus Gesamt-Unternehmenssicht Redundanzen und Widersprüche zu reduzieren (Kohärenz), indem dafür Sorge getragen wird, dass bestimmte Transparenz  und Wiederverwendungsregeln unternehmensweit beachtet werden.

Zu diesem Zweck hat die Disziplin verschiedenste Bebauungsplanungs-Modelle und  Methoden entwickelt. Der Preis für die Begrenzung der Gesamt-Komplexität besteht allerdings nicht nur im Planungs- und Kontrollaufwand (z.B. Freigabeprozess), sondern insbesondere in der Einschränkung des Gestaltungsfreiraums für Veränderungsprojekte. Aus Projektsicht sind als Alternative zum „plan-driven“ Ansatz deshalb „change-driven“ Ansätze wie z.B. Agile oder Lean attraktiv, weil letztere auf hohe Autonomie, Einfachheit und Schnelligkeit setzen. Dabei wird jedoch in Kauf genommen, dass mehr lokale Gestaltungsfreiheit ohne wirksame flankierende Maßnahmen mittel- und langfristig zu höherer Komplexität des Gesamtsystems führen – und damit dessen Agilität verringern.

Wie kann diese Ausprägung des klassischen Zielkonflikts zwischen globalen und lokalen Zielen aus der Perspektive Bebauungsplanung gelöst werden? Im Sinne von „Choose battles large enough to matter, but small enough to win” sollte kein ausgefeiltes Planungs- und Kontrollinstrumentarium auf Projekte bzw. Lösungen angewandt werden, die (z.B. im Bereich Kundeninteraktion) sowieso nicht sehr lange existieren oder nicht wesentlich sind. Andererseits machen Agile und/oder Lean dort wenig Sinn, wo (z.B. für Backstage-Prozesse) Anforderungen weitgehend stabil und klar sowie Lösungs-Lebensdauern lang sind. Zwischen diesen beiden Extrema, für die entweder traditionelle „plan-driven“ oder eben „change-driven“ Ansätze die jeweils besten Effekte erwarten lassen, existiert jedoch ein großer „Graubereich“. Sehr viele Innovationsprojekte und insbesondere komplexe Programme betreffen ja weder ausschließlich übergreifende, stabile noch klar lokale, kurzlebige Geschäftslösungen. 

Wie kann erreicht werden, dass bei Designentscheiden in Projekten übergreifende Ziele beachtet werden, ohne die Autonomie formell zu stark durch Planung und Kontrolle einzuschränken? Durch die Linse der Steuerungs- und Institutionalisierungstheorie betrachtet, beruht die in der Praxis gelebte Koordination primär auf formellen Interventionen und koerziven Mechanismen (z.B. Regeln, Sanktionen, Belohnungen). Informelle Interventionen und normative / mimetische Mechanismen (z.B. Vorbilder, Sinnstiftung, Internalisierung externer Effekte) spielen höchstens eine Nebenrolle. Studien zeigen jedoch, dass – insbesondere, wenn die Umsetzung in Form von Nudges erfolgt – gerade mittels informeller Interventionen erreicht werden kann, dass formell autonome Entscheidungen gleichwohl unternehmensweite Ziele zumindest teilweise berücksichtigen.

Bei differenzierter Betrachtung ist Bebauungsplanung im Unternehmen deshalb weder nur Verhinderer noch nur Enabler von Agile und Lean. Wichtig ist, sich in Veränderungsprojekten darüber klar zu werden, in welchem Verhältnis jeweils unternehmensweite (Komplexitäts )Folgen und lokale, kurzfristige Entscheidungsfreiheiten stehen. Bei klaren Konstellationen sollten entsprechende Vorhaben je nach Charakter einem der Normansätze (Planung / Kontrolle oder Agile / Lean) unterworfen werden. Für die vielen Fälle, in denen Zielkonflikte nicht einfach aufzulösen sind, sollte jedoch ein Koordinationsansatz gewählt werden, der zwar formell (bis auf möglichst wenige, wirklich zentrale Einschränkungen) den Projekten viele Freiheiten lässt, gleichzeitig aber intensiv informelle Interventionen einsetzt, um mittel- und langfristig die Agilität des Gesamtsystems zu erhalten.

R. Winter (2014), "Architectural Thinking," Business & Information Systems Engineering, vol. 6, no. 6, pp. 361-364.

R. D. Schilling, S. Aier, and R. Winter (2019), "Designing an Artifact for Informal Control in Enterprise Architecture Management," Proceedings of the 40th International Conference on Information Systems (ICIS 2019), Munich.