“Fit” sein für SOA

Feature | 28. Juni 2006 von admin 0

Die neuen SAP-Lösungen sind auf die Enterprise Service-Oriented Architecture (Enterprise SOA) ausgerichtet – und das hat seinen Grund. In einer aktuellen Untersuchung erklärten 75 Prozent der befragen Unternehmen, für die anstehenden Vorhaben in den Bereichen Customer Relationship Management (CRM), Enterprise Resource Plannung (ERP) und Supply Chain Management (SCM) service-orientierte Architekturen einsetzen zu wollen.
Es ist wohl nur noch ein Frage der Zeit, bis IT-Abteilungen die Migration zu den neuen Plattformen in ihre Planungen einbeziehen – falls sie nicht schon damit begonnen haben. Aber kennen die Führungskräfte der Fachabteilungen die Pläne ihres Unternehmens bezüglich SOA, ERP-Migration oder ERP-Konsolidierung? Manager tun gut daran, sich die Leistungsmerkmale einer SOA vor Augen zu führen. Dann können sie aktiv, wirksam und mit Fachwissen an den Planungen mitwirken und sicherstellen, dass den Bedürfnissen ihrer Abteilungen bestmöglich entsprochen wird.

Leichtere Integration

Service-orientierte Architekturen lassen Informationen leichter an jeden anfragenden Nutzer fließen. Dies optimiert Prozesse und unterstützt Unternehmen dabei, mit ihren Kunden, Partnern, Lieferanten und Mitarbeitern zu kommunizieren.
Die größte Stärke von SOAs ist ihre Fähigkeit, Systeme zu integrieren und bereits vorhandene Software wieder zu verwenden. Die meisten IT-Umgebungen in Unternehmen sind ein Sammelsurium von Systemen, über die Jahre entstanden durch Aufkäufe, Veräußerungen und internes Wachstum. Doch das Festlegen von Unternehmensstandards für Hardware, Betriebssysteme, Datenbankstrukturen und andere Parameter, war schon immer eine schwierige – wenn nicht sogar unmögliche – Aufgabe.
Früher verlangte die Integration heterogener Systeme – entweder innerhalb von oder zwischen Unternehmen und ihren Geschäftspartnern – eine aufwändig zu entwickelnde unternehmensspezifische Schnittstelle, die immer dann störungsanfällig wurde, wenn eines der Teilsysteme sich änderte. Eine SOA ermöglicht Integration, ohne dass für jedes anstehende Projekt das Rad neu erfunden werden muss. Sie schließt Kommunikationslücken zwischen den verschiedensten Standard- und kundenspezifischen Anwendungen, die auf unterschiedlichen Plattformen und Betriebssystemen laufen.

Mehr Systemflexibilität

Viele Unternehmen arbeiten mit mehreren ERP-Lösungen. Werden Auftragseingänge in verschiedenen Anwendungen bearbeitet, muss beispielsweise die Finanz- und Steuerabteilung mehrere Umsatz- und Verbrauchssteuerprogramme betreiben und Daten darin pflegen – wobei jedes über eine eigens angefertigte Schnittstelle angebunden ist.
In einer SOA hingegen greifen die verschiedenen Lösungen auf Steuerdienste zu, die auf einem plattform-unabhängigen, Web-gestützten Server laufen. Die ERP-, Rechnungslegungs- und E-Commerce-Anwendungen der gesamten Organisation rufen den zentralisierten Steuerservice über das bestehende Intranet auf. Dies vermeidet kostspielige Hardware-Installationen, Software-Updates und Patches für unterschiedliche Steuerprogramme.
Steuerdaten lassen sich unabhängig vom Steuerservice bereitstellen, so dass leichter auf sie zugegriffen werden kann und sie sich problemlos aktualisieren lassen. Dies erlaubt eine umfassendere Datenpflege und mehr Unabhängigkeit von der IT. Unternehmen können durchgängig einheitliche Steuerberechnungen vornehmen, Entscheidungen zur Besteuerung treffen und die für ihre Umsatzsteuererklärung notwendigen Daten aus verschiedenen Anwendungen oder von mehreren Standorten zusammenführen.
Und schließlich ist in einer SOA bei einem Upgrade der ERP-Lösung nicht auch gleich eine Aktualisierung der Steuersoftware notwendig, da beide Anwendungen getrennt voneinander bereitgestellt werden.

Schnellere Implementierung und größere Skalierbarkeit

Der Einsatz serviceorientierter Architekturen senkt dank des geringeren Bedarfs an Systemintegration die Implementierungskosten erheblich. Der Aufwand für das Erlernen von SOA-Entwicklungen ist relativ klein, so dass es bereits zahlreiche erfahrene Programmierer gibt. Damit wird die Suche nach talentierten Mitarbeitern weniger problematisch, als dies bei anderen neuen Technologien der Fall ist. Da die meisten bestehenden Technologien schon für eine SOA-Entwicklung erweitert wurden, können Programmierer mit vorhandenen Werkzeugen und Programmiersprachen quer durch die SOA-Landschaft entwickeln und integrieren.
Die Flexibilität serviceorientierter Architekturen erlaubt darüber hinaus eine größere Skalierbarkeit und Systemleistung. Da eine SOA über mehrere Server verteilt wird, laufen die Dienste frei beweglich im Netz. Damit ist es möglich, die darunter liegende Infrastruktur zu skalieren oder ein Upgrade durchzuführen, ohne gleich den Systembetrieb zu unterbrechen. Zusätzlich lassen sich Dienste mehrfach aufrufen und somit viele Aktionen gleichzeitig ausführen, um eine höhere Arbeitslast zu verarbeiten. Auf diese Weise bietet eine SOA endlich die Skalierungsvorteile, die von verteilten Systemen lange Zeit in Aussicht gestellt wurden, deren Technologie und Implementierung aber immer noch auf Standards basieren.
Aufgrund der niedrigeren Integrations- und Wartungskosten entsteht bei einer serviceorientierten Architektur ein positiver Return on Investment (ROI). Immerhin kostet das Programmieren einer Schnittstelle zwischen zwei kundenspezifischen Anwendungen bis zu einer Million Dollar. Selbst unter Berücksichtigung der Kosten für die Umschulung von Entwicklern auf SOA-Technologien und die Konvertierung bestehender Anwendungen sind die meisten Analysten davon überzeugt, dass eine SOA langfristig einen positiven ROI hervorbringt, da mehrere unterschiedliche Anwendungen zu einer Handvoll SOA-Dienste kombiniert werden können.
Kurzfristig ermöglicht es eine SOA, weniger Softwareprogramme zu unterhalten und Prozesse zu zentralisieren. Wenn Unternehmen die Lebensdauer bestehender Lösungen verlängern können anstatt neue schreiben zu müssen, kann der ROI dank der geringeren Kosten für IT-Beratung und Systemintegration rapide ansteigen.

