SOA: Licht in den Begriffdschungel Donnerstag, 24. Mai, 9.15 bis 10.45

SOA:

Licht in den BegriffdschungelDonnerstag, 24. Mai, 9.15 bis 10.45

Dr. Dieter Wenger, Wenger Competence Consulting, [email protected], Tel. 079 237 1001

2

Ziele des Seminars

Welches sind die Erwartungen des Geschäftes an die IT?

Wieweit können diese Erwartungen mittels SOA erfüllt werden?

Wie sieht die moderne Software-Architektur aus?

Wie sieht deren Nutzung aus?

Das Seminar ist ausgerichtet auf:

IT-Management, IT-Projektleiter, Consultants, Business Engineers, Integratoren, Organisatoren, ...

Achtung !

Dies ist kein technisches SOA Seminar.

3

Agenda

SOA & Moderne Software Architektur (35 Minuten) Wenger Competence Consulting

Case Study: Health (20 Minuten) Swisscom Information Services (SCIS) AG e-Serve AG

Case Study: Banking (20 Minuten) Steria Schweiz AG

Diskussion (15 Minuten)

4

Inhalt

Erwartungen des Geschäftes

SOA: Prinzip

SOA & Business Process Management (BPM)

SOA & Model-Based Architecture (MDA)

SOA & Enterprise Content Management (ECM)

SOA: Moderne Software Architektur

Merkmale

Vorteile

Nutzung

Plattformen

Die Roadmap

5

Inhalt


SOA: Prinzip





Merkmale

Vorteile

Nutzung

Plattformen

Die Roadmap

6

Erwartungen des Geschäfts

Ziele des Geschäftes: Differenzierung durch:

Steigerung der Geschäftsprozess-Werte (Business Value) Senkung der Geschäftsprozess-Kosten

Erwartungen an die Software-Lösungen: Hohe Geschäftsprozess-Unterstützung

Automatisierung, Benutzerunterstützung (Autonomisierung) Business Compliance / Business Orientierung

Hohe Flexibilität Hohe administrative Flexibilität Schnelle Umsetzung von neuen geschäftlichen Anforderungen Strategische Optionen

Hohe Stabilität Tiefe Kosten

Geringe Betriebs- und Prozessoptimierungs-Kosten Kontrolle durch Business / Transparenz für Business Hohe Performanz

7

Inhalt


SOA: Prinzip





Merkmale

Vorteile

Nutzung

Plattformen

Die Roadmap

8

SOA: Prinzip Redundanzfreiheit

Ein Geschäftsprozess ist ein Service !

Outsourcing Teile von Prozessen, die in verschiedenen

Prozessen gleich sind, werden in einen neuen Prozess ausgelagert.

Auslagerung von Services. Es entsteht eine Service-

Auslagerungstruktur

Beispiel: Der Service ‚Kunde aufnehmen/mutieren‘ ist

in 2 verschiedenen Prozessen gleich.

Vorteile: Reuse Eliminierung Prozess-Redundanz

(Ressourcen) Eliminierung Daten-Redundanz

Verkaufs-Prozess

Support-Prozess

Verkaufs-Prozess

Support-Prozess

Kunden-Management

Prozess ... Service ‚Kunde aufnehmen/mutieren‘

9

SOA: Prinzip Standardisierung

Individualisierung versus Standardisierung

Standard-Service Merkmal

Hoher Reuse (hoher Nutzungs-Entwicklungs Faktor) Vorteile

Hohe, anhaltende Qualität Best-of-Breed Tiefe Kosten

Nachteile Keine Individualität

Lösung: Optimale Aufteilung in Standard- und Individual-Services.

10

SOA: Individualität versus Standardisierung

1. Unterteilung der Services in Teil-Services (Teil-Teil Services, ...):

1. Bis ein Teil-Service 100% Standard oder 100% individuell.

2. Bis zu atomaren Services.

2. Auslagerung der Standard Teil-Services (Teil-Teil Services, ...)

3. Identifikation von gleichen Teil-Services

Nutzen:

Voraussetzung für Release-Management

11

SOA: Aufbau der Service-Orientierten Architektur

Individuell Standard

Reuse nein --- Auslagerung

ja Auslagerung Auslagerung

Aufbau der Service-Architektur

Mittels Auslagerung Identifikation von gleichen Services

