Vier Säulen eines Soba-Frameworks
Maßgeblich sind für ein Soba-Framework (Gartner-Bezeichnung für Service Oriented Business Applications) vier paritätische Säulen: Prozesse, Daten, Regeln und handelnde Parteien. Diese sind in einem Benutzerportal zu integrieren.
Die Prozessebene dient dazu, Geschäftsprozesse als kollaborativ übergreifende Prozesse und die darin verwendeten Lifecycle-Prozesse der zugehörigen Daten zu verwalten. Hier sind Aktivitäten mit den Anweisungen für die handelnden Personen, Entscheidungsregeln und Transitionen in den gegebenenfalls aggregierten Prozessen definiert und werden vom Prozess-Manager ausgewertet. Der Inhalt der Daten bildet gleichzeitig die Basis für die Entscheidungsregeln, mit deren Hilfe sich die Prozesse steuern lassen. Ist beispielsweise bei der Kenngröße "Auslastung" einer Datenleitung der Wert 80 Prozent als Schwelle bestimmt, tritt mit dem Erreichen dieser Grenze eine automatisierte Entscheidungsregel in Kraft. Zum Beispiel: "Mit dem Bereitstellen einer weiteren Leitung fortfahren".
Hinter der Regelebene versteckt sich ein Repository, in dem die Vorgaben als ablauffähiger Code hinterlegt sind, wobei sich neue Regeln mit einfachen Mitteln aus den bereits bestehenden bilden lassen müssen. Das heißt auch, dass das Repository sich jederzeit ergänzen und verändern lassen muss, um ständig die aktuelle Geschäftslogik verfügbar zu haben, ohne dass Release-Wechsel des Frameworks selbst notwendig sind. Bleibt man im Beispiel der Datenleitung, bedeutet das etwa, dass sich die Abrechnung des Betriebs über die Regeln der verschiedenen Faktoren ableiten lässt. Von Rabatten über technische Kenngrößen wie "genutzte Bandbreite" bis hin zu kaufmännischen Kenngrößen wie "Status der Geschäftsbeziehung". Ändert sich eine Regel, so wird nur der Algorithmus im Repository ausgetauscht, das restliche Framework der Applikation ist davon jedoch nicht betroffen.
In der Datenebene ist das Modell abgebildet, auf dessen Basis sich Daten integrieren und aggregieren lassen, um so das Geschäftsvokabular für alle funktions-, abteilungs- und unternehmensübergreifenden Prozesse in einem Repository zusammenzuführen. In den Metadaten werden die Datentypen und ihre semantischen Beziehungen beschrieben. Über Bildung von Templates aus den Metadaten ist eine weitere Spezialisierung und Individualisierung des Datenmodells möglich, insbesondere auch bezüglich der prozeduralen Beziehungen zwischen Datenelementen und den sie steuernden Prozessen. Beim Betrieb der Datenleitung lässt sich beispielsweise festlegen, welches Configuration Item (CI) "Leitung" mit welchen CIs "Komponenten" von "welchen Personen" in "Betrieb zu nehmen" und "im Betrieb zu betreuen" ist. Diese Beziehungen müssen für den Benutzer möglichst einfach und übersichtlich dargestellt werden.
Als Schnittstelle zum Benutzer fungieren dabei Portale, die die Interaktion mit den Prozessen und Diensten ermöglichen. Hier lassen sich Applikationen und Dienste als Summe von Prozessen orchestrieren, wobei natürlich die Rolle und Verantwortlichkeit der jeweiligen Benutzer in einem Rechtekonzept abgebildet sein muss.