seminarium i helsingborg den 20/9 - 2007, kl 11:30 – 14:00

Seminarium i Helsingborg

Den 20/9 - 2007, kl 11:30 – 14:00

Per Björkegren, Patrik Eriksson & Jimmy Sterner

DYA

Förstudier,Analyser

Verksamhets-lösningar

Utveckling UTOM

ArkitekturVerksamhetslösningar

IT Gover nance

Ar kit ekt urVer ksamhetPr ocesser

Appl ikat ionerInf or mat ion

Inf r as t r ukt urTeknol ogi

Projektportfölj

Arkitektur-support

StrategiskDialog

UtvecklingINOM

Arkitektur

Transform

ation

2007-08-30 SOA for profit Sida 2

Detta föredrag..

� ..handlar om SOA i ett stort perspektiv

� SOA som strategi för en verksamhet

� Ett antal områden kommer att belysas Varför SOA, denna hype? Vad är essensen av SOA? Hur komma igång med SOA? Hur testa SOA? SOA Governance? Mognadsmodell för SOA


Utgångspunkten..

� Boken ”SOA for profit”

� Bokens tillkomst

� Min roll

� Erfarenheter från att skriva en bok


Först, Några definitioner


Trebuchet MS

Definition


SHOW ME THE MONEY!

Bokens kapitel 2


Service Oriented Architecture- är mycket!

SOA = Lösningsdesign

+ infrastruktur

+ sammanförande av IT och verksamhet

+ stödjande processer

BPEL, BPM, Verksamhetstjänster, Arkitektur

ESB, Realtid, virtualisering

Arkitekturprocesser, Governance, Innovation, …

Tjänster

+ Påverkan på: testning, säkerhet, förvaltningsprocess, projektmetodik, ..

+ nya sätt att göra affärer och bedriva verksamhet

Avgränsningar, Förändring, Omfokusering, ..

Enklare förvaltning

Enklare integration

Snabbare respons mot verksamhetsbehovEffektivare användning av IT

Nya affärsmöjligheter


Varför väljer organisationer SOA?

Strategiska överväganden, organisationens position förändras

En fråga om MÅSTE; SOA är enda alternativet för överlevnad

En kombination av gammal teknik och förändrade krav från

verksamheten


Drivkrafter bakom SOA-projekt

http://www.ibm.com/se/


Anledning till varför svenska företag investerar i SOA

� Ökad flexibilitet (76%)

� Mer verksamhetsorienterad IT-funktion (53%)

� Kortare tid till marknaden (28%)

� Lägre IT-kostnader (21%)

� Teknisk revolution (21%)

� Möjliggörande av SLA-baserad leverans (9%)

Källa: IT-barometern 2007


Observerade fördelar från SOA



Observerade fördelar från SOA-projekt (på svenska)

� Ökad flexibilitet

� Reducerad kostnad

� Reducerad risk

� Ökad inkomst

� Nya produkter

� Snabbare implementering av produkter

� Enklare regeluppfyllnad (compliance)

� Förbättrad genomsyn (transparency)


Ska man bry sig om SOA?

Beror på er specifika situation

Aktuella verksamhetsproblem

Aktuella utmaningar

Detta måste utredas, och bästa sättet är att formulera en SOA-vision


Modell för en SOA-vision

Det måste finnas ett

skäl

Det måste finnas en

struktur på plats innan

Vilka är fördelarna?

Speciellt för verksamheten

Vad är SOA för oss?

Vad är konsekvenserna?

Ur olika aspekter

VARFÖR? VAD kan vi tjäna?

HUR ska SOAUtformas?

VAD blir konsekvensen?

HUR går viTillväga?


Är du i verksamheten?

� Ställ följande frågor:

Hur kan IT bidra till verksamhetens mål? Vad kan SOA ge vår verksamhet? Kan SOA även bli en möjliggörare för vår

organisation? Vilka områden får mest nytta av SOA? Vad är risker och konsekvenser av en

SOA-introduktion?