Ziel:

Mächtige (viel Business Value) sich nicht überschneidende Services.

12

SOA & Workflow

Service-Auslagerungstruktur Durch die Auslagerung entsteht ein

Workflow. Orchestration von Services

Service-Hierarchie Ein Service wird unterteilt in Teil-

Services und ausgelagerten Services, die zusammen einen Workflow bilden.

Verkaufs-Prozess

Support-Prozess

Kunden-Management

Prozess

13

Zusammenfassung

Die Services sind die Bausteine der Verarbeitung. Sie liefern den Business Value.

Es gibt Individual- und Standard-Services.

Die Services haben diverse Granularitäten: Ebene Prozess

Ebene Task

Ebene Teil-Task (Teil-Teil-Task, ...)

Ebene atomare Services

Die Services bilden eine Service-Auslagerungstruktur.

Die Services bilden einen Workflow (Orchestration, Choreography).

Die Services bilden unter sich eine Service-Hierarchie. Aufgrund der Individuell-Standard Optimierung

SOA ist ein Prinzip zur Strukturierung der Services

Die Kriterien sind Redundanzfreiheit und Wiederverwendbarkeit

14

Inhalt


SOA: Prinzip





Merkmale

Vorteile

Nutzung

Plattformen

Die Roadmap

15

SOA & BPM

IT (C

od

e)

Library of atomic generic Services

CorporateProcess Model

(CPM)

Process Model(PM)

Task Model(TM)

Inte

gra

tion

Prototyping

Business Logic M

odeling

SOA und BPM sind untrennbar SOA ist eigentlich nur ein Strukturierungsprinzip von BPM

Der wesentliche Teil der Services ist rein modell-basiert ! Nur die atomaren Services sind code-basiert !

Wie viele Arten von atomaren, generischen Services werden benötigt ?

16

SOA & BPM

IT

(Code)

CorporateProcess Model

(CPM)

Process Model(PM)

Task Model(TM)

Integra-tion

Prototyping

Business Logic M

odeling

...

...

Library of atomic generic Services

Die Anzahl der atomaren, generischen Services ist klein Ca. 100 allgemeine, je nach Branche weitere

Code-Reduktion: Gegenüber konventioneller Software ergibt sich eine Reduktion um Zehnerpotenzen !

SOA bedeutet ‚Modell-basierte Software‘ !

17

SOA & BPM : BPEL

Beispiel BPEL (links)

Business Process Execution Language (BPEL) für Orchestration von Services XML-based language (description) für SOA Einige ? betreffend BPEL (see John Evdemon)

Prozessdarstellung (rechts)

TravelerProcess

Travel Service

AirlineProcess

AgentProcess

Airline Service

By John Evdemon, Architect MicrosoftCo-Chair, Oasis WS-BPEL Technical Committee

18

SOA & BPM: Case-Orientierung

Services liefern einen Business Value. Der Business Value besteht aus Daten (Informationen)

Daten bilden den Case (Prozess-Case, Task-Case, ...) Auch Work Item genannt Durch Klassenmodell beschrieben (BOM)

Der Case ist memory-resident Performance

Die Services kommunizieren untereinander über den Case. Rules basieren auf dem Case (data-driven).

DataBase

Process/TaskLayer

MemoryDataLayer

PersistantDB

Layer

Case

Entry

Service

Inputvariables

Outcomes

Outputvariables

Task Case

19

Inhalt


SOA: Prinzip





Merkmale

Vorteile

Nutzung

Plattformen

Die Roadmap

20

Model-Based (Model-Driven) Architecture

Business Prozess

Prozessunterstützende Software BPM-basierte Software getrieben

durch das Modell Plus eLearning, Knowledge

Management, Controling, Reporting

Administrative Software BPM-basierte Software getrieben

durch das Modell; verändert teilweise das Modell

BPM Software (BE Umgebung) BPM-basierte Software für das

‚Business Process Management‘ Methodische Kompetenz zur Prozess-

Optimierung Inkl. Project Management: Planing &

Controling des Projektes

Model-Based Programming MDSD ... Model-Driven Software

Development

Integriertes Geschäfts-ModellProcess-, Data-, Rule-, Concept-, Content-,

Interface-, Event- und Functional Model

Kunde,Angestellter,