Vorbereitung in vier Schritten

Die Umstellung auf eine SOA kann sich für Unternehmen als unvermeidlich erweisen. Dann bleibt die Frage, ob die Abteilungen dafür vorbereitet sind. Manager können sich für diesen Gezeitenwechsel rüsten, indem sie die folgenden vier Schritte beherzigen.

  • Erstens gilt es, bei IT-Initiativen, die eine mögliche direkte Auswirkung auf die jeweilige Fachabteilung signalisieren, wachsam zu sein. Die Implementierung einer SOA kann im Windschatten anderer IT-Projekte anstehen oder ein eigenständiges Vorhaben sein. Wichtige Drehpunkte sind das Upgrade oder die Neuinstallation eines ERP-Systems, eine Prozesszentralisierung oder eine angekündigte Verlagerung zu einer service-orientierten Architektur.
  • Zweitens müssen Manager die Kommunikationskanäle mit der IT-Abteilung offen halten. Der Dialog stellt sicher, dass neue Unternehmenssoftware die Standards einer service-orientierten Architektur unterstützt. Der Steuerfachmann eines Unternehmens beispielsweise trifft zwar keine Entscheidungen über die Wahl einer Plattform oder Anwendung, aber er sollte sich bei der Implementierungsplanung einer neuen ERP-Installation oder bei einem Upgrade engagieren. Führungskräfte müssen die SOA auf die Liste der Punkte setzen, über die sie mit der IT-Abteilung diskutieren, und zwar vor und während dieses Prozesses.
  • Drittens kommt es darauf an, die richtigen Fragen zu stellen. Da an einer SOA-Implementierung verschiedene Unternehmensbereiche beteiligt sind, sollten Manager frühzeitig die Punkte zur Sprache zu bringen, welche die gesamte Organisation betreffen. Eine wichtige Frage ist, welche neuen Projektmanagementstrukturen – und finanziellen Mittel – notwendig sind, um eine service-orientierte Anwendung zu erstellen. Genauso wesentlich ist aber, welche neuen Projektkonfigurationen eine adäquate technische Abstimmung zwischen verbundenen SOA-gestützten Anwendungen sicherstellen und wie früh im Projekt Anwendungsabhängigkeiten aufgedeckt und vorhandene Ressourcen neu eingesetzt werden können.
  • Und viertens müssen sich Manager auf die Bedürfnisse des Unternehmens konzentrieren. Der Einsatz einer SOA ist gleichermaßen eine unternehmerische wie technische Frage. Für viele Firmen wird die große Herausforderung nicht die Implementierung von Softwarearchitekturen, sondern die Definition von unternehmerischen Regeln und das Gestalten von Geschäftsprozessen. Während die IT-Abteilung die internen Anwendungen einer SOA implementiert – der erste Schritt für die meisten Unternehmen – sollten sich Manager über die Entwicklungen im Bereich SOA-Technologien auf dem Laufenden halten. Es kommt darauf an, genau die Fragen und Probleme auszumachen, die die jeweilige Abteilung berühren und die betroffenen Prozesse bei der Implementierung der Technologie neu zu bewerten.

Die Geschäftsprozesse prägen das IT-Modell

Vertex Inc.

Vertex Inc.

Eine SOA ermöglicht eine neue, produktive Beziehung zwischen der IT-Abteilung und den anderen Unternehmensbereichen. Anstatt die Probleme einzelner Abteilungen einfach in Form eines Pflichtenhefts bei der IT Abteilung “abzuladen”, erfordert eine SOA eine echte Zusammenarbeit, um die IT den Geschäftsprozessen anzupassen. Mit einer service-orientierten Architektur wird Technologie zum Agenten der Veränderung – und nicht zum Hemmschuh. Durch den Einsatz flexibler Technologien können Unternehmen neue Prozesse, Software und sogar erworbene Firmen oder Bereiche effektiver und effizienter als in der Vergangenheit integrieren.
Basierend auf gängigen Standards und Technologien bieten service-orientierte Architekturen Unternehmen einen Weg für eine Softwareentwicklung, die im Vergleich mit anderen IT-Konzepten schneller, leichter, kostengünstiger, flexibler, skalierbarer und für ihre unternehmerischen Aktivitäten relevanter ist. Aber – und dass trifft für alle technologischen Veränderungen zu – am meisten werden diejenigen Unternehmen davon profitieren, deren Geschäftsbereiche und Support-Organisationen gut informiert sind, bei IT- Entscheidungen mitwirken und sich auf unternehmerische Fragen konzentrieren.

www.vertexinc.com

John A. Viglione

John A. Viglione

Leave a Reply