6.09 Java Magazin Java Architekturen SOA Agile Sonderdruck der Firma alfabet AG www.javamagazin.de
SOA-Management mit einem EAM-Tool Für den Aufbau einer serviceorientierten Architektur (SOA) gibt es unterschiedlichste Szenarien, angesiedelt irgendwo zwischen zentral architekturgetrieben und dezentral projektgetrieben Letztere oft durch die Notwendigkeit motiviert, schnelle Integrationserfolge zu erzielen. Dem gegenüber steht die Notwendigkeit, ein geordnetes Serviceportfolio nachhaltig aufzubauen und eine vorhandene Legacy-Architektur planmäßig in eine SOA zu überführen. Daraus ergibt sich eine Verbindung zwischen Enterprise-Architektur und SOA-Management als inzwischen allgemein anerkannte Notwendigkeit. von Dr. Hans Friedrich Kammer in architekturgetriebener SOA- Aufbau verfolgt in der Regel das Ziel, IT-Funktionalität im größeren Maßstab durch SOA-Services zu realisieren. Sobald er sich diesem Ziel tatsächlich nähert, ergibt sich die Notwendigkeit, eine große Anzahl von Services mit ihrem Lebenszyklus und ihrer Beziehung sowohl untereinander als auch zum Rest der Architektur zu managen. Vorbedingung für einen nachhaltigen Erfolg ist hier eine entsprechende Vorbereitung der verantwortlichen Organisation und auch ihrer Toolunterstützung. SOA-Management im weiteren Sinne geht über den Rahmen von Architekturplanung und Architekturmanagement hinaus und umfasst auch das operationale Management von SOA-Services auf der produktiven Plattform sowie (bei entsprechendem Geschäftsmodell) unter Umständen auch Design und Entwicklung der dazugehörigen Artefakte. Das nachfolgend dargestellte Konzept wurde seit Anfang 2008 bei T-Systems entwickelt und steht damit selbstverständlich im Zusammenhang mit der spezifischen Situation des Unternehmens. Ausgangssituation bei T-Systems Im damaligen Unternehmensteil Business Services hatte schon seit Anfang 2007 über den unternehmensweiten Standard hinaus eine intensive Erfassung der bestehenden IT stattgefunden. Inhaltlich umfasste diese Bestandsaufnahme die Landschaft der Anwendungen und Schnittstellen inklusive ihrer Bezüge zu den Geschäftsprozessen und Geschäftsdaten des Unternehmens und beinhaltete auch eine funktionale Charakterisierung im Sinne von Geschäftsfähigkeiten (Capabilities). Ende 2007 stand bei T-Systems Business Services eine IT Architecture Roadmap auf der Tagesordnung, in der die SOA eine essenzielle Rolle spielte Ergebnis einer vorherigen intensiven Konzeptionsphase, die noch von einer Projektorganisation getragen wurde. Die heute inzwischen durchgeführte Umorganisation des Konzerns warf bereits damals ihre Schatten voraus und ließ keinen schnellen Einstieg in den Aufbau einer neuen IT im großen Maßstab zu. Bereits gestartete Realisierungsprojekte orientierten sich aber schon an den Konzepten der Roadmap inklusive der Zielsetzung SOA oder dem Setzen auf Web Services für die Integration. Aus diesem Grund wurde zunächst nach einer schnellen Lösung gesucht, um anlaufende Projekte einfangen zu können. Das SOA-Management sollte von 2 javamagazin 6 2009 Software & Support Verlag GmbH www.jaxenter.de
Anfang an mit reifen Konzepten, aber einer zunächst schlanken und entsprechend den weiteren Erfordernissen skalierbaren Organisation stattfinden. Lösungen 1.0 und 2.0 Der Fokus der Toolunterstützung lag zu Beginn auf der Dokumentation der erwarteten neuen Services, um von vornherein eine Grundlage für die spätere Überführung der Bottom-up-getriebenen Entwicklung in die endgültige Zielarchitektur zu schaffen, die damals aufgrund der noch in Vorbereitung befindlichen Neuausrichtung des Unternehmens nicht finalisiert werden konnte. Deswegen standen zunächst nur die Dokumentation von Services in Form von Office-Dokumenten mit Templates oder aber die pragmatische Nutzung des vorhandenen EAM-Tools für diesen Zweck zur Diskussion. Mit der Fragestellung besser als Excel lag die Messlatte sehr niedrig und daher fiel die Entscheidung für das bereits eingeführte und seit mehreren Jahren genutzte EAM-Tool planningit von alfabet. Nachdem die Antwort auf die Minimalanforderungen gefunden war, stellte sich die Frage nach einer weitergehenden Perspektive konkret auch nach der Notwendigkeit, weiter nach einem endgültigen Tool zu suchen. Daraus entstand das hier nachfolgend dargestellte Konzept, das mit Unterstützung der T-Laboratories und alfabet, als Hersteller des eingesetzten Tools, erarbeitet wurde. Im Zuge der Neuorganisation wurde dieses zunächst im Unternehmensteil Business Services entstandene Konzept für T-Systems insgesamt adaptiert. Eine wesentliche Prämisse dabei war, eine Aufteilung der IT in alte und neue Welt zu vermeiden, und dementsprechend auch das SOA- Management mit seiner Organisation und seinen Prozessen nicht neben die bestehende IT-Organisation zu stellen. Auch dies war ein Argument zugunsten der Verwendung der vorhandenen EAM- Toolunterstützung in einem (zu erweiternden) integrierten Prozess. Rahmenbedingung: Eine föderale SOA Eine wesentliche Weichenstellung bei einer SOA-Einführung ist der Grad der Abb. 1: SOA-Management Aufgaben und Schneidung der SOA-Organisation Zentralisierung. SOA erhebt grundsätzlich den Anspruch, schnelle Realisierungszyklen zu ermöglichen dem kommt die Dynamik von kleinen und agil agierenden Projekten entgegen. Der volle Benefit einer SOA für das gesamte Unternehmen ergibt sich aber erst durch ein durchgängig konsistentes Serviceportfolio. T-Systems beantwortete diese Frage mit einem Federate SOA -Ansatz. Dieser beinhaltet übergreifend gültige SOA-Standards, den Anspruch einer unternehmensweiten Sicht auf das gesamte Serviceportfolio, aber auch der Freiheit für einzelne Teilorganisationen, innerhalb dieses Rahmens weitgehend autonom Services zu entwickeln und zu nutzen. Der Rahmen des Konzepts für das SOA-Management ergab sich aus der geplanten Organisationsstruktur, die neben einem zentralen SOA-Management eine Betriebsorganisation für die SOA-Plattform (SOA Runtime) sowie ein eigenständiges Team für Entwicklung und Integration vorsieht. Bei dieser Schneidung liegt der Aufgabenschwerpunkt des zentralen SOA-Managements auf den Aspekten SOA Governance und (SOA-)Architekturplanung Letzteres beinhaltet das Handling der zentral verantworteten SOA-Anforderungen, das Management des gesamten SOA- Serviceportfolios und die Steuerung der Betriebsorganisation (SOA Release und Change Management nicht zu verwechseln mit dem Change Management im Sinne von ITIL, das wiederum Aufgabe der Betriebsorganisation selbst ist), (Abb. 1). Architekturframework und Domänenmodell Keine Enterprise-Architektur ohne Framework böse Zungen behaupten, dass über mindestens vier Frameworks gestritten wird, sobald sich drei Architekten zusammenfinden. Tatsächlich erschließt sich in der Praxis in einer Diskussion über das richtige Framework nicht immer die praktische Relevanz. Andererseits ist ein EAM inklusive der Toolnutzung mit mehr als drei Beteiligten wenig Erfolg versprechend, wenn kein gemeinsames Verständnis über die Bedeutung der modellierten Konstrukte besteht. Sobald ein SOA-Aufbau mit einer längerfristigen Planung verbunden ist, ergibt sich durch die Verwendung eines Frameworks mit der richtigen Strukturierung ein unmittelbarer praktischer Benefit. Richtige Strukturierung bedeutet in diesem Fall, dass im Rahmen des Frameworks länger- und kurzfristigere Planungsinhalte sinnvoll definiert und voneinander abgeleitet werden können. Bei der Wahl des Frameworks orientierte sich T-Systems am Architecture Development Model (ADM) von TOGAF, das die Planungsphasen einer Business Architecture, Information Systems Architecture und Technology Architecture umfasst. Diesen Phasen des Entwicklungsmodells entsprechen die Hierarchieebenen des gewählten Ar- www.jaxenter.de Software & Support Verlag GmbH javamagazin 6 2009 3
chitecture -Frameworks. TOGAF differenziert des Weiteren bei der Information Systems Architecture zwischen Data Architecture und Application Architecture; die für eine SOA adäquate Verallgemeinerung besteht in der Unterscheidung zwischen einem Logical Layer und Application Layer. Genau zwischen diesen beiden Ebenen besteht für die SOA ein wesentlicher Unterschied. Eine IT-Planung auf einem Logical Layer kann grundsätzlich durch den implementierungsunabhängigen Entwurf von Komponenten vorgenommen werden. Ohne SOA und ohne die Zuordnung zu einer Applikation schweben diese Komponenten aber in der Luft aus diesem Grund findet ein entsprechendes Design in der Regel nur im Rahmen einer Applikationsentwicklung statt, während sich die Architekturplanung im Application Layer abspielt. Aus der Perspektive der Architekten sind Daten und IT-Funktionen notwendigerweise einer Applikation zugeordnet, die sich mit anderen Applikationen durch Schnittstellen austauscht. In einer SOA sind die Verhältnisse anders: Sobald SOA-Services ins Spiel kommen, bietet sich eine Planung auf dem Logical Layer an. Im Rahmen dieser Planung kann konkret beschrieben werden, welche Services gebaut werden, was sie leisten und wie sie (logisch) miteinander interagieren sollen. Sinnvoll ist eine derartige Architekturplanung dann, wenn sie zur Grundlage der IT-Realisierung gemacht werden kann, also ausreichend verbindlich und überprüfbar ist. Dies kann ein logisches Servicedesign in Verbindung mit klar beschriebenen Realisierungs- und Integrationsstandards tatsächlich leisten. Umgekehrt ist die übergreifende Planung einer Architektur von SOA- Services im Detail vermutlich gar nicht machbar, wenn sie alle Implementierungsdetails eines Application Layers umfassen soll. Um welche Inhalte geht es nun konkret auf den unterschiedlichen Planungsebenen? Der Business Layer umfasst die Geschäftsziele, das Geschäftsmodell und Sobald SOA-Services ins Spiel kommen, bietet sich der Logical Layer an. die Geschäftsprozesse. Im Rahmen eines EAM und aus der Perspektive der Architekten werden diese Inhalte als Input des Business entgegengenommen, aber nicht aktiv gestaltet. Der Logical Layer beinhaltet Geschäftsdaten im Sinne eines Business Object Model (BOM) und IT-implementierbare Geschäftsfunktionen, sinnvollerweise eingebettet in ein IT- Domänenmodell. Bei der Beplanung einer SOA wird auf dieser Ebene darüber hinaus ein logisches Servicedesign beschrieben, mit Aussagen darüber, welche Services welche Geschäftsfunktionen realisieren und wie sie auf bestimmte Geschäftsdaten zugreifen (sollen). Bereits auf dieser Ebene kann eine logische Orchestrierung stattfinden, die die wesentlichen Abhängigkeiten der Services untereinander abbildet. Der Application Layer beinhaltet typischerweise die Landschaft der Anwendungen und Schnittstellen. Die SOA- Planung auf dieser Ebene beinhaltet die bereits implementierten (und konkret zur Implementierung geplanten) Services inklusive ihrer Nutzungsbeziehungen im Sinne von Service Contracts. Auf dem Technical Layer wird die tatsächliche technische Ausprägung der realisierten und geplanten IT abgebildet. Diese Ebene ist als Gegenstand der Architekturplanung bei einer outgesourcten IT weniger interessant der IT-Dienstleister garantiert hier Service Levels und ist selbst für ihre Ausgestaltung im Detail verantwortlich. Aufgabe SOA-Management Wie erwähnt, betrifft SOA-Management grundsätzlich den gesamten IT-Lebenszyklus Plan/Build/Run. Eine genaue Abgrenzung der planerischen Anteile gegenüber Implementierung und Betrieb hängt in der Praxis vom Geschäftsmodell ab, nach dem die IT gebaut und betrieben wird. T- Systems ist wie viele seiner eigenen Kunden hier selbst ein Outsourcer: IT-Realisierung wird beim IT-Dienstleister (auch im eigenen Haus) in Auftrag gegeben und beim Betrieb der Software ist auch T-Systems Kunde der eigenen Rechenzentren. Aufgabe der eigenen CIO-Organisation ist in beiden Fällen die Steuerung der Dienstleister, nicht die direkte Organisation der operativen Umsetzung. Bezogen auf die SOA ergeben sich damit auf der Planungsseite vier wesentliche Managementaufgaben, die im Folgenden erläutert werden. SOA- Bebauungsplanung Auf der Ebene einer strategischen Bebauungsplanung ist hinsichtlich der SOA noch kein hoher Detaillierungsgrad erforderlich. Gegenstand der IT-Bebauungsplanung ist die langfristige IT-Unterstützung des Business (d. h. der Organisation, der Geschäftsprozesse, der angebotenen Produkte) durch die IT. Im Rahmen einer SOA-Planung auf diesem Level muss dargestellt werden, in welchen Domänen eine SOA-Realisierung (wann) stattfinden soll. Die Beplanung einer SOA-Plattform auf dieser Ebene ist streng genommen selbst keine SOA- Bebauungsplanung (die SOA-Plattform ist, systematisch gesehen, eine Applikation), muss aber als wesentliche Randbedingung für das Ausrollen von Services mit einbezogen werden. SOA-Portfoliomanagement Das typische Szenario des SOA-Portfoliomanagements ist eng mit dem weiter unten beschriebenen SOA-Lifecycle- Management verbunden. Abgeleitet aus der strategischen Bebauungsplanung, wird ein Bedarf nach einem SOA-Service artikuliert. In einem toolunterstützten Portfoliomanagement kann durch eine Recherche der Status dieses Service ermittelt werden: Im günstigsten Fall ist er bereits vorhanden und muss lediglich einem weiteren Consumer zur Verfügung gestellt werden. Möglicherweise ist er schon als Kandidat, aber noch ohne konkrete Realisierungsplanung 4 javamagazin 6 2009 Software & Support Verlag GmbH www.jaxenter.de
beschrieben. Bei einer Legacy-Architektur ist es nicht unwahrscheinlich, dass die betreffende Funktionalität bereits in einer Applikation realisiert, aber als SOA-Service noch nicht verfügbar ist. Damit dieser vordere Teil des Portfoliomanagements stattfinden kann, müssen SOA-Services entsprechend ihrem Lebenszyklus dokumentiert und auffindbar sein. Streng genommen umfasst dieser Lebenszyklus der Services auch ihr Leben vor der SOA, d. h. auch die anderweitig realisierten Geschäftsfunktionen, die perspektivisch Bestandteil der SOA werden sollen. Die zentrale Aufgabe des SOA- Portfoliomanagements ist die planmäßige Entwicklung des Serviceportfolios entsprechend den Geschäftszielen. Wesentliche Anforderung an eine Toolunterstützung hierfür ist die Möglichkeit, das Portfolio in einer adäquaten Struktur und mit dem notwendigen Informationsgehalt zu dokumentieren. Wenn eine vorhandene Legacy-Architektur nicht von vornherein aus der SOA-Perspektive abgeschrieben, sondern die zukünftige SOA als Bestandteil einer neuen Welt betrachtet wird, muss ein SOA-Portfoliomanagement grundsätzlich auf alle in der IT verfügbaren Funktionalitäten zugreifen können. Es setzt also ein EAM voraus, das in diesem Sinne seine Hausaufgaben gemacht hat. SOA-Lifecycle-Management Die Notwendigkeit für ein SOA-Lifecycle-Management ergibt sich zum Teil schon aus dem dargestellten SOA- Portfoliomanagement. Über die Pflege des SOA-Serviceportfolios hinaus ist auch die Steuerung der operativen Umsetzung der SOA eine Planungsaufgabe. Wenn die Realisierung und das Deployment von Services beauftragt werden, bietet sich eine Dokumentation der entsprechenden Statusübergänge und betroffenen Releases im gleichen Rahmen an. Lifecycle-Management bedeutet demnach, den Übergang der Services von einem (planungsrelevanten) Status in den anderen zu steuern und zu dokumentieren. Als für T-Systems nicht planungsrelevant wurden dabei die für ein Entwicklungsprojekt typischen Übergänge betrachtet aus der Planungsperspektive sind Projekte Blackboxes, die einen Auftrag entgegennehmen und Ergebnisse abliefern. SOA-Service-Contract- Management Die Nutzung der Services durch Orchestrierung (untereinander) als auch durch andere Service-Consumer führt bei einer wachsenden SOA zu komplexen Planungsaufgaben. Die Migration von Legacy-Schnittstellen zu SOA-Services sprengt dabei den Rahmen einer ausschließlich SOA-bezogenen Planung. Die Inhalte, die hier zu managen sind, ergeben sich aus der Frage, wer wann welchen Service in welcher Ausprägung wie nutzt bzw. nutzen soll. Ein Teil dieser Fragestellungen ist deckungsgleich mit dem einer konventionellen Informationsarchitektur und sollte damit grundsätzlich in einem vollwertigen EAM-Werkzeug abbildbar sein. Andererseits werden sich in einer reifen SOA auch Fragestellungen darüber hinaus ergeben, die nicht zwangsläufig in den Rahmen eines EAM gehören (Security, Policy Enforcement). Abbildung von SOA- Informationen in planningit Aus einer Bottom-up-Perspektive, d. h. aus der weit verbreiteten Praxis heraus, Architektur mit Excel und PowerPoint zu dokumentieren, ist planningit zunächst ein technisches Werkzeug, mit dem sich unterschiedliche Architekturinhalte und ihre Beziehungen untereinander strukturiert abbilden lassen. Seitens des Herstellers steht allerdings ein höherer konzeptioneller Anspruch hinter dem Produkt, nach einschlägigen Studien auch nicht zu Unrecht. Das hier vorgestellte Nutzungskonzept für das SOA-Management war allerdings stark minimalistisch motiviert und versuchte zunächst pragmatisch, den eigenen Informationsbedarf in den angebotenen Konstrukten zu platzieren und dabei einen größtmöglichen Nutzen aus den im Rahmen des bestehenden Nutzungskonzepts gepflegten Inhalten zu ziehen. Eingepflegt waren als Kernbestand die Applikationen und Informationsflüsse der vorhandenen Architektur, verknüpft mit den nachfolgend aufgeführten Referenzdaten, und ergänzend dazu das Geschäftsprozessmodell des Unternehmens (High Level), ein Business Object Model sowie ein Domänen- und Geschäftsfunktionsmodell. Serviceabbildung wie und wo? Für die Abbildung von SOA-Services verfügt planningit über kein dediziertes Objekt, was aber nicht gegen das Produkt spricht. Das in der Praxis für die Abbildung von SOA-Services genutzte Konstrukt heißt Komponente und war ursprünglich dazu vorgesehen, IT- Standards als Teil der Architekturplanung zu unterstützen. Es würde zu weit führen, das nach wie vor gültige Konzept für IT-Standardisierung mit planningit darzustellen. Allerdings hat die Komponente (gegenüber der Applikation ) im Kontext von planningit eine besondere Bedeutung, die man verstehen sollte, wenn man sie praktisch nutzen will. planningit unterscheidet zwischen Standardkomponenten und lokalen Komponenten. Beide können jeweils Applikationen zugeordnet werden. Durch eine derartige Zuordnung wird dann z. B. der Tatbestand ausgedrückt, dass mein SAP (die Applikation) unter Linux (eine Komponente) mit einer Oracle-Datenbank (weitere Komponente) und mit den SAP-Modulen CO und FI (noch mehr Komponenten) läuft. Eine Standardkomponente wird praktisch gesehen immer dann verwaltet, wenn das betreffende Objekt außerhalb der nutzenden Applikation(en) auch selbstständig als Planungsobjekt von Interesse ist. Dies trifft z. B. dann zu, wenn der Einsatz einer Standardsoftware in mehr als einer Anwendung angestrebt wird. Eine Überprüfung der Ist-Architektur gegenüber dem Standard geschieht dann durch den Vergleich der verbauten Komponenten mit dem Standard, und eine Planung im Standard wiederum durch das Verbauen der Standardkomponente in den Applikationen der Zielarchitektur. SOA Logical Layer Wie oben dargestellt, sind SOA-Services auch bereits vor dem Verbauen in der www.jaxenter.de Software & Support Verlag GmbH javamagazin 6 2009 5
Applikationslandschaft wichtige Planungsgegenstände. Dementsprechend lag es nahe, sie durch Standardkomponenten von planningit darzustellen. Für die Darstellung der Versionen eines Service und der Statusübergänge innerhalb seines Lebenszyklus braucht es dann nur noch die Standardfunktionalität des Tools. Interessanterweise wird zwischen unterschiedlichen Komponententypen differenziert der Typ Service erwies sich hier aber gerade nicht als der passende, da nur der Typ Business die Möglichkeit bietet, den SOA-Service mit Geschäftsfunktionen und Geschäftsdaten zu verknüpfen (was ein wesentliches Anliegen der Planung im Logical Layer ist). Genau diese Informationen lassen sich mit der gewählten Konvention exakt und detailliert darstellen. Die Orchestrierung von Services untereinander kann in planningit ohne besondere Kunstgriffe durch Informationsflüsse zwischen Standardkomponenten dargestellt werden. SOA Application Layer Der Lebenszyklus eines Service in der rein logischen Sicht kann nicht die ganze Wahrheit enthalten. Die Frage, wo ein SOA-Service tatsächlich wirksam ist oder sein soll, muss im Application Layer beantwortet werden. Kein Service ohne Applikation: Der betreffende Enterprise Service Bus bzw. die betreffende Business Process Engine müssen als aufnehmende Applikationen eingepflegt werden, dann können die idealerweise bereits als Standardkomponenten angelegten Services innerhalb von ESB bzw. BPM (als lokale Komponenten) referenziert werden. Grundsätzlich ist es möglich, die tatsächlich vorgenommene Orchestrierung der betriebenen Services auf dieser Ebene darzustellen (nachdem die entsprechenden Beziehungen bereits im Logical Layer abgebildet wurden). Welche Modellierung wo stattfindet, sollte aufgrund des praktisch festgestellten Informationsbedarfs entschieden werden. Auf jeden Fall ist es sinnvoll, Nutzungsbeziehungen über die Grenze einer Applikation hinaus durch Informationsflüsse zu dokumentieren, auch Abb. 2: Abbildung von SOA-Services in planningit logische bis technische Sicht wenn sie nur zwischen Services bestehen. Die Dokumentation der Nutzung der SOA-Services durch Applikationen ist ein Muss, wenn eine planmäßige und agile Weiterentwicklung der SOA- Landschaft möglich sein soll. SOA Technical Layer Mit den bisher dargestellten Konventionen werden zwar SOA-Services innerhalb der höheren Layer modelliert, die verwendeten Konstrukte sind aber nicht eigentlich SOA-spezifisch. Mit dem Komponententyp Service hat alfabet den Erfordernissen einer SOA- Beplanung Rechnung getragen, da diese auch die Aspekte der technischen Realisierung einbezieht. Der Typ Service kann intern durch das Konstrukt Technical Service erweitert werden, das ungefähr den Informationsgehalt einer Servicebeschreibung durch eine WSDL hat. Tatsächlich ist es auch möglich, eine vorhandene WSDL einfach zu importieren, statt ihre Inhalte nachzudokumentieren. Sinn und Zweck dieser Konstruktionen zeigen sich erst, wenn man die unterschiedlichen Modellierungsebenen zueinander in Beziehung setzt (Abb. 2). Geschäftsfunktionen werden von einer Standardkomponente (Typ Business ) als Business Service referenziert eine derartige Modellierung drückt (auf der logischen Ebene) aus, dass der betreffende SOA-Service die referenzierte Geschäftsfunktion implementiert. Eine Komponente vom Typ Service referenziert die technische Sicht auf die durch einen Service implementierte Funktionalität. Auch eine solche Komponente kann als lokale Komponente eines ESB bzw. einer BPE referenziert werden. Im Kontext dieser Applikation (ESB bzw. BPM) kann durch ein Technical Service Mapping die Beziehung zwischen der Geschäftsfunktion und ihrer technischen Ausprägung hergestellt werden. Ergebnis einer derartigen Modellierung ist dann, dass über eine Geschäftsfunktion im logischen Modell am Ende auch bekannt ist, welcher Service draußen auf der Plattform tatsächlich realisiert wird. SOA im EAM SOA in der wirklichen Welt Eine Einbeziehung der technischen SOA-Aspekte im dargestellten Umfang hat auch T-Systems nicht im Rahmen des EAM vorgesehen wohl aber im Rahmen des SOA-Managements auf der produktiven Plattform. Die mittelfristig angestrebte Zielplattform ist hier das Produkt CentraSite der Software AG. Als günstig für T-Systems erwies sich hier die Strategie von alfabet, die Integration mit anderen Tools dort voranzutreiben, wo der eigene 6 javamagazin 6 2009 Software & Support Verlag GmbH www.jaxenter.de
Anspruch endet. Zwischen planningit und CentraSite existiert eine Schnittstelle, über die die technische und die logische/strategische Sicht auf die Services miteinander koordiniert werden können. Dabei sind unterschiedliche Ausprägungen möglich welche davon zum Tragen kommt, entscheidet das übergreifende Nutzungskonzept. Für T-Systems dürfte das Zielszenario so aussehen, dass die technische Seite der Services im Regelfall zunächst in CentraSite dargestellt wird und von dieser Seite Service -Komponenten nach planning IT propagiert werden, wo die Verbindung mit der logischen und Planungssicht hergestellt wird. Nicht zu vergessen sind die Services, die vor der SOA entstanden sind, und die einzu- fangen eines der ursprünglichen Anliegen des dargestellten Konzepts war. Zusammenfassung Ursprünglich als Minimalansatz use what you have gedacht, entwickelte sich das Konzept für die Toolunterstützung beim SOA-Management zu einer Rundumlösung, bei der derzeit keine funktionalen Lücken bekannt sind. Vielmehr muss die zukünftige Praxis zeigen, in welchem Umfang von den dargestellten Features von planningit Gebrauch gemacht wird. Die starke Integration von EAM und SOA-Management entspricht auch der IT-Strategie von T-Systems, in der keine neue Welt neben die vorhandene IT gestellt werden soll. Die stärkere Detaillierung einer SOA-Planung gegenüber der einer konventionellen Applikationsarchitektur muss voraussichtlich in der Organisation und den Managementprozessen beantwortet werden soweit es um die Toolunterstützung geht, sind die wesentlichen Fragen mit planningit und der CentraSite-Integration beantwortet. Dr. Hans Friedrich Kammer ist promovierter Physiker und seit 1993 als IT-Entwickler, Projektleiter und Berater mit Schwerpunkt Architektur im TelCo-Bereich tätig. Von 2006 bis 2008 arbeitete er im Architekturmanagement des CIO-Bereichs von T-Systems, seit März 2009 als Consultant bei der Cirquent GmbH. alfabet AG wurde 1997 in Berlin gegründet und unterstützt seitdem Großunternehmen, ihren IT-Einsatz besser am Geschäftserfolg auszurichten. Unternehmen und Marktbeobachter sind sich einig, dass die Grundlagen für diese Ausrichtung in einer effektiveren und effizienteren IT-Planung gelegt werden müssen. alfabet übernimmt hier eine Vorreiterrolle und hat mit planningit eine Standardsoftwarelösung entwickelt, die eine solch kollaborative IT-Planung erstmalig ermöglicht. Die Lösung basiert auf der Kompetenz und auf den langjährigen Erfahrungen, die alfabet in seiner Arbeit mit IT-Organisationen internationaler Unternehmen und großen IT-Service-Providern sammeln konnte. Unternehmen nutzen planningit, um Transparenz und integrierte und hochgradig automatisierte IT-Planungsprozesse zu etablieren. planningit ist die zentrale Informations- und Entscheidungsplattform für die kontinuierliche Transformation der IT (ERP für die IT), um mit den sich dynamisch ändernden Geschäftsprozessanforderungen Schritt halten zu können und dabei Anforderungen der Compliance und Ausnutzung von neuen Technologien sicherzustellen. Das Unternehmen bedient derzeit 16.000 IT-Anwender aus den Branchen Automobil-, Finanzdienstleistungen-, Telekommunikation-, Energiewirtschaft-, Chemische-, Transport & Logistik und Tourismusindustrien. Zu den Kunden von alfabet gehören international agierende Firmen wie AXA Winterthur, Generali, BP, Credit Suisse, Daimler, Deloitte, Deutsche Bahn und T-Systems. Die Analysten von Gartner und Forrester stufen alfabet als Marktführer für Enterprise Architecture Management und Change Management und IT Roadmapping ein. www.jaxenter.de Software & Support Verlag GmbH javamagazin 6 2009 7
alfabet AG Leibnizstraße 53 D-10629 Berlin phone: +49 30 880 345 0 fax: +49 30 880 345 999 e-mail: mail@alfabet.com web: www.alfabet.com