Är du inom IT

� Ställ dig följande frågor:

Kan SOA bli en möjliggörare även för IT Vad är drivkrafterna för SOA? Vart börjar vi? När är lämpligast att börja? Vilka risker och konsekvenser finns?


Sammanfattning – Show me the money!

SOA är inget självändamål

SOA har en roll om, och bara om, nytta kan påvisas.NYTTA = PENGAR

Därför måste man börja med att ta fram en vision för SOA


The essence of SOA in

Seven easy concepts

Bokens kapitel 3


SOA är enkelt

SOA är sunt förnuft, smart tänkande,

och en smula önsketänkande

De grundläggande ideerna med SOA är enkla att förklara, även för

den som inte är familjär med IT


Uppfattningen om SOA, varierar

� Många företag på IT-arenan har utvecklat en egen definition som ofta är till fördel för de egna produkterna och tjänsterna

� De stora visionärerna som Gartner och Forrester, liksom experter som CBDI använder OLIKA modeller och terminologi

� Bland IT-folk har SOA blivit synonymt med ”att göra IT på rätt sätt”

� SOA beskriver ett nytt stadie i IT:s mognadsprocess Det är inget nytt, utan bygger på alla erfarenheter vi samlat på oss

under 40 år

Utmaningen är att själv samla tillräcklig kunskap för förstå

nyttan och vart man ska börja


Tiden är inne

Flera faktorer samspelar till den hype som

SOA blivit


Några generationers IT-arv i bagaget

- Komplexitet -


Produktleverantörerna gasar ..

Alla investerar stort i SOA!

Alla pratar SOA!

Alla ä bäst på SOA!

Kort sagt, teknikleverantörerna driver på, och det med en kraft som

sällan skådats ..

BAM, ESB, BPM, BPEL, .. och förvirrar!


http://tibco.com/default.jsp

http://www.sap.com/index.epx


Förändringstrycket på verksamheter ökar

Konkurrens från Konkurrens från lågkostnadsländerlågkostnadsländer Utökat EUUtökat EU Ökad EU-regleringÖkad EU-reglering 24-timmarsmyndigheten24-timmarsmyndigheten 11:e september11:e september Sarbanes-Oxley act Sarbanes-Oxley act Irak-kriget Irak-kriget Orkanen i södra SverigeOrkanen i södra Sverige Orkaner i USAOrkaner i USA Jordbävning i PakistanJordbävning i Pakistan FågelinfluensanFågelinfluensan .... ....

Tillväxt Kostnadsjakt Kvartalsekonomin Sammanslagningar/Förvärv Partnerskap/Allianser Delade funktioner Outsourcing Nya affärsmodeller .. ..

.. men vi lever i en värld av alltmer ökande instabilitet .. och förändring är ett alltmer påtvingat allmäntillstånd


Hokus pokus, SOA!

Någr a gener at ioner sIT-ar v i bagaget-Kompl exit et - Alla investerar stort i SOA!

Alla pratar SOA!

Alla ä bäst på SOA!

Kort sagt, teknikleverantörerna driver på, och det med en kraft som

sällan skådats ..

BAM, ESB, BPM, BPEL, .. och förvirrar!

För ändr ingst r ycket påver ksamhet er ökar

KonkurrensKonkurrens frfråånn llåågkostnadslgkostnadsläändernder UtUtöökatkat EUEU ÖÖkadkad EUEU--regleringreglering 2424--timmarsmyndighetentimmarsmyndigheten 11:e 11:e septemberseptember SarbanesSarbanes--Oxley act Oxley act IrakIrak--krigetkriget OrkanenOrkanen i i ssöödradra SverigeSverige OrkanerOrkaner i USAi USA J ordbJordbäävningvningi Pakistani Pakistan FFåågelinfluensangelinfluensan .... ....

Tillväxt Kostnadsjakt Kvartalsekonomin Sammanslagningar/Förvärv Partnerskap/Allianser Delade funktioner Outsourcing Nya affärsmodeller .. ..

