Dieser Eindruck trügt. IT-Verantwortliche sollten sich von den Abgesängen auf den SOA-Hype ebenso wenig blenden lassen wie von den Hochglanzbroschüren der Softwarehersteller. Denn es gibt sie, die erfolgreichen SOA-Initiativen, auch in Deutschland. Nicht nur Pionieranwender wie die Deutsche Post haben bewiesen, dass SOA mehr ist als ein technikgetriebenes Modethema. Als strategische Option steht das Konzept bei einer Vielzahl großer Unternehmen und Behörden weit oben auf der Agenda. Dazu gehören die Daimler AG ebenso wie die Deutsche Bank, der Volkswagen-Konzern, die Telekom, die Hypovereinsbank oder auch die Bundesagentur für Arbeit. Die Bewerbungen zum computerwoche-Wettbewerb “CIO des Jahres 2008″ belegen zudem, dass SOA nicht nur in Großunternehmen ein Thema ist.

Eine gewisse Ernüchterung, manche Analysten sprechen von Abkühlung oder gar Desillusionierung, ist dennoch unverkennbar. Die zum Teil schlechten Erfahrungen in der Anfangsphase der SOA-Euphorie, aber auch überzogene Versprechen der IT-Hersteller, haben ihren Teil dazu beigetragen. CIOs, Projekt- und Prozessverantwortliche sollten diese Erkenntnisse als Chance begreifen, um ihre SOA-Pläne kritisch zu hinterfragen.

Die wichtigste Lektion: SOA ist, entgegen vielen Argumenten der Softwaregurus, kein reines IT-Thema. Wer SOA nur als Architekturparadigma für die Softwareentwicklung begreift, wird die erhofften Vorteile wie Flexibilität, Agilität und Effizienz kaum ernten können. Das volle Potenzial entwickelt eine SOA erst über die damit zu erzielenden Prozessverbesserungen. Dazu müssen die Fachabteilungen ins Boot, was direkt zur zweiten Lektion führt: Die Protagonisten müssen den wirtschaftlichen Nutzen einer SOA besser erklären. Das altbekannte Kommunikationsproblem der Techies wirkt sich in SOA-Vorhaben fatal aus.

Dazulernen müssen aber auch die Mitarbeiter in den Fachabteilungen, beispielsweise wenn es um den Umgang mit modernen Tools für die Prozessmodellierung- und -analyse geht. Eng damit zusammen hängt eine dritte Erkenntnis: Die mit SOA einhergehenden organisatorischen Veränderungen wirken nicht nur in den IT-Abteilungen, sondern potenziell in allen Unternehmensteilen und Führungsebenen. Ohne deren Unterstützung und Mitwirken bleibt SOA am Ende doch nur ein IT-Konzept.

Gerade dieses Interagieren der in vielen Unternehmen organisatorisch oft getrennt aufgestellten Domänen ist es jedoch, das nicht wenigen Konzernen in der Umsetzung Service orientierter Architekturkonzepte so seine Schwierigkeiten bereitet.

Dass das sogenannte „Business-IT-Alignment“ einen wesentlichen Erfolgsfaktor auf dem Weg hin zu einer effizienten Kommunikations-infrastrukturimplementierung darstellt, wird in Fachartikeln und Podiumsdiskussionen sowie Fachforen so häufig propagiert, wie es an Umsetzungspfaden zu dessen Erreichung mangelt. Überraschen kann dies indes nicht, ist doch die Verschaltung zwischen Geschäftsprozess und der als dessen Umsetzungswerkzeug agierenden IT einer der sensibelsten weil „menschlichsten“ Entwicklungsvorgänge, der zudem von Unternehmen zu Unternehmen individuell divergiert.

Inwieweit vor diesem Hintergrund „Studien“, wie jener des Unternehmens Amberpoint, nach der rund 60% der in einer Erhebung befragten CIOs im Rahmen der Einführung Service orientierter Architekturen bereits heute „die meisten ihrer Projekt-Ziele erreicht“ haben, Glauben geschenkt werden darf, bleibt der individuellen Interpretation der hier zugrunde gelegten (Projekt-)Zieldefinition durch jeden Einzelnen überlassen. So lassen nicht zuletzt die fortwährend intensiv geführte Diskussion des Themas sowie die stetig wachsenden IT-Budgets der Unternehmen für Beratung, Konzeption und Implementierung Service-orientierter Architekturen Zweifel aufkommen, ob die erhoffte Weiterentwicklung hin zum „agilen, den Anforderungen der Zukunft gewachsenen Konzern“ tatsächlich erreicht werden konnte.