ManagerAdministrator

BusinessEngineer

SoftwareEngineer

1 2 3

4

1

2

3

4

Auch ‚Model-Driven Architecture‘ (MDA) genannt. Die gesamte geschäftliche Logik liegt im Modell. Die Plattform umfasst Engines und atomare,

generische Services, die die geschäftliche Logik ausführbar machen.

21

Model-Based (Model-Driven) Architecture

Das Modell muss fähig sein, den gesamten ‚Business Logic Content‘ zu umfassen. Die diversen Arten von ‚Business Logic Content‘ müssen unterstützt werden:

Workflow Logic incl. Event-Logic Rule Logic (BRM) Business Object Logic (BOM) Business Content Logic User-Interface Logic Functional Logic Concept Logic – Ontology

Komplettes Modell – Wieso? Nur ein komplettes Modell ist direkt ausführbar. Ist Modell nicht komplett, dann können nur gewisse Typen von Anwendungen

erstellt werden. Der Business Engineer muss an allen Modellen gleichzeitig arbeiten können !

22

Inhalt


SOA: Prinzip





Merkmale

Vorteile

Nutzung

Plattformen

Die Roadmap

23

Enterprise Content

Der Enterprise Content umfasst: Die gesamte Logik, wie Prozesse manuell und automatisch (elektronisch)

durchgeführt werden. Workflow Logik Regel Logik (BRM) User-Interface Logik (WEB2.0) Funktionale Logik

Die Daten, die für die Bearbeitung benötigt werden und die bearbeitet werden.

Datenlogik (BOM) Die unstrukturierten Daten einer Unternehmung.

(Document) Content Logik Ontologie (Begriffliche Logik)

Also: Business Logik Daten Dokumente

24

ECM: Corporate Knowledge - Enterprise Content

Corporate Knowledge = Enterprise Content

Corporate Knowledge hat 2 Rollen: ‚Controling & driving‘ des Business Processing

CK = Business Logic: Business Logic Content (Competence) des BPM Modelles Beispiel: Die Business Prozess Logik, um Rechnungen zu prüfen.

‚Being processed‘ durch das Business Processing CK als Information Beispiel: Rechnungen, die geprüft werden

Corporate Knowledge in beiden Rollen Z.B. Business Rules, die gepflegt werden und die die Verarbeitung steuern.

Corporate

Knowledge

(CK)

(EC ... Enterprise Content)

Business Processing

CK as Competence

CK as Information

Dynamic Business Logic (Competence)

OperationalAgility

25

Inhalt


SOA: Prinzip





Merkmale

Vorteile

Nutzung

Plattformen

Die Roadmap

26

Moderne Software-Architektur

Kombination der Prinzipien: Service-Based Model-Driven Prozess-Oriented

Case-Orientiert / Data-Driven

Kombination der Schlagworte: SOA BPM MDA ECM BRM

ITEngineering

Dritt-Systeme

BPM2 Plattform

Integriertes Business Model:Process-, Data-, Rule-, Concept-, Content-,

Interface-, Event- und Functional ModelSoftwareEngineering

Software Services

Bibliothek von Aktivitäts-Typen

BusinessEngineering

Geschäft Administration

27

Inhalt


SOA: Prinzip





Merkmale

Vorteile

Nutzung

Plattformen

Die Roadmap

28

Vorteile

Erwartungen Geschäft Service-Based Model-Driven Process-Oriented

Hohe Geschäftsprozess-Unterstützung

Optimale Individualisierung

Umfassende und grosse Menge an Geschäftslogik (Geschäfts-Kompetenz)

Process-Compliance

Hohe FlexibilitätModularisierungOptimaler Reuse

Hoher modell-basierter Anteil

Process-Compliance

Hohe StabilitätReleasefähigkeitStandard-Services

Hoch reusable Code (atomare Services)

Tiefe Kosten Optimale Standardisierung

Effizienz in der Prozess-Optimierung

Process-Compliance

Business TransparenzPrototypingModel2Execution

Process-Compliance

Hohe PerformanzAtomare ServicesSOA/BPM Plattform

Horizontale IntegrationDaten memory-resident

Weitere Vorteile: Outsourcing-Option Migrations-Option aus Legacy

29

SOA / BPM als ‚Disruptive Technology‘

