Nachdem die fachlich relevanten Teile des Altsystems identifiziert wurden, stellt sich die Frage, wie diese am effizientesten in eine SOA transformiert werden können. Hierzu bietet sich ein modellgetriebener Ansatz wie die Model Driven Architecture (MDA) an. Sie ist ein geeignetes Werkzeug für die Modernisierung, da sie das automatische Mapping zwischen den Modellebenen unterstützt sowie Modelle auf Technologieplattformen wie beispielsweise GUI-Frameworks, Applikations-Server, Datenbanken und BPM-Engines abbilden kann. Dieses ist insbesondere wichtig, da sich so die semantische Interpretation der fachlichen Modellelemente in der SOA optimal steuern lässt. "MDA Architecture Blueprints" geben außerdem dem Entwickler genauere Vorgaben, schaffen Orientierungspunkte für Projekt-Manager und erhöhen das gemeinsame Verständnis aller Projektparteien.
Die Process-Oriented Architecture (POA) ist die letzte Ausbaustufe einer SOA. In einer POA werden Prozesse explizit modelliert. Sie werden damit besser kontrollier- und steuerbar. Dieser Ansatz erfordert eine frühe Einbindung der Fachabteilungen, um Modelle der vom Altsystem unterstützten Prozesse zu erhalten. Allerdings darf das Modernisierungsprojekt nicht zu weit gefasst sein. Besser ist es, zunächst die SOA-Transformation möglichst nahe am Originalsystem vorzunehmen und dann in weiteren Phasen die Vorteile von SOA/POA auszunutzen. Ist der erste Schritt getan, können die Geschäftsprozesse nachfolgend iterativ optimiert beziehungsweise neue Prozesse inkrementell hinzugefügt werden.
In der Regel braucht die Legacy-to-POA-Transformation einen höheren Abstraktionsgrad, als ihn die Unified Modeling Language (UML) bietet, die sich nicht für technisch wenig versierte Fachvertreter eignet. Diese bevorzugen vielmehr Prozessmodellierungswerkzeuge wie "Aris" oder "Adonis". Selbst Modelle, die mit Microsofts "Visio" erstellt wurden, können brauchbar sein. Der Bruch zwischen der technischen und der fachlichen Welt manifestiert sich zudem nicht nur in den unterschiedlichen Notationen, sondern häufig auch in der Perspektive. UML-Anwendungsmodelle beziehen sich meistens auf konkrete Systeme, während reine Prozessmodelle oft keine Annahme über zugrunde liegende Systeme machen. Der Legacy-to-POA-Ansatz sollte diesen Bruch zum Beispiel wie folgt adressieren:
Für die Modellierung auf hoher Abstraktionsebene, mit Ereignis-Prozessketten mit Aris;
das automatische Mapping auf technische Modellebene mit UML;
die Aufarbeitung der resultierenden Modelle durch technische Fachexperten;
die Auslegung verschiedener Modellsegmente auf die unterschiedlichen Schichten der SOA: GUI, BPMS, Rules Engine, Basisdienste etc.