Sollen auf ganzer Linie die heutzutage das Konzept nahezu ausnahmslos positiv besetzenden Potenziale einer SOA, wie Wiederverwendbarkeit von Diensten, agile, an wandelnde Umweltgegebenheiten sich flexibel anpassende Geschäftsprozesse oder, dadurch bedingt, durchschlagende Kosteneinsparungspotenziale gehoben werden, müssen Unternehmen eine ganze Reihe technischer wie auch organisatorischer und politischer Hürden nehmen. SOA wird zur Change-Management- und Organisationsaufgabe.

Und so lautet die Frage in Zukunft nicht mehr nur, wie eine Service orientierte Architektur zu implementieren ist, sondern auch bzw. vielmehr, wie eine Organisation geschaffen werden kann, welche die effektive Implementierung einer SOA überhaupt zulässt. Bleibt die Beantwortung letzterer Fragestellung jedoch weiterhin unbeantwortet weil unbeachtet, sind suboptimale Projektergebnisse, die am Ende jenen inzwischen gerade deshalb vermehrt laut werdenden Stimmen Nahrung geben, welche SOA als „anbieterorientierte Marketing-Strategie“  oder gar „Geldverschwendung“ verschreien, unvermeidliche Konsequenz.

IT- und Organisationsorchestrierung

Wirft man einen Blick in die Literatur, stellen Serviceorchestrierung und -choreographie zentrale Begrifflichkeiten im Hinblick auf die Philosophie der Prozesssteuerungswahl innerhalb des Themenfeldes Service orientierter Architekturen dar. Dass diese „(Neu)-Orchestrierung“ – oder allgemeiner, dieses neue Zusammenspiel – aller IT-bezogenen Instrumente eines Unternehmens auch ein neues Zusammenspiel der Organisationseinheiten eines Unternehmens, mit all den in ihnen verankerten Kompetenzen und somit nicht zuletzt eine neue Definition der Unternehmenspolitik notwendig macht, wird bislang oft außer Acht gelassen. Wird der konzeptionelle Ansatz einer SOA in Projekten, welche maßgeblich in die vitalen Geschäftsprozesse eines Konzerns eingreifen (und eben nicht irgendwelchen Mickey Mouse Projekten) zur Anwendung gebracht, kommt es zwangsläufig zu weit reichenden, durch eben jenen Verantwortungstransfer induzierten Machtverschiebungen innerhalb des Unternehmens, gegen die sich die vermeintlich unterlegene Partei, bei Wahrnehmung des Machtverlustes, mit den bekannten Mitteln zur Wehr setzen wird.

Dass auch bei zur Zusammenarbeit (zunächst) gewilltem Personal indes im operativen „Doing“ der mit der SOA-Konzeptumsetzung notwendigerweise einhergehenden Geschäftsprozessimplementierung in manchen Fällen Frustration aufkommt, liegt neben unklaren Projektzieldefinitionen oder auch in Einzelfällen nicht optimal ausgebildetem Personal, an in der Persönlichkeit begründeten Charakteristika von Denk- und Handlungsstrukturen der sich bewusst für unterschiedliche Berufsbilder entschieden habenden Charaktere, wie auch nicht selten orthogonal zueinander stehenden Ziel- und Anreizsystemen der betroffenen Fachbereiche.

So ist einerseits zu konstatieren, dass Menschen, die sich für unterschiedliche Berufsbilder entschieden haben – und kaufmännische und technische Stellenprofile divergieren inhaltlich doch deutlich voneinander – unterschiedlich sozialisiert und ausgebildet sind, andere Wertesysteme haben, gar in verschiedenen Wahrnehmungs- und Sprachwelten leben. Und so nähern sich „Process Engineer“ und Systemarchitekt – um nur zwei Stellenprofile prototypisch für beide Lager herauszustellen – Problemen ebenso unterschiedlich wie sie Begrifflichkeiten und Sprache divergent verwenden. Missverständnisse und die aufgrund divergierender Zielsysteme logischerweise entstehende Verfolgung individueller (lokaler) Optima sind die Folge. Gesamtoptima aus Unternehmenssicht können oder sollen nicht verfolgt werden.