Alternative zu konventionell erstellten IT-Lösungen Gibt es heute noch Gründe für die Erstellung von konventionellen

Lösungen? Ersatz von konventionell erstellten IT-Lösungen

‚Cobol‘-Lösung nicht durch ‚Java‘-Lösung ersetzen! Weil: Die Probleme bleiben die gleichen oder werden noch grösser, weil

die Anforderungen wachsen. Erweiterung von konventionell erstellten IT-Lösungen. Migration von konventionell erstellten IT-Lösungen. Merge von konventionellen IT-Lösungen

Aufgrund von Firmenzusammenschlüssen und Neustrukturierungen. Es wird eine Prozess-Schicht über die redundanten Systeme gelegt.

BasisSystem x

Basis SystemLayer

BasisSystem y

ProcessLayer

30

Inhalt


SOA: Prinzip





Merkmale

Vorteile

Nutzung

Plattformen

Die Roadmap

31

Traditionelle Lösungen versus SOA Lösungen

IT verlangt einheitliche kompakte Plattform

Business verlangt prozess-orientierte, entkoppelt Struktur

BPM: beides Solutions entkoppelt Plattform kompakt

DB DB DB DB

BPM Platform IT

BusinessProcessModel




DBDB

SolutionCode

ITDB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

SolutionCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

SolutionCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

SolutionCode

IT-Platform

Insellösungen (stove pipes, silos)

32

Traditionelle Lösungen versus SOA Lösungen

Vertikale Systeme

werden ersetzt durch

Business ProcessModelle

+SOA / BPM Platform

DB DB DB DB

BPM Platform IT

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode

DB

IT

ApplicationCode





Range of Industries

Insellösungen (stove pipes, silos)

33

Migration

Mit SOA (BPM) kann eine risikolose Migration durchgeführt werden. Schrittweise

Kosteneffizient

ProcessLayer

BusinessServiceLayer

DataLayer

UserInterface

Layer

MainModuleLayer

BusinessFunction

Layer

DataLayer

Silo (Stove Pipe) Application Architecture SOA-Based (BPM-Based) Application Architecture

ServiceModuleLayer

Pragmatic, stepwise, riskless & economic way for migration !

No extraordinary investments, minimal risk !

Immediate Benefit for Business !

34

Migration: Ausgangssituation

UserInterface

Layer

MainModuleLayer

BusinessFunction

Layer

DataLayer

ServiceModuleLayer

35

Migration: Erste migrierte Business Prozesse

ProcessLayer


DataLayer

UserInterface

Layer

MainModuleLayer

BusinessFunction

Layer

DataLayer

ServiceModuleLayer

36

Migration: Weitere migrierte Business Prozesse

UserInterface

Layer

MainModuleLayer

BusinessFunction

Layer

DataLayer

ServiceModuleLayer

ProcessLayer


DataLayer

37

Migration: Elimination der ersten Silo Anwendungen

UserInterface

Layer

MainModuleLayer

BusinessFunction

Layer

DataLayer

ServiceModuleLayer

ProcessLayer


DataLayer

38

Migration: Die perfekte SOA/BPM Welt

ProcessLayer


DataLayer

39

Migration: Die perfekte SOA/BPM Welt

ProcessLayer


DataLayer

40

Szenarium: Outsourcing

Anforderungen Business Prozess Engineering Plattform Ausgerichtet auf den Business Engineer (nicht Software Engineer) Optimale Unterstützung des Prozess Management Zyklus

Requirement Management, Modellierung, Prototyping



Kunde,Angestellter,


BusinessEngineer

SoftwareEngineer

Anforderungen Unternehmen Inhouse Business Engineering

für Business Prozess Optimierung

Die geschäftliche Kompetenz muss im Hause bleiben !

Anforderungen Lösungen: Hohe administrative Flexibilität

41

Szenarium: Inhouse IT

Anforderungen Unternehmen Inhouse Business Engineering für

Business Prozess Optimierung Die geschäftliche Kompetenz muss

im Hause bleiben ! Innerhalb Informatik

Ausrichtung der Informatik auf neue Software Architektur

Enge Zusammenarbeit von Business und Software Engineering

Anforderungen Lösungen: Migration der bestehenden

Lösungen



Kunde,Angestellter,


BusinessEngineer

SoftwareEngineer