.. men vi lever i en värld av alltmer ökande instabilitet

.. och förändring är ett alltmer påtvingat allmäntillstånd

SOOOAAAAH!


Dessa sju koncept sammanfattar essensen av SOA

1. Komponentifiera

2. Kom överens

3. Använd vad som redan finns

4. Från bygge till Infrastruktur

5. Underlätta förändring, förbättra kontinuerligt

6. Gör det som verksamheten behöver

7. Reagera på omgivningen


1. Komponentifiera

Att dela upp i självständiga komponenter är en fundamental

grund i SOA

Det är dessa komponenter som skapar flexibilitet, snabba lösningar

och kostnadseffektiva lösningar

MEN, det gäller inte bara teknik, utan i lika stor grad verksamhet


Vi komponentifierar teknik

Process-skikt

Tjänste-skikt

Applikations-skikt

Teknologi-skikt

Microsoft.NET

LinuxJ2EEIBMCICS

Ekonomi

HR

ERP CRM

katalog

LotusNotes

OrderKonto Anställd Kund AbstraktionFrikoppling

KopplautifrånProcessen

Infrastruktur

ApplikationerKomponenter


Komponenterna i tekniken finns på olika nivåer

Tjänste-realisering

Implementerings-tjänster

Verksamhets-baserade tjänster

Sammansattapplikation

AndraTjänste-

leverantörer

Sammansatta Verksamhetstjänster

Interna resurser

Tjänst Tjänst

Tjänst TjänstTjänstTjänst TjänstTjänst

Lägg order

Order-Hanterings-process

Kontrolleraaktuelltlagersaldo

HämtaLagersaldoi allalagersystem

LevereraLagersaldo


Vi komponentifierar även verksamheten

Process-skikt

Tjänste-skikt

Applikations-skikt

Teknologi-skikt

Microsoft.NET

LinuxJ2EEIBMCICS

Ekonomi

HR

ERP CRM

katalog

LotusNotes

OrderKonto Anställd Kund AbstraktionFrikoppling

KopplautifrånProcessen

Infrastruktur

ApplikationerKomponenter


Re-think your business!

För att få ut den förväntade effekten så behöver kan se verksamheten med nya glasögon

BillingClose

Delivery

OperationsPlanning

PaperProduction

PaperConverting

TransportManageme

nt

TransportOperations

WarehouseManageme

nt

SalesManageme

nt

OrderManageme

nt

OrderManageme

nt

WarehouseManageme

nt

TransportOperations

Domänmodell

Processer

Bokens kapitel 5

OrderManageme

nt

WarehouseManageme

nt

TransportOperations

PaperProduction

PaperConverting

WarehouseManageme

nt

TransportOperations

Processen för Lagerorder

Processen för Produktionsorder med distribution via lagerterminal


En tjänsteorienterad domän

Warehouse Management

GoodsIn

Move goods

Pack goods

StockInventory

GoodsOut

Repairgoods

Integration services

Receiveadvice

ReportGoods move

ReportGoods received

Cross-dock

Handlepallets

ReportInventory

RecieveInstruction

Physical goods InterfaceRoad Loading dock Raiload Loading dock

CapabilitiesTjänsteorienterad gränssnittFör standardiserad samverkan

Standardisering kan ske på olika sätt!Gränssnitt eller Applikation?


Komponentifiering behöver en referensmodell

Mobiledevices

InternalPortal

ExternalPortal

Information services


DocumentArchive

CommonFunctionality

DataWare-house

Secu

rity

serv

ices

Dire

cto

ry s

erv

ices

CustomersSuppliersPartners

Masterdata

Business processes

Communication

ExternalWeb site

Service personnelLogistics

B2B

Externalsystems

Adapters to business systems

Business rules

Business systems

Direct use


2. Kom överens!

Integration kräver att många aktörer måste vara överens!

SOA är en utvecklad form av integration!

För att lyckas måste komma överens om STANDARDS och hur