Einen sinnvollen, wenn auch – vielleicht durchaus bewusst – inhaltlich sehr eng gefassten Lösungsansatz zu Annäherung beider Welten liefern Vollmar et al.  in ihrem Beitrag zur Governance-Umsetzung, welcher auf der herstellerübergreifenden Informationsplattform der Bitkom soa-know-how.de publiziert wurde. Sie propagieren mit der Etablierung eines „SOA Centers of Excellence“ die Schaffung eines bereichsübergreifenden Gremiums, „welches aus Mitgliedern der Fachbereiche und der IT auf unterschiedlichen Hierarchiestufen zusammengesetzt ist“ und dessen Aufgabe in der Unterstützung von Projekten, dem Durchführen von Architektur-Reviews oder dem Sammeln und Verwalten von Services und deren Metadaten liegt.

Im Gegensatz zu der von vorgenannten Autoren vertretenen Lösung zur Überwindung des „IT-Business Gaps“ sollte die Zusammensetzung dieses Gremiums indes nicht temporärer Natur sein, da sich Zielsystem und kulturell-soziologischer Hintergrund der in diesem vereinigten Individuen nicht innerhalb von Tagen – quasi per Dekret – nachhaltig im Sinne eines für (zumindest größere) SOA-Projekte erforderlichen ganzheitlichen Denkens und Handelns ändern lässt. Mehr noch: Das geschaffene Gremium benötigt einen Moderator zwischen IT und (i.d.R. kaufmännischen) Fachbereichen, der über weit reichende Entscheidungs- und Fachkompetenzen verfügt. Gerade letzteres ist in aller Regel sehr branchenbezogen, da Prozess Know-how, und über dies muss die Instanz zwingend verfügen, nicht nur in methodologischen Aspekten, sondern, zwecks Sicherstellung der Akzeptanz im Unternehmen und Projektzielführungskompetenz, vor allem auch in fachlichen Fragen unabdingbar ist. Letztlich sind die Aufgaben der Moderatorenfunktion vielfältig und reichen so von der zentralen Kommunikationssteuerung über das Prozess-Effizienzmonitoring bis hin zu Übersetzerfunktionen zwischen den unterschiedlichen Sprach- und Begriffswelten und dem hiermit oft verbundenen Konfliktmanagement.

Nur als eigenständige Instanz mit Weisungsbefugnis gegenüber Drittparteien ausgestattet, durch ein starkes Management etabliert und mit außergewöhnlichen kommunikativen Fähigkeiten ausgestattet, lässt sich die zweifelsfrei ebenso außergewöhnliche Herausforderung bewältigen. Vor allem aber bedarf es, wie bereits zuvor angedeutet, eines konsequenten und gut strukturierten Entwicklungsprozesses, Mitarbeiter in jene Position zu entwickeln. Diese Voraussetzung indes zu schaffen, ist Aufgabe des Top-Managements, welches wiederum professionell diesen organisatorisch sehr weit reichenden Wandel zu managen in der Lage sein muss.

SOA heißt daher weniger Tooldenken, weniger Top-Down oder Bottom-Up und ganz sicher zwecks Erzielung gesamtunternehmerischer Optima und Prozess- wie Systemkomplexitätsbeherrschung ein Aufeinanderzubewegen von Business und IT, das jedoch weiter greift, als manchem heute bewusst sein mag. SOA findet nicht per Erlass statt, es ist vielmehr „orchestrierter Entwicklungsprozess“ denn Projekt. Dann und nur dann wird unser Ansicht nach SOA sich auch rechnen.

Bernhard Balkenhol
Oliver Simon
Axel Wiemann
Infinity³

Regel 1: Überfallen Sie Ihre Ansprechpartner nicht mit Fachbegriffen

Überstrapazieren Sie nicht den Begriff „SOA“. Besser ist es, zunächst den erzielbaren Nutzen auf der Geschäftsebene in den Vordergrund zu stellen. Sprechen Sie mit der Geschäftsleitung über Prozesse, wie sich diese analysieren, steuern und automatisieren lassen und Sie finden rasch eine gemeinsame Gesprächsgrundlage. Die folgenden Gespräche rund um die IT fallen mit Sicherheit deutlich leichter und behandeln, welche Projekte notwendig sind und welche Architektur sich dafür am besten eignet. Das leitet auf eine logische Art und Weise zum Thema SOA über.

Regel 2: Erstellen Sie eine SOA-Nutzenmatrix

