Arkitektur för informationsbehandlingsområdet Gunnar Kartman IT akitekt 2010 01 18
Presentationen Arkitektur och arkitekturens huvudområden Grundupplägg och förväntade effekter Tjänster och processer Två sidor av samma mynt Information En av de viktigaste strategiska tillgångarna för kommunen Tjänsteorientering Effekter på arkitekturen Modell för arkitektur Organisation, roller och ansvar Arkitekturprocessen På gång i Karlstad Först ett spaningspass
Vad är arkitektur? Operahuset, Oslo Först ett spaningspass
Är arkitektur viktigt? The Winchester Mystery House, San Jose, CA 38 års byggtid från 1884 160 rum varav 6 kök och 40 sovrum 1257 fönster, 950 dörrar 147 byggnadsarbetare Inga ritningar, inga arkitekter och ingen dokumentation
Är arkitektur viktigt? Ingen vision Ingen strategi Inga principer eller riktlinjer Får man då förväntad leverans? Blir det lätt att ändra och integrera?
Hur definierar vi arkitektur? Arkitekturarbetet är starkt kopplat till strategiskt arbete och de mål som uttrycks på olika nivåer inom organisationen Arkitekturarbetet transformerar strategier till beskrivningar framtagna för något som vi avser att skapa Beskrivningarna ligger till grund för realisering av nya lösningar (det skapade) samt ändring av befintliga
Hur definierar vi arkitektur? En dynamisk arkitektur Hållbar Vision Destinationen, beskriven som en vision eller en målbild Nästa Nästa Karta och kompass (Beskrivningar) Nästa Nästa Aktuell arkitektur NULÄGE Nästa Känd situation Projektportföljen Orienteringsbanan Begränsad av arkitekturen, Främst principer/riktlinjer Källa: Sogeti / Per Björkegren 7
Egenskaper/mål Arkitekturen ska upplevas som ett effektivt verktyg för verksamhetens utveckling och vila på grundläggande principer/riktlinjer beslutade på högsta nivå Arkitekturen ska verka i linje med uppsatta mål / visioner, i en kontinuerlig process (proaktivitet) Arkitekturen involverar och tillvaratar olika intressenters perspektiv (vyer) och bidrar därför till samverkan Arkitekturen ska vara så organiserad och dimensionerad att den inte upplevs som en stoppkloss i utvecklingsarbetet Snabba lösningar tillåts bara man vet effekterna av dem!
Arkitekturens huvudområden
Realisering av arkitektur Arkitekturprinciper Realiseringsriktning Lösningar Referensarkitekturer Lösningsarkitekturer Implementationer A1 A A21 A2 Generell beskrivning V I T av hur man bygger ett hus: Det ska vara väggar, B A22 C C1 D D1 D12 E F1 F F2 F21 G G1 G12 golv och tak för att det ska bli ett hus... Planritning: Huset är disponerat så här, med de här funktionerna... Konstruktionsritning: Detaljer över hur man bygger... Uppförd (realiserad) byggnad
Några effekter av arkitekturarbetet Underlag för beslut i strategiska och taktiska frågor vilket möjliggör en aktiv ledning och styrning mot verksamhetens mål en bas för ständiga förbättringar och kvalitetsarbete Beskrivningar av samband (komplexitet), hantering av förväntningar Beskrivningar av strategiska förflyttningar som möjliggör maximalt hög genomströmning av ändringar med största möjliga kontroll och minsta möjliga risk Proaktivitet jämförbart med planprocessen i stadsbyggnadssammanhang Skalbarhet och återanvändbarhet Effektivitet
Arkitekturprinciper exempel
Arkitekturprinciper Förankrade Överordnade principer ska beslutas på högsta ledningsnivå. Övriga principer på lämpliga undernivåer (såfåsom möjligt) Begripliga Principernas grundsatser (uttryck, logisk grund, slutsats) ska lätt kunna förstås Robusta Principerna måste vara exakt formulerade för att kunna ge ett otvetydigt underlag för användning Kompletta och konsistenta Principerna bör täcka alla tänkbara situationer men får ändå inte vara motsägelsefulla Stabila Principerna ska vara stabila över tid men ändå tillåta ändrings och livscykelhantering Spårbara Principerna ska kunna härledas (arkitekturloggen)
Ramverk, modeller och standarder som vi arbetar med IT Service Management ITIL v.3, ISO/IEC 20000 Förvaltning AFS/pm3 Processer Karlstad kommuns processmodell Projekt Karlstad kommuns projektmodell Arkitektur TOGAF 9, OASIS SOA modell Tjänsteorientering OASIS SOA modell Interoperabilitet Nationellt ramverk för interoperabilitet (VERVA), European Interoperability Framework for Pan European Government Services (EU EIF 1.0 och EIF 2.0 Draft)
Tjänster och processer Två sidor av samma mynt
Kommunens uppdrag Kommunen ska ta tillvara gemensamma intressen för människorna som lever och arbetar i den En del är obligatoriskt enligt lag, medan annat är frivilligt I praktiken är kommunen en leverantör av tjänster riktade till fysiska och juridiska personer och det är här som mycket av attraktionskraften hus en kommun ligger Vi som arbetar med informationsbehandling ska leverera (IT) tjänster i linje med de behov som kommunens verksamheter har
Visionen Livskvalitet Karlstad 100 000 De fyra ledstjärnorna En attraktiv stad som växer En stad för alla Den goda gröna staden En kommun i gott skick
Huvudintressenter
Tjänster och processer tvåsidor av samma mynt Tjänst Medlet varmed en konsuments behov förs samman med en producents förmåga och åtagande att tillhandahålla avsett värde (nytta) Leverabler: Direkt tjänsteinnehåll ( nyttolast ), tillgänglighet, kapacitet och kontinuitet Avtalas ofta i Service Level Agreements SLA, och mäts av mot uppsatta mätetal (Service Level Targets) baserade på KPI:er (Key Performance Index) Process En serie aktiviteter som realiserar en tjänst Ska uppnå de prestanda som specificeras för tjänsten. Processeffektiviteten mäts enligt ovanstående Realiseras i instanser utifrån en processdefinition Tjänst Producent Nyttolast Underliggande processer/resurser (människor, system) Process Tillfört affärsvärde (nytta) Konsument
Tjänster och processer tvåsidor av samma mynt Affärsvärde (nytta) Realiseras hos konsumenten Utfallet beror inte bara på producenten utan kan även bero på konsumentens förmåga att ta emot resultatet eller att interagera med processen Kvalitet Om mätningar genomförs uppnås rätt kvalitet när avtalade mätetal faller in. Det blir lätt att avgöra om man övereller underpresterar Om inga mätningar genomförs uppnås kvalitet när kunden är nöjd men det är svårt att ha koll på hur man egentligen ligger till Tjänst Producent Nyttolast Underliggande processer/resurser (människor, system) Process Tillfört affärsvärde (nytta) Konsument
Några viktiga drivkrafter eförvaltning och Nationella IT strategin Driver behov av federerade lösningar där tjänster/ processer både ska erbjudas och integreras. Frågor om informationsägande och informationssäkerhet är viktiga parametrar som driver komplexitet. Exempel: e tjänster till medborgare, vårdprocessen, NPÖ m.fl. Konkurrensutsättning Enligt samma principer som ovan Molntjänster Är en variant på temat konkurrensutsättning, men kan också vara en intern företeelse
Information En av de viktigaste strategiska tillgångarna för kommunen
(e) tjänsteleveransmodellen Vem äger information? Var finns Master data? Hur förvaltar vi information (gemensamhetsaspekten)? Hur ser integrationslandskapet ut?
Ifederation och organisatorisk samverkan Integration av tjänster och processer istället för system Förmåga till interoperabilitet är avgörande Nationell Patientöversikt NPÖ är ett gott exempel på tillämpning Information Tjänsteorienteradintegration
Utmaningarna
Utmaningarna Allt mer komplexa e tjänster efterfrågas Integration av tjänster och processer sektorsövergripande och mellan organisationer (B2B), outsoucing/cloud computing där det är stor risk för att komplexiteten kommer att driva kostnader och skapa tröghet Hög tillgänglighet till e tjänster är en absolut nödvändighet (24x7x365) Höga informationssäkerhetskrav (BIF) och höga krav på driftsäkerhet
Utmaningarna Regelefterlevnad (Compliance) är ett måste Att vara i linje med säkerhetskraven i exempelvis patientdatalagen logga vad som hände, när det hände och vem som gjorde det? Följsamhet (Agility) är en överlevnadsfråga Förmågan att följsamt designa, införa, driftsätta och supporta ändrade eller nya e tjänster utifrån verksamheternas krav Det arkitekturella landskapet finns knappt beskrivet Det som inte har beskrivits kan inte heller ändras på ett säkert sätt Nytta i förhållande till kostnad måste påvisas Hur tar vi betalt på ett rättvist sätt, och är det värt pengarna det vi gör? Hur mäter vi och följer upp?
Bakom kulisserna
Tjänsteorientering Effekter på arkitekturen
! Tjänsteorienterade arkitekturer är den naturliga följden av ett tjänste och processorienterat förhållningssätt Källa: Oliver Widder
Vad är SOA (Service Oriented Architecture)? En tjänsteorienterad arkitektur skall både ses som ett affärsmässigt synsätt och ett tekniskt förhållningssätt med metodologier för respektive område SOA är ett tankesystem för att dra nytta av distribuerade resurser som kan vara kontrollerade av olika ägare SOA är en del av den totala arkitekturen och är en angelägenhet för både verksamhet och IT (orkestrering) Källa: Oliver Widder
Riktig SOA följer affärsmålen på ett flexibelt sätt, dvs minimerar Time to Market ger möjlighet att anpassa sig till oväntade förändringar omfattar endast till en viss del teknologi, resten är mjuka värden ger förutsättningar för återanvändbarhet och automatisering ger förutsättningar för enhetlig loggning och spårbarhet föreskriver löst sammansatta integrationer men hanterar även Legacy system har ett övergripande repository för publicering av tjänster Källa: Oliver Widder
Tjänsteorientering enligt OASIS SOA modell Synlighet (Visibility) Utförande Sammanhang (Execution context) Tjänstebeskrivning (Service Description) Tjänst (Service) Verklig effekt (Real world effect) Samverkan (Interaction) Avtal & policy (Contract & Policy)
Strategin för att lyckas Tjänsteorientering Ända från slutanvändaren ned till den tekniska infrastrukturen ett kraftfullt sätt att bli effektivare, men också ett paradigmskifte Processorientering Verksamhet och IT samverkar i användning, utveckling, förvaltning, drift och support av tjänster Samverkan Erfarenhetsutbyte och gemensamma projekt över sektors och organisationsgränser. Särlösningar ska i möjligaste mån undvikas Interoperabilitet / standardisering Vi ska anstränga oss att undvika inlåsningseffekter
Interoperabilitet / standardisering Legal / rättslig interoperabilitet Det ska finnas lagrum för det vi utvecklar Organisatorisk interoperabilitet Processer och funktioner inom och mellan organisationer ska fungera tillsammans utan organisatoriska hinder som skillnader i synsätt, kultur m.m Semantisk interoperabilitet Uttryck och begrepp ska fungera mellan olika system och över sektorgränser Teknisk interoperabilitet Olika komponenter i IT infrastrukturen ska fungera tillsammans och med en dynamik som säkerställer utbytbarhet
...interoperabilitet... Arkitektur...IT-tjänster......processer... Sambanden
Holistisk verksamhetsutveckling med stöd av IT Tekniskt initiativ Verksamhetens initiativ BPM och BPA Återanvändbara tjänster Metoder Enterprise Service Bus (ESB) BPA = Business Process Automation BPM = Business Process Modeling Källa: Enfo Zystems
Tjänstekataloger på olika nivåer e Services Business Service Catalogue Technical Service Catalogue SOA Repository
Genväg till SOA? Källa: Oliver Widder
Modell för arkitektur Organisation, roller och ansvar
Modell för tjänstebaserad arkitektur Realiseringsriktning
Roller och ansvar Affär och strategi Affärsarkitekt Värdenätverk Affärsmodell Verksamhetsarkitekt Information Arkitekturledning (Styrgrupp IT) Tjänster och processer Applikation/ System Teknologi IT arkitekt EA arkitekt Infrastruktur Tekniska tjänster Observera att arkitekturorganisationen är ett stöd till ledningen på olika nivåer och ingen parallell ledningsstruktur. Den syftar endast till att få arkitekturprocessen att fungera på ett optimalt sätt
Arkitekturprocessen
Arkitekturprocessen IT styrning genom strategier, principer, regler m.m. Inledning G. Styrning och ledning av införande H. Ändringshantering av arkitektur F. Migrationsplanering A. Vision för arkitekturen Hantering av behov och förväntningar E. Möjligheter och lösningar B. Verksamhetsarkitektur D Teknisk arkitektur C. Informationsarkitektur Arkitektur bedrivs i processform Arkitekturprocessen I den mån arkitektur saknas eller behöver förändras utgår man från nuläget (Baseline) och rör sig mot målet (Taget). Vad som ska göras identifieras i en Gap analys
Tillämpning av arkitektur Citat ur kommunens anvisning för hur byggnader får förändras: ska ändringar ändå utföras med varsamhet och med hänsyn till byggnadens tidstypiska eller kulturhistoriska karaktär. I en komplex värld måste vi ha planer och planbestämmelser att utgå från när vi förändrar
Tillämpning av arkitektur Säkra förändringar i en komplex värld Bygger man inte in byråkrati och seghet? Balans
På gång i Karlstad
Högt på agendan Modell, utbildning och verktyg för att beskriva och köra processer En strategi för arkitekturarbetet som kan börja verka i en första version Kartlägga centrala delar av informationslandskapet Komplettera SOA referensarkitektur med ärendespindel och portal (infrastruktur för ytintegration) Ta fram tjänsten Kvalitetsäkrad personinformation. Den kommer bl.a att adressera frågan om samförvaltning av information Fåut komplexitetsdata från SOA in i SLM/SLA
Visionen vad vi siktar på Medborgare Kommungemensamma tjänster Tjänstebegäran Verksamhet X Verksamhet Y e tjänst Anställd Portal Presentationslager, kommunikationskanaler Processplattform (BPMS) Integrationsplattform (ESB) Sammansatta systemtjänster Autentisering Åtkomst Tjänst Tjänst Integrationsplattform (ESB) Systemtjänster Tjänst Tjänst Tjänst Tjänst System PKI tjänst Katalogtjänst Verksamhetssystem A Verksamhetssystem B
Exempel på tjänsteorienterad arkitektur Integrationsplattform och ITSM
Två integrationsområden möts Applikationsintegration Katalogintegration ESB/SOA
Plattformar för processer och tjänsteintegration Extens ecompanion Aveksa ADM Access BPM (Business Process Management) ESB (Enterprise Service Bus) BAM (Business Activity Monitoring) Avisering Avisering Avisering RES Metakatalog Avisering EDU Access PU DB Navet HSA
SOA referensarkitektur Infrastrukturmodell Service Development Modeling Construction Deployment Security Services Authentication, authorization, encryption & integrity Process Choreography Services Business process orchestration Human task interaction Business rules Business to Business (B2B) Services Partner management B2B message management Service Monitoring & Management Monitoring Logging Auditing Management Statistics & accounting Transformation Routing Conversion Connectivity Enterprise Service Bus (ESB) Service Registry Describe Publish Discover Collaboration Services End User interaction Application (direct connection) Business logic Service Enabler Adaption to ESB User Application (interfaced) Business logic
SOA referensarkitektur Integrations och processdomäner Governance A strive to consolidate Enterprise <Karlstads kommun municipality> Enterprise level Domain <Department 1> Domain <Department..n> Business domain level Application <..n> Application Domain <..n> Application Domain <..n> Application level Application <..n> Application <..n> Application <..n> Application <..n>
SOA implementation Fas 1, november 2009 Open Source
Exempel integrationspolicy Alla integrationsbehov ska passera Change Management för analys och prioritering enligt gängse regler för ändringshantering Inga integrationer får implementeras i strid med SOA referensarkitektur Policy är tillämplig från EA nivå (koncernen Karlstads kommun och samtliga externa kunder) och organisatioriskt nedåt
Exempel guidelines Concept model Integration An Integration is the exchange of one data entity (e.g., order or customer) between at least one Consumer and one Provider using at least one Service An Integration will define one or more Contracts that each uses one of the Services of the Integration
Exempel guidelines Concept model Service The means by which the needs of a consumer are brought together with the capabilities of a provider A Service accepts and/or returns information A Service is expressed in terms of one or more Endpoints and one or more Messages A Service can be classified for different types of use cases A typical example of such a classification is to distinguish between a public and a private Service. A public Service would be accessible for any consumer while a private would be a dedicated Service for that (or a small set of) consumer(s)
Exempel guidelines Concept model Contract A Contract defines how a specific Consumer accesses a Service, and what regulations apply, such as availability, volumes, frequency, and security
Exempel guidelines Service classifications Why? In an ESB, many kinds of services may be present. In order to be able to apply relevant design criteria to a specific service, it is useful to categorize services Baseline currently classifies services as either Public or Private
Exempel guidelines Service classifications four levels of services from right to left 1. Method calls. These are language dependent calls to functionality in the systems that perform the actual work. Note that many tools will allow this kind of method to be exposed as a Web service. This, in itself, does not qualify it as a Public service 2. Entry points to back end systems. These services may or may not be exposed as callable services. A service of this kind is implemented as any mechanism that triggers the back end system to perform a task, including file import, communication table triggering etc. From Baseline's point of view, we can identify and name any such interface between the Integration Platform and a Provider as a Service 3. To qualify as a Public Service, a number of criteria should be met, elaborated in the pattern Public service 4. An orchestrated process could also be considered exposing its entry point as a Public Service A Private service is any service that doesn't qualify as a Public service
Exempel guidelines Public Services What defines Public Services? WHY? In order to fulfill the promises of SOA, services need to be designed with reusability as an overriding design goal. To achieve reusability, a number of criteria (defined in this pattern) need to be met. A Public Service should have the following characteristics: Coarse grained * Business oriented The service should be designed and delimited according to a distinct business activity, rather than a grouping of functionality motivated by technical considerations. * Real world effect Invoking a Public Service will always result in something happening in the business, be it money exchanging owners, goods being removed from a warehouse, a mail being sent somewhere. * Single call In order to minimize network latency a Public Service fulfills its real world effect with a single call. * Abstraction of implementation The Consumer is completely shielded from all implementation details of the service. * Facade A Public Service will often act as a facade, fulfilling its task by making calls to several other Public and/or Private Services (Composite Service) * Canonical Data Object A Public service should be defined using Canonical Data Objects. Autonomous * Stateless Since a Public Service completes its task in a Single call (see above), it follows that it is stateless, i.e., the Consumer will not need to keep state between calls to the Service. * No side effects Several Consumers calling the service simultaneously should not experience any interference from each others calls. Versioned * Backward compatibility Public Services need to be able to handle Consumers expecting different versions of the service. This can be achieved by versioned Canonical Data Objects, versioned end points, or a combination of both. * Forward extensibility Canonical Data Objects should be defined using extensible schemas to enable future functionality to be introduced with minimal impact on existing Consumers. Published * Documented The interface of a Public Service should be fully documented according to some standard (e.g. WSDL) * Repository The specification of a Public Service should be retrievable by a human user using a searchable repository, enabling cross referencing of Integrations, Contracts, and Services.
IT Service Management / ISO 20000 Tjänsteportfölj Tjänstekatalog Tjänsteutveckling Marknadens möjligheter Kontinuerlig tjänsteförbättring Service Design Outsourcade tjänster Tjänstekoncept P Service Transition Service Operation Avslutade tjänster Kunder P F P Tjänsters livscykel Resursanvändning / återlämning Resurspool
Tack! Gunnar Kartman IT arkitekt gunnar.kartman@karlstad.se