Anforderungen Business Prozess Engineering Plattform Optimale Unterstützung des Prozess Management Zyklus

Requirement Management, Modellierung, Prototyping Offene Plattform

IT muss die Plattform transparent haben (Sourcecode) Plattform für Software- und Business-Engineering

Migration zur modernen Software-Architektur

42

Inhalt


SOA: Prinzip





Merkmale

Vorteile

Nutzung

Plattformen

Die Roadmap

43

Arten von Plattformen

Art der Plattform:

Einsatz:Process-Modeling

EAIWorkflow Mgt

(BPM1.0)BPM2.0

Macro-Workflow +++ +++ +++ +++

Micro-Workflow -++ --- --- +++

Modell-Basiert: Vollständigkeit der modellierbaren Logik

--+ --+ --+ +++

Plattform-Funktionalität: Learning, Document Mgt, Project Mgt, Knowlegde Mgt, Performance Mgt

--- --- +++ +++

ECM --- --- -++ +++

SOA --+ +++ -++ +++

Model2Execution: Prozess Mgt Zyklus

--+ --+ --+ +++

Ziel / Aufgabe: ModellierungSystem-

Integration

System-Integration, Workflow

Neues Software

Paradigma

44

Positionierung im Markt

Plattform Ansatz Beurteilung

Typ BeispieleProcess

ModelingSOA MDA Bemerkung

Applicat.-

Integrat.

Voll-ständig. Modell

Code Replace-ment

Eignung Business Analyst

Bermerkung

Business Modeling

WebSpere BPMS (IBM), Oracle, Visio (MS), SAP, ...

(+)++ --- ---

Kombination von Modeling Tool und Development Plattform notwendig; Integration mittels BPEL

--- --+ --- +++

Gap zwischen Design und Implementation. Komplexere Prozesslösungen nur konventionell möglich.

Workflow(BPM 1.0)

Metastorm (e-Works), filenet, ultimus, ...

-++ -++ --+

Fokus auf der Koordination von bestehenden Anwendungen; kommen aus dem WFM und Document Management

-++ --+ --+ -++

Ist eine Erweiterung von konventionellen Lösungen. Komplexere Prozesslösungen nur konventionell möglich

EAI

Seebeyond, axway, biztalk, e2e, ...

--+ +++ --+

Fokus auf der Integration von bestehenden Anwendungen

+++ --+ --+ ---Komplexere Prozesslösungen nur konventionell möglich

BPM 2.0

Intalio, Pega-system, Savvion, abaXX, e-Serve BPM2

(+)++ +++ (+)++

Umfassende Erfüllung der Kriterien von BPM wie Koordination, ‚Executable Model‘ und ‚Code Replacement‘.

(+)++ (+)++ (+)++ (+)++

Kompletter Paradigma-Wechsel (disruptive technology). Komplexeste Prozesse können hoch automatisiert und autonomisiert werden bei wesentlich tieferen Kosten.Neu: Spezielle Plattform für Business Analyst

45

BPMS: BPMS 2006 Report

Bruce Silver Associates, The 2006 BPMS Report

46

Inhalt


SOA: Prinzip





Merkmale

Vorteile

Nutzung

Plattformen

Die Roadmap

47

Summary

SOA ist keine technologische Herausforderung

SOA ist eine Business Engineering Herausforderung

SOA bedeutet auch BPM, MDA, ECM, BRM Deren Kombination bildet die neue Software-Architektur

Paradigma-Wechsel, Disruptive Technology

Investieren Sie ins Business Engineering Gefordert im individuellen Teil

Kaufen des Standard Teil

Beziehen Sie die Plattform-Technologie Wenn Sie eine Inhouse IT haben

Die Plattform-Technologie muss offen sein (Source-Code)

48

SOA-Roadmap

Implementierung einer modernen Software-Architektur Erstellung einer Roadmap

Wie sieht die Software-Architektur heute aus? Welche Geschäftsprozesse sind Kernprozesse (individuell)? Wer: Kleines Team von massgebenden Personen inkl. externer Beratung

(der Aufwand ist gering; Tage) Aufstellen eines Business Engineering Team

Profil Projektleiter, die Geschäft kennen Aufbau Business Engineering Kompetenz

Evaluation Business Engineering Plattform (SOA, BPM) Outsourcing Partner