Listen Sie die verschiedenen Nutzenaspekte von SOA und ihre Auswirkung auf unterschiedliche Ebenen der Unternehmensführung in einer Matrix auf. SOA-Nutzenaspekte sind vielfältig und umfassen zum Beispiel Innovationsfähigkeit, Prozesseffizienz, Produktivität der Mitarbeiter, Governance von Geschäfts- und IT-Prozessen sowie Sicherung von IT Investitionen. Mögliche Ebenen der Firmenleitung sind: Unternehmensstrategie, Unternehmenspolitik, Finanzen, Unternehmenskultur und operationale Umsetzung.

Mit Hilfe der SOA-Nutzenmatrix sind Sie in der Lage, gezielt mit verschiedenen Ansprechpartnern über relevante Themen sprechen. Also zum Beispiel mit dem CFO über die Auswirkung auf den Cash-Flow oder das Risiko von Investitionen. Für den CEO sind Themen wie die Innovationsfähigkeit und die Möglichkeiten, neue Produkte und Dienstleistungen an den Markt zu bringen interessant. Der COO sowie Manager von Fachabteilungen hingegen beschäftigen sich eher mit operativen Aspekten, die etwa aus einer gesteigerten Produktivität oder höherer Prozesseffizienz entstehen.

Die Erarbeitung einer SOA-Nutzenmatrix ist also eine sehr gute Vorbereitung für die Nutzenargumentation auf allen Ebenen und ermöglicht es, zunächst über die Ziele von SOA zu sprechen, bevor die Implementierung besprochen wird.

Regel 3: Wählen Sie das richtige Projekt und die richtigen Partner für erste Erfolge

Erste SOA-Projekte sollten so ausgewählt werden, dass ein spürbarer Nutzen für die Geschäftsprozesse im Unternehmen entsteht. Ideal sind Projekte, in denen die SOA dabei hilft einen manuellen Prozess zu automatisieren oder zu vereinfachen. Weisen Sie Erfolge mit messbaren Kennzahlen nach. Achten Sie bei diesen ersten Projekten darauf, im Vorfeld nicht zu viel zu versprechen. Machen Sie die ersten Erfolge deutlich und kommunizieren Sie anschließend die SOA-Gesamtstrategie sowie den Nutzen für das Unternehmen. So finden zukünftige Projekte mit Sicherheit eine breite Unterstützung innerhalb Ihrer Organisation.

Der wichtigste Grund dafür liegt nach seiner Einschätzung im fehlenden “Business Sponsorship”, einfacher ausgedrückt: Das Management versteht den Nutzen einer SOA nicht. Das klingt nach einer Binsenweisheit, die in der Diskussion um das Für und Wider von SOA immer wieder auf den Tisch kommt. Doch Hailstone ist überzeugt, dass darin das entscheidende Hindernis liegt. Abhilfe könne nur eine bessere Kommunikation der Ziele und Nutzenpotenziale schaffen. Wer SOA nur als IT-Thema betrachte, könne diese Hürde kaum nehmen: Als “Tool” für die IT biete SOA nicht mehr als einen kosteneffizienten Weg, um Integrationsprobleme zu lösen. Aus der Sicht des Managements liefere eine SOA-Strategie demgegenüber den Schlüssel zum vielzitierten “Business/IT-Alignment”, sprich, sie ermöglicht es, IT- und Geschäftsziele in Einklang zu bringen. Daraus ergäben sich sowohl kurz- als auch langfristige Vorteile, darunter beispielsweise die Optimierung von Geschäftsprozessen, die einfache Integration von Geschäftspartnern oder die schnelle Entwicklung mächtiger Composite Applications aus bestehenden Software-Services.

Das Zauberwort in all diesen Fällen heißt Agilität, erläutert der Analyst. Damit verbunden ist die Fähigkeit von Unternehmen, sich schneller als die Konkurrenz an veränderte Marktbedingungen anzupassen und ihr damit einen Schritt voraus zu sein. Diese Botschaft müssten die meisten IT-Organisationen dem Business-Management erst klar machen. Solange sie diese Aufgabe nicht meistern, bleibe SOA ein Konzept für eine Minderheit.