INTEGRATION ska realiseras som en del

av SOA


3. Använd vad som redan finns

Med SOA tar vi ett steg framåt och mer aktivt söker efter delar som gör samma sak, och som

kan implementeras som en del (komponent)

Mindre teknik att förvalta = mindre kostnadMindre teknik = enklare förändring (agilitet)

Komponenter får inte vara

för små

Det måste vara enkelt

att åter-använda


4. Från Bygge till Infrastruktur

Köpa produkt är bättre än att återanvända

Återanvända är bättre än att bygga nytt

Köpa tjänst är bättre än att köpa produkt


Återanvändning kan ske på olika nivåer

Legacyapplication

Legacyapplication

Business processes

Business services

Technical services

Technology layer

Processes can be reconfigured at will, reusingunderlying business services. Process steps can be supported by one or more services. Abusiness service can support one or more processes or process steps.

These services can be composed of technicalservices and cross-cutting concerns (such asSecurity services). A business service has clear business relevance and is understandableto business people.

The technical services can be the implementation of parts of a business service, or a service interface to an existing application.In reality, the technical services themselves can alsobe composed of other technical services. Thismeans there can be many layers of re-use.

Underneath all services there is still a layer ofhardware and infrastructural software such asapplication services and database servers. Withvirtualization, this dependence becomes increasinglyloose.


Omvänd Återanvändning – federala tjänster

OperationsUnit

OperationsUnit

OperationsUnit

OperationsUnit

SalesCompany

Quality management

Group Reporting

Forecasting & Master planning

Sales & Order management

Återanvändning kan även ske via styrning, att komponenter skapas för att de ska användas av alla.

I detta fall är återanvändningen en federal standardisering


För vissa domäner är köpa självklart

Warehouse Management

GoodsIn

Move goods

Pack goods

StockInventory

GoodsOut

Repairgoods


Receiveadvice

ReportGoods move

ReportGoods received

Cross-dock

Handlepallets

ReportInventory

RecieveInstruction

Physical goods InterfaceRoad Loading dock Raiload Loading dock

Lagersystem är inte differentierande, och världens bästa system finns på marknaden till

bra pris – MAO ”hôl i hôvve å kôpe”

Standardsystem


Det finns tjänster ”out there”

� Valutaberäkning

� Formatkonvertering

� Kreditkontroll

� Företagsinformation

� Personinformation

� Betaltjänster

� Kontrollfunktioner

� Applikationstjänster (SAAS) ..


Pro-aktiv destruktion

Utmaningen är dock hur man ska kunna särskilja sig i konkurrensen

med en uppsättning standardkomponenter

Skrota din egenutvecklade tjänster så fort något

likvärdigt finns på marknaden, vänta inte!


5. Underlätta förändring, förbättra kontinuerligt

Förändring är ett allmäntillstånd

Att förutspå framtiden är omöjligt

Att skapa förutsättning för snabba förändringar är en mycket stor

förväntan på SOADYNAMIK - FLEXIBILITET


6. Gör det som verksamheten behöver

Det måste dock skapas mekanismer för att detta ska bli av

SOA har blivit verktyget för att äntligen integrera Verksamhet och IT

Tidig dialog!!

Kvalitetssäkring mot ALLA typer av verksamhetskrav och förväntningar

Glöm inte arkitekturprinciper och policys!


7. Reagera på omgivningen

SOA är ”agility”, vilket innebär att man går över till en högre grad av

händelsestyrning

SOA lovar verksamhet i realtid


Reagera på omgivningen

Detta ställer mycket stora krav på förändring av arkitekturen

Batch >>

Event-driven

Hårt integrerat

>>Löst kopplat

Integrerade system

>>Sammasatta applikationer


Sammanfattning – 7 easy concepts

Dessa koncept tillsammans skapar en kraftfull arkitektur som kan adressera

många av de problem som upplevs idag

En organisation som anammat dessa dessa koncept kan så småningom

levera bästa tänkbara TCO och även förändra sin roll till att inspirera till

