Anne Thomas Manes von der Burton Group hielt einen Vortag zum Thema „ The Reincarnation of SOA“. Dies weil sie letztes Jahr SOA tot geschrieben hat (http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html).
Heute sind Cloud, Applikationen für Smartphones, soziale Netzwerke und BPM Trends in der IT. Die technische Grundlage dieser Trends bildet SOA, da alle auf Services aufbauen. Somit wird SOA als Architektur Prinzip wichtig bleiben, doch der Technologiefokus wird in den Hintergrund gedrängt. Beispielsweise genügt es nicht, bestehende Applikationen mit Schnittstellen zu ergänzen (Technik), ohne sich über die Software- und Systemarchitektur Gedanken zu machen.
Für den SOA-Neustart schlägt sie fünf Punkte vor, welche man umsetzen sollte:
- Definieren von messbaren SOA Zielen und Grundsätzen
- Verstehen von SOA Prinzipien und Mustern
- Etablieren einer SOA Governance
- SOA auf Unternehmensebene anwenden
- SOA auf Projektebene anwenden
Weiter betonte sie, dass das J2EE in der zukünftigen modernen Welt nicht mehr funktionieren wird, sondern neue Architekturen mit loser Kopplung gefragt sind.
Dienstag, 22. Juni 2010
Freitag, 11. Juni 2010
[ipt] SOA Forum Part I
Am 9. Juni 2010 besuchte ich in Zürich das SOA Forum der [ipt]. In diesem Eintrag will ich über den Vortrag der Gartner Gruppe (Massimo Pezzini) zum Thema „Now that SOA is For Real, What do We Do with It?“ berichten.
Als Haupttreiber für SOA hat Massimo IT Kostenreduktion, das Bewältigen von plötzlichen und unerwarteten Änderungen und Geschäftsprozesseffizienz genannt. Weiter betont er, dass SOA ein Architekturkonzept und keine Technik ist. Dies wurde anhand der Gartner SOA Definition illustriert, welche das Ziel hat, dass die Schnittstelle die Geschäftslogik repräsentiert. Diese Architektur ist zusammen mit den Gartner SOA-Use-Patterns (Beschreibung) die Grundlage zur Effizienzsteigerung in der IT.
Weiter sind eine Planung, eine SOA-Governance und ein vorausschauendes Handeln notwendig. Besonders die Governance trägt wesentlich zu Erfolg einer SOA bei. So sind Richtlinien und Werkzeuge zum Arbeiten mit einer SOA zu definiert. Daraus ergibt sich unter anderem ein Werkzeugkasten mit Assets, welche wiederverwendet werden können. Die Auswirkungen dieser Assets sind die anfangs genannten SOA-Hauptreiber.
Eine wichtige Bremse für SOA ist der Payback. So beginnt dieser erst nach 12-24 Monaten, wodurch hohe Anfangsinvestitionen entstehen. Durch die bereits erwähnten Massnahmen lässt sich auch der Payback vermindern. Doch wer sich für eine SOA entscheidet, muss langfristig denken.
Die Gartner SOA-Design-Pattern lassen sich mit dem SOA-Maturity-Model vergleichen. So zeigen beide eine Evolution der SOA-Umgebung. Da nach Gartner SOA auf dem Weg zur Maturität ist, darf man gespannt sein, wie es sich weiterentwickelt und wie stark Standardisierungen dies unterstützen.
Als Haupttreiber für SOA hat Massimo IT Kostenreduktion, das Bewältigen von plötzlichen und unerwarteten Änderungen und Geschäftsprozesseffizienz genannt. Weiter betont er, dass SOA ein Architekturkonzept und keine Technik ist. Dies wurde anhand der Gartner SOA Definition illustriert, welche das Ziel hat, dass die Schnittstelle die Geschäftslogik repräsentiert. Diese Architektur ist zusammen mit den Gartner SOA-Use-Patterns (Beschreibung) die Grundlage zur Effizienzsteigerung in der IT.
Weiter sind eine Planung, eine SOA-Governance und ein vorausschauendes Handeln notwendig. Besonders die Governance trägt wesentlich zu Erfolg einer SOA bei. So sind Richtlinien und Werkzeuge zum Arbeiten mit einer SOA zu definiert. Daraus ergibt sich unter anderem ein Werkzeugkasten mit Assets, welche wiederverwendet werden können. Die Auswirkungen dieser Assets sind die anfangs genannten SOA-Hauptreiber.
Eine wichtige Bremse für SOA ist der Payback. So beginnt dieser erst nach 12-24 Monaten, wodurch hohe Anfangsinvestitionen entstehen. Durch die bereits erwähnten Massnahmen lässt sich auch der Payback vermindern. Doch wer sich für eine SOA entscheidet, muss langfristig denken.
Die Gartner SOA-Design-Pattern lassen sich mit dem SOA-Maturity-Model vergleichen. So zeigen beide eine Evolution der SOA-Umgebung. Da nach Gartner SOA auf dem Weg zur Maturität ist, darf man gespannt sein, wie es sich weiterentwickelt und wie stark Standardisierungen dies unterstützen.
Dienstag, 18. Mai 2010
Was ist Agiles Prozessmanagement (BPM)
In den letzten 4 Monaten habe ich meine Masterarbeit zum Thema "Agiles Prozessmanagement" geschrieben. Für einen BPM Newbie, wie mich, gab es viele neue Erkenntnisse. Unter anderem musste ich zuerst agiles BPM definieren. Mittels Expeteninterview habe ich folgenden Definiton erarbeitet:
Agiles BPM ist die schnelle Anpassungsfähigkeit des Prozessmanagements auf neue Gegebenheit und hat die Eigenschaften Flexibilität, Schnelligkeit, Schlankheit.
Es ist klar, dass diese Definiton nicht allgemeingültig ist. Sie müsste mit weiteren Untersuchungen überprüft werden. Desweiteren ist zu prüfen, welche Punkte aus dem agilen Manifest der Softwareentwicklung (http://agilemanifesto.org/) übernommen werden könnten.
Bereits in die Defintion eingeflossen ist "Responding to change over following a plan". Dieser Punkt wurde mit der schnellen Anpassungfähigkeit gleichgesetzt.
Die restlichen Punkte sind meines Erachtens nicht in die Definition von agilem BPM zu übernehmen. Denoch müssen sie beim Arbeiten mit aglilem BPM beachtet werden. Die Punkte "Individuals and interactions over processes and tools" und "Customer collaboration over contract negotiation" haben wesentlichen Einfluss auf eine service-orientierte Unternehmenskultur. Kontroverse ist "Working software over comprehensive documentation", denn meiner Meinung nach müssen die Änderungen dokumentiert werden, damit sie auch nachverfolgbar und überprüfbar sind. Dies ist für das Controlling entscheidend.
Agiles BPM ist die schnelle Anpassungsfähigkeit des Prozessmanagements auf neue Gegebenheit und hat die Eigenschaften Flexibilität, Schnelligkeit, Schlankheit.
Es ist klar, dass diese Definiton nicht allgemeingültig ist. Sie müsste mit weiteren Untersuchungen überprüft werden. Desweiteren ist zu prüfen, welche Punkte aus dem agilen Manifest der Softwareentwicklung (http://agilemanifesto.org/) übernommen werden könnten.
Bereits in die Defintion eingeflossen ist "Responding to change over following a plan". Dieser Punkt wurde mit der schnellen Anpassungfähigkeit gleichgesetzt.
Die restlichen Punkte sind meines Erachtens nicht in die Definition von agilem BPM zu übernehmen. Denoch müssen sie beim Arbeiten mit aglilem BPM beachtet werden. Die Punkte "Individuals and interactions over processes and tools" und "Customer collaboration over contract negotiation" haben wesentlichen Einfluss auf eine service-orientierte Unternehmenskultur. Kontroverse ist "Working software over comprehensive documentation", denn meiner Meinung nach müssen die Änderungen dokumentiert werden, damit sie auch nachverfolgbar und überprüfbar sind. Dies ist für das Controlling entscheidend.
Montag, 23. November 2009
BPM, BRM und SOA
Meine Masterarbeit zum Abschluss meines EMBA widmet sich dem Thema "Agiles Prozessmanagement" und somit unter anderen dem Themen "Business Prozess Management", "Business Rules Management" und "Service Oriented Architecture". Dazu habe ich ein interessanten White Paper von Dr. W. Martin gefunden, welches das Zusammenspiel dieser drei Themen gut beschreibt. Diese Paper kann hier heruntergeladen werden.
Montag, 9. November 2009
Zum Anfang übernehme ich den einzigen Beitrag meines alten Blogs :)
Seit ein paar Tagen beschäftige ich mich mit dem CMS Radiant. Viele neue Herausforderungen erwarten mich, darunter auch die Erstellung einer Navigation.
Basieren auf den Radiant HowTo's vom Radiant Wiki und http://radiantcms.org/blog/archives/200 ... p-or-menu/ habe ich meine erste Navigation gebaut.
Dabei habe ich ein Snippet ersellt, das sich wieder aufruft. Somit kann die Navigation rekursiv erstellt werden. Mit den Tags
Im Layout befindet sie der Aufruf zum Erstellen der Navigation:
Die Navigation stellt nun alle Unterseiten mit deren Kinder usw. der Root-Seite dar. Die Rootseite wird nicht dargestellt.
Seit ein paar Tagen beschäftige ich mich mit dem CMS Radiant. Viele neue Herausforderungen erwarten mich, darunter auch die Erstellung einer Navigation.
Basieren auf den Radiant HowTo's vom Radiant Wiki und http://radiantcms.org/blog/archives/200 ... p-or-menu/ habe ich meine erste Navigation gebaut.
Dabei habe ich ein Snippet ersellt, das sich wieder aufruft. Somit kann die Navigation rekursiv erstellt werden. Mit den Tags
<r:it_self> und <r:unless_self> wird verhindert, dass das aktive Element verlinkt wird. <r:if_ancestor_or_self> und </r:if_ancestor_or_self> stellt sicher, dass nur Elemente des geöffneten Astes dargestellt werden.<r:children:each>
<li>
<r:if_self>
<r:title />
</r:if_self>
<r:unless_self>
<a href="<r:url />"><r:title /></a>
</r:unless_self>
</li>
<r:if_children>
<r:if_ancestor_or_self>
<ul>
<r:snippet name="navigation" />
</ul>
</r:if_ancestor_or_self>
</r:if_children>
</r:children:each>
Im Layout befindet sie der Aufruf zum Erstellen der Navigation:
<r:find url="/">
<ul>
<r:snippet name="navigation" />
</ul>
</r:find>
<ul>
<r:snippet name="navigation" />
</ul>
</r:if_ancestor_or_self>
</r:if_children>
</r:children:each>
Die Navigation stellt nun alle Unterseiten mit deren Kinder usw. der Root-Seite dar. Die Rootseite wird nicht dargestellt.
Abonnieren
Kommentare (Atom)