Voraussetzung hierfür ist allerdings, dass sich die Unternehmensleitung und seine IT-Verantwortlichen intensiv in ihren eigenen Unternehmensprozessen auskennen und sich ihrer Kernkompetenzen bewusst sind. Hier liegt einer der Stolpersteine im SOA-Dschungel. Erst wenn Klarheit über die betriebswirtschaftlichen Abläufe im Unternehmen als auch die Differenzierung gegenüber dem Wettbewerb vorhanden ist, lassen sich auch stabile serviceorientierte Softwaredienste entwickeln, die helfen, genau diese Geschäftsabläufe zu optimieren. Bei vielen Unternehmen herrscht hier Nachholbedarf.
In diesem Zusammenhang werden zukünftig andere Fragen in den Vordergrund rücken:
• Wo und von wem erhalten Unternehmen zukünftig Software-Lösungen?
• Wie werden die Leistungen abgerechnet und verwaltet?
• Wo liegen die Informationen und wie sind sie abgesichert?
Ein Geschäftsführer oder eine Unternehmensführung hat selten das IT-Know-how für die Entwicklung eines eigenen SOA-Konzeptes. Hier wird oft auf qualifizierte Beratung aus IT-Systemhäusern zurückgegriffen, die bei der Einführung einer SOA-basierten Geschäftslösung unterstützen. Gerade für mittelständische Systemhäuser hält das SOA-Konzept interessante Geschäftschancen bereit. IT-Dienstleister entwickeln aus den einzelnen SOA-Komponenten branchenspezifische oder spezialisierte Anwendungskomponenten und können diese künftig in die Geschäftsabläufe des Kunden einklinken. Somit spielen IT-Systemhäuser als auch Softwareprovider eine extrem wichtige Rolle bei der Implementierung von SOA-Konzepten. Erst durch ihre intensive Beratungsleistung lässt sich aus dem „SOA-Konzept“ ein echter Mehrwert für Unternehmen generieren. IT-Partner, wie IT-Beratungshäuser oder Softwareprovider wissen, mit welchen Infrastrukturen sie Lösungen schaffen können, die ihre Kunden zukunftsträchtig machen.
Zukünftig wird um SOA kein Weg herumführen. Für den einen oder anderen Unternehmer ist auch von sekundärer Bedeutung wie sich der Grad der Verzahnung der betriebswirtschaftlichen Bereiche eines Unternehmens mit der IT auf technologischer Ebene abspielt. Entscheidend ist, dass SOA die Wirtschaftlichkeit seines Unternehmens erhöht und dessen Wettbewerbsfähigkeit steigert. Dabei gewinnen die Konzepte Web 2.0 und Software as a Service (Saas) sowie deren Einbindung eine weitere wichtige Bedeutung für die Entwicklung von adaptiven Geschäftsarchitekturen.

Daraus lässt sich sehr schnell ableiten, dass In-house-Entwicklungen weiterhin ein Thema und damit erforderlich sein werden. Während klassische Software-Entwicklungsumgebungen inzwischen praktisch zur Commodity geworden sind, sind Plattformen zur Unterstützung des Entwicklungsprozesses wieder umkämpft! Warum? Weil insbesondere Eclipse als Open Source Development Framework eine hervorragende Ausgangsplattform bietet und praktisch alle Hersteller diese auch unterstützen. Diese neuen, respektive auf SOA-Bedürfnisse erweiterten Plattformen, zielen stark auf Anforderungsmanagement (Requirements Management), Projektmanagement des Entwicklungsprozesses, Qualitätssicherung, Life-Cycle-Werkzeuge, Repositories, Testwerkzeuge, Optimierungswerkzeuge und andere, aus dem Umfeld des Entwicklungsprozesses ausgerichteten Tools, ab.
Die Übernahme von Mercury durch HP im letzten Jahr hat das Augenmerk erstmals seit längerem wieder auf diese Umgebungen gelenkt. Dabei spielen neben den etablierten Herstellern (z. B. IBM, HP, Microsoft) auch neue Anbieter wie Identify Software (jetzt als Teil von BMC) und Adlon (Application Lifecycle Management) eine zunehmend wichtige Rolle bei der sich intensivierenden Abstimmung zwischen den Business-Bereichen und der IT. SOA verspricht eine höhere Flexibilität der IT, die aus Business-Sicht dringend erforderlich ist. Diese höhere Flexibilität setzt eine verstärkte Entwicklungsgeschwindigkeit der hausinternen Entwicklungsabteilungen, bei gleichzeitig gestiegenen Anforderungen an die Zuverlässigkeit und die Qualität (auch bei der Fehlerbehebung), voraus. Hausinterne Entwicklungsabteilungen, die „schon“ nach einem halben Jahr eine neue Tarifstruktur, – z .B. bei einem Mobilfunkanbieter – anbieten können, müssen extreme Anstrengungen unternehmen, um diese Zeitspanne zu verkürzen. Denn gerade im Mobilfunksektor kann ein halbes Jahr bereits eine Ewigkeit sein. Bei der Integration von Anforderungen und Software-/Integrationstests (z. B. Borlands Reqirements Based Testing) handelt es sich dabei lediglich um grundlegende Bedingungen. In diesem Zusammenhang ist auch die gerade angekündigte Übernahme von Telelogic aus Schweden durch IBM bemerkenswert. Sie zeigt einmal mehr, dass IBM nicht müde wird, in die Nahtstelle zwischen Business-Anforderungen und der Umsetzung in individuelle Software-Lösungen auf der Basis von SOA zu investieren.
Schlussfolgerung : Business Process Optimization (BPO) und auch Business Performance Management (BPM – auch für Business Process Management) benötigen optimierte Software-Systeme, deren Komponenten von einem oder mehreren Herstellern stammen können. Sie müssen bei großen Anwenderunternehmen sicher durch eigene Software-Entwicklungen ergänzt werden. Auf den Einsatz entsprechender Tools wird zukünftig kaum jemand verzichten können. Unternehmen, die bisher noch keine derartige Software-Unterstützung im Einsatz haben, sollten sich dringend mit den Angeboten der relevanten Anbieter auseinandersetzen.