verksamhetsutveckling

SOA är inte enkelt, men att göra det på rätt sätt är en överlevnadsfråga


Govern’ or end up in

mess

Bokens kapitel 4


SOA med Governance

Initiative 1

Development QA Deployment Operations

Initiative 2

Initiative ...

Co

mp

lian

ce

Development policiesNew business processes

Operations policies

Service

Governance

SOA infrastructure

Applications

Enhetlighet, flexibilitet, tillgänglighet, återanvändning, ..

Compliant


SOA utan Governance

Initiative 1


Initiative 2

Initiative ...

No

co

mp

lian

ce

No development policiesNew business processes

No operations policies

Service

Governance

SOA infrastructure

Applications

The mess, or beginning of it!

Compliant


Initiative 1


Initiative 2

Initiative ...

Co

mp

lian

ce

Development policiesNew business processes

Operations policies

Service

Governance

SOA infrastructure

Applications

Om Utveckling och Förvaltning ses som två olika saker

Another way to The mess..

Compliant


Agile development = RISK!

En ny rörelse inom systemutvecklarsskrået

Om det släpps fritt utan governance så är vi tillbaka i den onda cirkeln

Att etablera arkitektur och governance är ett sätt att ta hand om riskerna

En annat sätt är att odla en kultur som premierar det som är rätt

Rätt SOA-ansats motverkar i sig risken


Att hålla ordning på tjänster är viktigt

Development

Projectportfolio

Serviceportfolio

Operations

Application/Infrastructure

portfolio

Återanvända

Skapa

Övervaka

Drifta


Tjänster behöver livscykelhantering


governance

Roller &ansvar

PolicysMekanismer

Tydligt ansvarMandat

Bra regelverk och standards

Mekanismer som får det att bli verklighet


SOA-Styrmekanismer, enligt Gartner

� Executive committe

� IT Council of business IT executives

� IT leadership committee

� Enterprise architecture committee

� Business/IT relationship managers

� Process teams with IT members

� Service-level agreements

� Chargeback arrangements


SOA-Organisatoriska enheter

� SOA Business Transformation Architecture Council

� SOA Technical Architecture Board

� Component Design and Development Centres

� Operations Centre


Så här ser det ofta ut....

?

?

?

??

?

Vision

TodaysSituation


.. Men vi vill detta ..

KändsituationUtgångsläge

Nästa

Nästa

NästaNästa

Nästa

SOA-Vision

Stegvis, i rätt riktning och under

kontroll


Nyckeln är att integrera arkitekturen med processerna som förändrar!

DYA

För-studier,Analyser

Verksamhets-lösningar

Utveckling OUT OFBOUND

Verksamhetslösningar

Governance

Arkitektur

ProcessOrganisation

ApplikationInformation

InfrastrukturTeknologi

Projektportfölj

Arkitektur-tjänster

StrategiskDialog

UtvecklingUNDER

Arkitektur

Principer,Policys, Regler,

Modeller,Mönster,

Dokumentation,Mallar


I T G o v e r n a n c e

Hitta en governance-modell som fungerar för soa

d-SOA

Pre-studies,Analysis

Delivery OUT OF BOUND

Project Portfolio

StrategicDialogue

IntegrationAnalysis

Prioritisation & Dispatch

Deliveries

Deliveryunder Project

ArchitectureSupport

A r c h i t e c t u r eBusinessProcesses

ApplicationsInformation

InfrastructureTechnology

Principles,Rules,

Models,Documentation,

Templates,Configurations

Business solutions

Delivery CenterDispatch Center

ArchitectureProduction

ArchitectureVisioning


En sak till..

Att mäta är viktigt

Vad är beviset på framgång, vilka

nyckeltal behövs?

Mognadsmodeller är en annan form av nyckeltalsmodell


Sammanfattning Governance

Etablera arkitektur!

Just Enough – Just in time!Tidig dialog!

Projektportföljhantering!

Kontrollera leveransprojekten!