Durchführen der Migration Business Engineering getrieben; nicht IT-getrieben

Das Vorgehen bleibt prinzipiell das gleiche, ob grosse oder kleinere Organisation.

Anhang:

50

Diskussion

Welche Rolle spielt UML 2.0? Abhängigkeit von einer Plattform?

51

Model & Types of Application

Type of Solution

Logic UI Workflow DB ProcessingDocument Processing

Work-GroupCase

ManagementTransaction Processing

Knowledge Processing

UserInterface

+++++ +++++ ++++ +++++ +++++ +++++

Makro-Workflow

+++++ +++++ ++++ +++++ +++++ +++

Micro-Workflow

+++++ +++++ +++

BusinessRules

+++ +++ +++ +++++ +++++ +++++

BusinessObjects

+ +++++ +++++ +++

BusinessContent

+ +++++ +++++ ++++ +++++

Data Base+++ +++++ +++ +++ +++++ +++++ +++

Functional++ ++ ++ ++ +++ +++ +++

Ontology+++++ ++++ +++++

52

Choreography versus Orchestration

Choreography is concerned with interaction and conversation of Web Services, wherein languages, communication technologies, formal models along with techniques for operations like service compatibility determination or validity checking of conversation protocols is of interest. Orchestration is concerned with arrangement of several services to a more complex functionalities, wherein mainly service composition are of interest. Choreography and Orchestration with Web Services are considered as the enabling technologies of Web Service based process management.

Bei der Orchestrierung, gibt es jemanden - den Dirigenten - der den Orchestermitgliedern sagt, was sie zu tun haben und sicherstellt, dass der Takt eingehalten wird. Bei der Choreographie folgen die Tänzer einem definierten Plan - aber jeder unabhängig voneinander.

Die Definition ist gleichzeitig eine gute Gedächtnisstütze, da die Analogie perfekt zu den Begriffen passt. Eine weitere Definition von Paul Downey vergleicht Orchestration mit einer zentral gesteuerten Ampel, bzw. Choreography mit einem Kreisverkehr, wo jeder Teilnehmer Regeln folgt, denen zuvor zugestimmt wurde.

Der Unterschied zwischen den beiden Begriffen ist, und da sind sich die meisten Kommentatoren einig, jedoch eher akademischer Natur. Der Nutzen der Unterscheidung in der Praxis ist eher gering.

53

WEB-Services: Registry / Repository (UDDI.org)

Wikipedia: UDDI (Universal Description, Discovery and Integration) ist ein Begriff aus

der Computertechnik und bezeichnet einen Verzeichnisdienst, der die zentrale Rolle in einem Umfeld von dynamischen Web Services spielen soll.

Der Verzeichnisdienst besitzt eine SOAP-Schnittstelle. Er enthält Unternehmen, ihre Daten und ihre Services. Dabei kann man in UDDI zwischen drei Arten der Informationen unterscheiden: Den "White Pages", einer Art Telefonbuch, den "Yellow Pages", also die elektronische Entsprechung der gelben Seiten, und den "Green Pages". Die genaue Aufteilung mit samt der Daten, die den einzelnen Teilen entspringen werden, sind in folgender Liste ausgeführt:

White Pages Namensregister, sortiert nach Namen Auflistung der Anbieter mit allen Detailangaben Kontaktinformationen (Telefon, Telefax,...)

Yellow Pages Branchenverzeichnis Spezifische Suche gemäß verschiedener Taxonomien (Ort, Dienstart,...) Verweist auf White Pages Klassifiziert die Services anhand internationaler Standards wie UNSPSC

Green Pages Informationen über das Geschäftsmodell des Unternehmens Technische Details zu den angebotenen Web Services Auskunft über Geschäftsprozesse

Case Study: Swisscom IT Services AG

Health Prozesse anhand Leistungs-Management

Hans-Jürgen Gerdum, Swisscom IT Services AG, [email protected]

www.swisscom.com

Roland Bendelac, e-Serve AG,[email protected]

www.e-serve.ch

Case Study: Steria Schweiz AG

Beispiel Bank-Prozess

Thomas Rathmann, Steria Schweiz AG,[email protected]

www.steria.ch

Documents

SOA: Licht in den Begriffdschungel Donnerstag, 24. Mai, 9.15 bis 10.45