„SOA ist das Fundament für Agilität“ ist allerorten zu hören. Bausteine aus bestehenden Geschäftsprozessen werden verwendet, um neue, innovative Prozesse zu entwickeln, die Entwicklungskosten sinken rapide, die Innovationsgeschwindigkeit steigt. So schön, so gut. Die Realisierung dieser Möglichkeiten jedoch erfordert die Schaffung einer Gesamtunternehmensarchitektur (Enterprise Architecture), welche die Anwendungsarchitektur in den Kontext der Geschäftsprozesse setzt, sowie die Durchbrechung von Prozess- und funktionalen Grenzen innerhalb der Organisation.

SOA wird so zu einem Ansatz, das Geschäft durch IT zu strukturieren und damit die Basis für den Bauplan einer Prozess-Architektur zu legen. Der Geschäftsprozess-Architekt beschreibt, wie Business und IT strukturiert sind, welche Geschäftsprozesse bzw. -Abläufe benötigt und somit von der IT unterstützt werden müssen. Erst dann definiert der CIO, welche „Enabling Systems“ diese Abläufe – und deren schnelle Änderung! – unterstützen. Er definiert also, wie IT zum „Business Enabler“ des Unternehmens wird.
Um dies zu ermöglichen ist es erforderlich, auf die notwendigen funktionalen Fähigkeiten des Unternehmens zu fokussieren anstatt auf die Applikationen. Dafür müssen Geschäftsprozesse im Hinblick auf diese Fähigkeiten abgebildet werden, und diese dann wiederum auf Gemeinsamkeiten und Synergien hin analysiert, bevor sie auf die Systeme übertragen werden. Dann hat SOA den Effekt, dass die IT Systeme in eine übergeordneten Geschäfts- bzw. Unternehmensarchitektur eingebettet werden und Geschäftsprozesse konsequent in IT Services übersetzt werden, anstatt IT Systeme auf Prozesse zu setzen.
Um die stetige Ausrichtung der IT an den Geschäftsprozessen für die Zukunft sicherzustellen empfiehlt es sich daher, ein IT-Anforderungsmanagement aufzubauen, das auf Basis der definierten Unternehmensarchitektur und in enger Zusammenarbeit mit dem Business Anforderungen analysiert und diese durch die „IT-Liefereinheit“ zur Umsetzung freigibt. Während das Anforderungsmanagement auf IT-Effektivität (die richtigen Dinge zu tun) fokussiert, konzentriert sich die IT-Liefereinheit auf IT-Effizienz (die Dinge richtig zu tun). Wo das Anforderungsmanagement mit der bestehenden Unternehmensarchitektur an Grenzen stößt, etwas weil sich das Geschäft verändert hat, muss die Unternehmensarchitektur in enger Kooperation zwischen IT und Geschäft angepasst werden.

Bernhard Holtschke
Geschäftsführer im Bereich System Integration & Technology bei Accenture