Etablera arkitekturstyrning i designfasen!

Ordning och reda på tjänster!

Säkerställ mandat!

Etablera nödvändiga mekanismer!

Integrera processer och arkitektur!


How to prepare and

start

Bokens kapitel 8 & 9


Man kan inte göra allt på en gång

Den stora bilden är ganska tydlig, men att definera en strategi, en vägkarta, är

både svårt och förvillande

Man ser inte skogen för alla träd


Man kan inte göra allt på en gång

Dagens företagsledare, ofta brända av stora misslyckade projekt, accepterar

bara små ansatser

Som i många andra fall gäller att ansatsen måste skräddarsys

Man måste hitta balansen, och en långsiktigt bärande vision..

Å andra sidan, för små ansatser riskerar att cemetera SOA-initiativet till statusen “anekdotisk period”


Skapa en tjänsteorienterad verksamhet

Man måste kunna identifiera nuläget för att göra en plan

LÖSNINGEN; en MOGNADSMODELL som kan beskriva nuläget och peka ut nästa

steg ur den karta av områden som måste tas omhand för att lyckas med SOA

Man måste veta vilka områden som ska bedömas ur ett SOA-perspektiv

Man måste förstå vad nästa smarta steg är utifrån nuläget


Utifrån vår definition av SOA har följande nyckelområden definierats


Vi har också en mognadsmodell

Mer om detta senare..

.. som kan beskriva nuläget och peka ut nästa steg ur den karta av områden som måste tas omhand för att

lyckas med SOA


Vart startar man då?

Det finns 5GrundläggandeEntry-points enligt IBM!

NågonstansBrinner det!



Det är viktigt att hitta ”Loket”

Vart brinner det?

Finns det något projekt som kan driva?

Ofta är integration den mest tydliga och bästa startpunkten


IBM:s entry points

� People-centric Collaboration

Samverkan och samsyn. � Business process management

Optimering av processer. Göra processer mer dynamiska.

� Information as a service

Göra information mer tillgänglig. Förädla information� Connectivity

Koppla samman människor, information och processer� Reuse

Återanvändning. Säkerställa standardisering


Vad är startpunkten i Sverige

� Informationstillgänglighet

� Business Activity Monitoring

� Naturlig IT-strategi

� INTEGRATION

Tjänsteorienterad integration Etablering av governance


Ett snabbt sätt att hitta loket

SOA Potential Workshop (SPW)

Fokusintervjuer med ledning

Workshop med ledning

Dokumentation

IntervjuresultatVad är SOAMöjligheternas konstHur kan SOA hjälpa oss?NyttonalaysStrategisk analys


Sammanfattning

Ta reda på vart det brinner, dvs hitta rätt entry point

SOA Potential Workshop

Identifiera nuläget avseende mognadSOA Maturity Model

Analysera nyttan med SOASOA-Visionen


Safely reaching your

destination

Bokens kapitel 10


RISK: Resultatet uteblir

En strukturerad ansats avseende test är mycket viktigt

Många tjänster med beroenden

SOA är verksamhetsstrategiskt!

SOA innehåller många av allt

Många aktörer och intressenter

Nyttan kommer senare!

RISK: Ökad komplexitet


Fokusera på verksamheten

Verksamhetensdriven testhantering (BDTM)

Säkra hela kedjan från verksamhetskrav till skarp

användning

Verksamhetskrav är:Direkta – kopplat till lösningIndirekta – Strategi och arkitektur


Använd en testprocess

Anpassa detaljnivån

Säkra testflödet genom hela utvecklingsprocessen

Säkerställ koppling till Arkitektur

Testa bara det som behövs, utgå från riskanalys och verksamhetskrav

Definiera krav och risker tidigt och detaljera efterhand. Glöm inte

uppföljning en tid efter driftsättning

Integrera med Governance-modellen


Förbättra efterhand

Analysera och följ uppTMap-modellen som koncept

1. Test utgår från verksamhetskrav

2. Sättet att testa optimeras genom testmetod3. Sätt upp rätt kombination av organisation, verktyg och infrastruktur


Testmål / objekt-Kritiska framgångsfaktorer-Ändringar-Verksamhetskrav-Arkitekturkrav-Verksamhetsprocesser-etc

Business Driven Test Management (BDTM)

Riskanalys - Resultat

2. Strategi-Definiera testnivåer-Applicera testnivåer-Planera och kalkylera-Bestäm testtekniker

3. Testprocess-Definiera testfall-Genomför tester

ÄGARE

Resultat, Risker, Tid och Pengar


sammanfattning

Säkerställ att test löper genom hela processen

Keep it simple!Gör de tester som behövs

Från KONTROLL till DRIFT!

Lita på arkitekturstyrningen!

SOA utvecklingsmodell

-Peeling the onion-

SOA utvecklingsmodell är…

Ett sätt att mäta på vilken nivå ett företag befinner sig kring SOA ur ett holistiskt perspektiv.

Ett konkret sätt att få direkt feedback kring vilka områden man bör fokusera på för att nå nästa nivå i sitt arbete med SOA. Rätt fokus på rätt saker…

SOA utvecklingsmodell hur…

Modellen bygger på att samla in, konsolidera och analysera svaren på en mängd förutbestämda frågor och presentera dessa i en matris.

Detta kan faciliteras via intervjuer eller enkäter (papper eller online).

Ett holistiskt perspektiv - Process, Teknik, Människa

•Alla dessa tre tillsammans är möjliggörare för SOA•Modellen tar hänsyn till alla dessa tre perspektiv

Process

Människa Te

knik

SOA

The onion

Dessa tre perspektiv representeras i modellen av 20 nyckelområden inom SOA ?

PROCESS

TEKNIK

MÄNNISKAN

Vi vet bara var vi är om vi frågar…mätningen baseras på ett antal påståenden som besvaras med ja eller nej. Påståendena är kopplade till mognads aspekter av de 20 nyckelområdena.

Exempel: Påståenden under nyckelområde Technology and standards

A. Technology and standards for SOA are chosen at the moment a concrete problem arises.

B. In the field of it, standards and technologies for SOA have been carefully chosen on the basis of proof-of concepts

C. The choice of standards and technologies issues from a SOA-wide strategy.

D. New standards and technologies are continuously followed and implemented as a part of a SOA-wide strategy wherever useful.

Varje nyckelområde har sin utvecklingsväg.

Denna evolution representeras i modellen av A,B,C och i vissa fall D. Det finns en tydlig kravbild för varje nivås uppfyllnad.

Kravbild Nivå A: Technology and standards for SOA are chosen at the moment a concrete problem arises.Checkpoints:- Have basic choices been made with regard to certain SOA technologies and standards? Are there SOA standards available within the organization?

Kravbild Nivå B:In the field of IT, standards and technologies for SOA have been carefully chosen on the basis of proof-of concepts. Checkpoints:- Are choices regarding SOA technologies and standards only made when the technology or standard has been tested within the organization in question (via a proof-of concept, for example)?- Has the management of SOA standards been embedded in the organization?

Vårt exempel från förra bilden:

A. Technology and standards for SOA are chosen at the moment a B. concrete problem arises.

B. In the field of it, standards and technologies for SOA have been carefully chosen on the basis of proof-of concepts

C. The choice of standards and technologies issues from a SOA-wide strategy.

D. New standards and technologies are continuously followed and implemented as a part of a SOA-wide strategy wherever useful.

A>B>C>(D)

OM MAN SVARAT JA PÅ A,C OCH D SÅ BEFINNER MAN SIG PÅ A,MAN HAR JU INTE UPPFYLLT KRAVEN FÖR B (DÄRAV EVOLUTIONSMODELL)

De 13 stegen…

På modellens andra axel finns 13 utvecklingssteg för varje nyckelområde.

Nivå 0 räknas inte som ett utvecklingssteg utan som en startpunkt.

Dessa steg sträcker sig från:FRÅN:

Nivå 1

• Det finns en budget och tid tillgänglig för SOA initiativ

• Det finns en vision av JUST-NU arkitektur

• Ad-hoc teknologi väljs när det behövs

• Informationssäkerhet implementeras reaktivt.

• Det finns sparsamt med medvetenhet hos IT folket

• Det finns sparsamt med medvetenhet hos verksamhets folket.

TILLNivå 13

• Arkitektur kvalitetsprocessen är integrerad I organisationens kvalitetsprocess

• Service usage funding (service market place)Service användning

• Verksamhet och IT är komponentiserade och återanvändning är självklart.

• Verksamhet och IT arbetar tillsammans för att bygga och driftsätta affärsprocesser

• Löst kopplad verksamhet – Informations systems virtualisering

>>>>>>>>>>>>>>>>>2,3,4,5,6,7,8,9,10,11,12

SOA Utvecklingsmatrisen ?

Detta är vår grafiska vy av resultatet

Hur skall jag läsa matrisen ?

För att uppnå SOA-mognadsnivå 1 skall följande nyckelområde nått nivå A

Ett verkligt resultat…

This is when you should start to peel!!!

The onion - Revisited

•Med utvecklingsmodellens hjälp kan man styra riktningen och börja skala löken mot en SOA !

Process

Människa Te

knik

Utvecklingssteg 0

Utvecklingssteg 13

The onion

SOA

Utvecklingssteg 1. . . . . . . . . ..

Rörelsen mot SOA:Mognadsmodellen kan användas på olika sätt

I utbildningssyfte för att förstå innehåll och sekvens för de olika åtgärder som en SOA-ansats kommer att kräva.

Läs igenom hela modellen och undersök sekvensen av utvecklingsteg per område. Studera också hur de olika områdenas nivåer relaterar till varandra.

För att få insikt i de styrkor och svagheter som den aktuella verksamheten har.

Dom nyckelområden som får högre utfall än medel är styrkor och de områden som får ett lägre utfall är svagheter som kräver åtgärder i någon form.

Planering framåt.

Bestäm vad ni vill uppnå med SOA och klargör detta tydligt. Bestäm sedan vilket steg i modellen denna målbild motsvarar. Markera utgångsläget och målbilden. De olika kontrollnivåerna mellan utgångsläge och målbild blir gapet och därmed basen för aktiviteterna i planen. Sekvensen för aktiviteterna får man genom den turordning som de har i modellen.


Ten things to say to get fired


Tio saker man ska undvika

� Vi säger inte nåt till verksamheten!

� Tro mig! SOA är litet, SOA är enkelt!

� Vi behöver ingen processorientering!

� Vi kommer att bygga ett Babels torn!

� Låt oss fråga vår nye juniorarkitektet!

� Vi ändrar standarden istället!

� Med SOA kommer vi att sikta mot rörliga mål

� SOA? Bara låt alla 1000 blommor blomma!

� Låt oss göra SO utan A!

� Vi kommer att migrerera allt till SOA!


Sammanfattning

Det står utom all tvivel att SOA som koncept kan förbättra alla verksamheter

Sättet är dock ytterst indivuduellt

SOA-definitionen varierar, liksom vart man börjar ur ett verksamhetsperspektiv

SOA är inget ändamål i sig, det MÅSTE anpassas


Bestäm Er defintion av SOA!


Architecture Governance

Börja bygg SOA-apparaten!AM / Project / Transformation Portfolio

Business development

IT Transformation

EnterpriseArchitecture

BusinessOrganisation

ApplicationInformation

InfrastructureTechnology

StrategicDialogue

ConstructionUnder

Architecture

Analysis & Design

ConstructionOut of bound

Architecture

ArchitectureSupport

Prioritisation

ArchitectureVisioning

ArchitectureProduction


Använd mognadsmodellen för bygget!

seminarium i helsingborg den 20/9 - 2007, kl 11:30 – 14:00

Documents