2012 – Strøm C - Morten Skodbo - Modenhet i bruk av programstyring i norske o...
2012 – Strøm A - Øyvind Aassve - Teknologistyring - rammeverk og metode
1. Teknologistyring –
rammeverk og metodikk
Øyvind Aassve
Virksomhetsarkitekt
Oslo Universitetssykehus
Prosjekt 2012 10.oktober 2012
2. Roar – status på TOGAF i helse, resultater
virksomhetsanalyse.
Styring – COBIT, ITIL, prosjekt- og porteføljemetodikk.
Basert på hva? Sjekk med Arne. Slide 13
Slide 19, 47 – koble mot ITIL og PPM
Slide 134 – nyttige referanser.
3. Arkitektur (definisjoner)
Arkitektur:
” .. the structure of the components, their relationships and the
principles and guidelines governing their design and evolution over time” – Institute
of Electrical and Electronic Engineering (IEEE).
Virksomhetsarkitektur (Enterprise Architecture):
“… set of descriptive representations (i.e. models) that are relevant for describing
an Enterprise …” (John Zachman)
...prosess...
...for å omforme virksomhetens visjon og strategi...
...til effektiv virksomhetsendring...(hvis det ikke er behov for endring, er det heller
ikke behov for arkitektur)...
...ved å lage, kommunisere nøkkelkrav, prinsipper og modeller som beskriver
virksomhetens fremtidige tilstand og muliggjøre dens utvikling. (Gartner)
5. Scope
Implemented
Idea
Solution
Business Program/Project
IT Strategy Business Portefolio Applicatoin IT Operations
Strategy Managemnet
Process Management Development
Management
Enterprise Architecture
Håndtere overganger med gap og overlapp blir kritiske
suksessfaktorer
6. Kontekst for virksomhetsarkitektur
Definere strategi
Enterprise
Planning and
Strategy
Realisere endring gjennom Hvordan implementere gitt
prosjekter Enterprise strategi
Enterprise
Portfolio
Architecture
Management
7. Hvorfor virksomhetsarkitektur?
• Redskap for å optimalisere IT-investeringer i forhold til forretningsstrategi og
virksomhetsprosesser, for å sikre en mest mulig forretningsdrevet, helhetlig og langsiktig utvikling
av IT-porteføljen. Felles verktøy for virksomhet og IT for å levere endringer.
• Redskap for å oppnå riktig balanse mellom IT-effektivitet og innovasjon i virksomheten.
• Verktøy for å kommunisere overordnede mål, design og sammenhenger til ulike typer
interessenter til hjelp for at alle jobber i samme retning.
• Etablerer prinsipper, standarder og retningslinjer som forbedrer kvaliteten og sikrer konsistens og
samhandling mellom systemer på tvers av prosjekter og initiativer.
• Forenkler kontroll og oppfølging av prosjekter for å sikre samsvar med visjon og retningslinjer
• Økt levetid på systemer fordi systemene har større fleksibilitet og tilpasningsevne ved endring i
forretningsbehov.
•Beskrive arbeidsdeling mellom komponenter og applikasjoner.
• Øke gjenbruk av eksisterende komponenter.
8. Verktøy for å utarbeide arkitekur
Taksonomi/ klassifseringsrammeverk
for EA produkter -
eks. Zachman, TOGAF, Gartner.
Classification
Prosess for utvikling av Sektorarkitekturer inkl.
EA-produkter (TOGAF) Sector prinsipper og standarder -
Methodology ex. NIKT-rapport.
specific
9. Bruk av view i klassifiserings- Classifi-
cation
rammeverk
Sect
Method- or
ology speci
fic
Virksomhetsarkitektur er en meget kompleks konstruksjon – for
komplisert til å vises i en felles fremvisning.
Et ”view” viser en type elementer i et eget diagram ut fra
fokusområde til interessent.
Ex. fra bygningsarkitekter - egne tegninger for reisverk, elektrisk,
rørleggerarbeid, ventilasjon ++
10. Vanlige ”view”
Classifi-
cation
Sect
Method- or
ology speci
fic
• Forretningsarkitektur (inkludert strategi, organisasjon
,arbeidsprosesser)
• Informasjonsarkitektur
• System- /applikasjons-/ tjenestearkitektur
• Teknisk arkitektur
Hver av de ulike viewene har ulike abstraksjonsnivåer tilpasset
brukerrollen.
12. Classifi-
Klassifiseringsrammeverk: Gartner
Best Practice 2: Align Business, Information and cation
Technical Architectures Method-
Sect
or
ology speci
fic
Sample Architectural
Viewpoints and Artifacts
Life Cycle Stage Enterprise Enterprise Enterprise
Business Arch. Information Arch. Technical Arch.
• Process principles • Information principles • Service-level
• Organizational and standards requirements
Conceptual requirements • Integration policies • Software delivery
• Functional map principles
• Information flows
• Asset criticality
• Business process • Data models • Technical reference
models and design • Object/component model (unpopulated)
Analysis and • Organizational and models • Infrastructure design
Design business rules • Design guidelines, rules
patterns, frameworks
• Human-to-human • Data, software and user • Topologies and
workflows interface services networks
Implementation • Automated workflow • Master data stores • Enterprise server bus
orchestration and • Databases and and message
collaboration software solutions handling
GARTNER LEADER’S TOOLKIT 5
14. Metodikk: Classifi-
Classifica-
tioncation
Typiske hovedleveranser
Sect
Method- or
ology speci
fic
• Definere prinsipper, standarder og retningslinjer for å sikre en konsistent og helhetlig
IT-portefølje.
• Utarbeide en fremtidig målarkitektur (to be) som kan håndtere kravene og føringer fra
forretningsstrategi og andre eksterne faktorer.
• Kartlegge og dokumentere komponenter og relasjoner i eksisterende arkitektur (as is).
> men diversifisert portefølje og meget ressurskrevende. Bør være del av prosjekters
dokumentasjonsansvar.
• Utarbeide GAP-analyse som identifiserer sentrale avvik mellom nåsituasjonen og
målarkitekturen i forhold til å supportere forretningsstrategi og fremtidige krav.
• Veikart for å identifisere aktiviteter og prosjekter som bringer oss fra der vi er (as is) til
dit vi skal (to be). > hvor involvert i forhold til å foreslå prosjekter som først og fremst
har arkitekturmessig fokus. PA/SIKT bestemmer prosjekter.
• Forankre, forankre, forankre
15. Metodikk: TOGAF - ADM Classifi-
Classifica-
tioncation
Sect
Method- or
ology speci
fic
The TOGAF Architecture Development Method (ADM)
16. Sette scope, avgrensninger og forventninger for et TOGAF
prosjekt; lage arkitekturvisjonen; validere
forretningskontekst;lage Statement Of Architecture Work
(SAW)
Forberede organisasjonen på et vellykket arkitekturprosjekt
Utvikle forretningsarkitekturen
Utvikle nåsituasjon og målbilde arkitekturer
og analysere gap
Tilby kontinuerlig monitorering og en
endringshåndteringsprosess for å sikre at
arkitekturen responderer på behovene
fra forretningen
Utvikle arkitekturer for
informasjonssystemer
Utvikle nåsituasjon og målbilde
arkitekturer og analysere gap
Tilby arkitekturell oversikt i
implementeringen; sikre at
implementeringsprosjektet er ihht.
arkitekturen
Utvikle teknologiarkitektur
Utvikle nåsituasjon og målbilde
arkitekturer og analysere gap
Analysere kostnader, fordeler og
risiki; utvikle detaljert
implementerings- og migreringsplan
Utføre initiell implementerings
planlegging; identifisere de
Sikre at alle nivå og faser i TOGAF største/viktigste prosjektene
prosjektet er basert på og validerer
med forretningskravene
17. Metodikk: Classifi-
Classifica-
tioncation
Governancegrensesnitt og
Sect
Method- or
ology speci
fic
porteføljestyring
NIKT utarbeider metodikk for
• Hvordan skal prosjektene/forvaltning forholde seg til arkitekturen
• Hvordan identifisere behov for og gi innspill til oppdatering av arkitekturen
• Hvordan utarbeide/tilpasse regional/lokal arkitektur
Ex. grensesnittet mot prosjektmetodikk som står for faktisk implementering av arkitekturen.
• Tidlig stadium – identifisere konsekvenser. Evt tilslutning/ føringer.
• Designgjennomgang – sikre samsvar med arkitektur.
• Prosjektmetodikk – sikre implementasjonen er den samme som godkjent av arkitekturforum. Prosjekt
dokumenterer i verktøy i tråd med definerte retningslinjer for hva som skal dokumenteres og hvordan.
18. Økosystem av arkitekturer –
Classifi-
Classifica-
tioncation
Sect
or
føringer for offentlig sektor
Method-
ology speci
fic
Nasjonale føringer og internasjonale
forpliktelser – FAOS, CEN, HL7
Samhandling og felles
grenseflater innen helse –
NasjonalIKT–rapport.
Lokal arkitektur basert på
forretningskrav ved den
enkelte virksomhet
19. Overordnede arkitektur- Classifi-
Classifica-
tioncation
prinsipper for offentlig sektor
Sect
Method- or
ology speci
fic
DIFI – (Direktoratet for Forvaltning og IKT) - skal på et overordnet nivå
sørge for elektronisk samhandling i og med offentlig sektor.
• DIFI har etablert syv arkitekturprinsipper for å sikre at fremtidige IT-
løsninger passer sammen og kan benyttes i sammenheng.
• Prinsipper om tjenesteorientering og interoperabilitet – overgang fra
monolittisk til tjenestorientert arkitektur.
”Det er obligatorisk for statlige virksomheter å bruke prinsippene ved utvikling av
nye IT-løsninger eller ved vesentlige endringer av eksisterende løsninger. Dersom
det etter en helhetlig vurdering er klare ulemper eller utilsiktede konsekvenser ved
å følge enkelte av prinsippene i det konkrete prosjektet, kan de prinsippene det
gjelder fravikes. Fraviket må begrunnes.” - DIFI
20. Overordnet prinsipp: Classifi-
Classifica-
tioncation
Tjenesteorientert arkitektur (SOA) Method-
ology
Sect
or
speci
fic
Tjenesteorientert arkitektur: et konsept der applikasjoner og automatiske prosesser aksesserer
informasjonsressurser gjennom standard tjenestegrensesnitt, uten at det krever programmering
eller kunnskap om systemene på lavere nivå.
Tjenester reprsenterer allsidige, gjenbrukbare forretningsfunksjoner slik at man kan dele opp
komplekse forretningsprosesser til enkle adminstrerbare enheter.
Gartner – 5 prinsipper for SOA:
- modulære systemer – komplekse oppgaver løses ved å sette sammen et sett av små enkle
komponenter som kobles sammen.
- veldefinerte og dokumenterte grensesnitt mellom moduler
- distribuerbare tjenester – kan kjøres på ulike plattformer
- løst koblede tjenester
- gjenbruk av tjenester. Ulike konsumenter som deler noe funksjonalitet bruker felles tjenester.
21. Tjenesteorientert Classifi-
Classifica-
arkitektur (SOA) forts
tioncation
Sect
Method- or
ology speci
fic
Arbeidsfla
Arbeidsfla
te
Arbeidsflate
te
Arbeidsprosesser og
Arbeidsprosesser og
Arbeidsprosesser og orkestrering
orkestrering
orkestrering
Tjenestebuss
Tjenester Tjenester T T T T T T T T T
Funk
Funk
Funk
Funk
Funk
Funk
Applikasjon Applikasjon
Funk
Funk
Funk
22. Overordnet prinsipp:
Classifi-
Classifica-
tioncation
Sect
Interoperabilitet
Method- or
ology speci
fic
Organisatorisk Interoperablilitet
(modellere og koordinere forretningsprosesser, konsistens med
interne mål, gjøre tjenester lett tilgjenglige og brukervennlige)
Semantisk Interoperablilitet
(sikre presis mening og lik oppfattelse av betydning av
informasjon av begge parter)
Teknisk Interoperablilitet
(tekniske løsninger for å linke systemer – område for
WebServices og SOA)
23. Økosystem av arkitekturer – Classifi-
Classifica-
tioncation
føringer for helsesektoren Method-
ology
Sect
or
speci
fic
Nasjonale føringer og internasjonale
forpliktelser – FAOS, CEN, HL7
Samhandling og felles
grenseflater innen helse –
NasjonalIKT–rapport.
Lokal arkitektur basert på
forretningskrav ved den
enkelte virksomhet
24. Classifi-
Classifica-
Sektorarkitektur Helse:
tioncation
Sect
Method- or
NasjonalIKT – Rapport om tjeneste-
ology speci
fic
orientert arkitektur i spesialisthelsetjenesten
Styringsdokument fra 2008 som dekker helheten for prosesser,
tjenester,informasjonsstruktur, teknologi og standarder for
spesialisthelsetjenesten.
• Overordnede prinsipper og standarder
• Overordnede tjenestebeskrivelser/ ankermodell
• Overordnet informasjonsmodell
• Teknologi og informasjonssikkerhet
Lastes ned på:
http://www.nasjonalikt.no/Publikasjoner/Tjenesteorientert_arkitektur_i_spesialisthelsetjenesten_hovedrapport_full_v1_0e.pdf
25. Prinsipper fra Nasjonal IKT
• Helhetstenking heller enn suboptimalisering
• Interoperabilitet
• Forsvarlig tilgang til informasjon
• Fleksibilitet og endringsevne
• Leverandøruavhengighet
• Gjenbruk av informasjon gjennom tjenester
• Kontrollere teknologivariasjoner
• Kontrollere funksjonell redundans
• Horisontal og vertikal konsolidering
• Modne standarder og teknologier
26. Økosystem av arkitekturer –
Classifi-
Classifica-
tioncation
Sect
Oslo Universitetssykehus
Method- or
ology speci
fic
Nasjonale føringer og internasjonale
forpliktelser – FAOS, CEN, HL7
Samhandling og felles
grenseflater innen helse –
NasjonalIKT–rapport.
Lokal arkitektur basert på
forretningskrav ved den
enkelte virksomhet
27. Eksempel målbilde integrasjon OUS
System/ tjenester konspetuelt
Helsenett/
Helsenett/
Internett
Internett
(elektronisk info
(elektronisk info
til/fra andre HF+
til/fra andre HF+ Forskning/ kvalitetssikring
Adm og Ledelsesinfo +)
+)
Kliniske data
(tilgang all relevant kliniske (full tilgang alle avidentifiserte data
(tilgang adminstrative
funksjonalitet i ett grensesnitt) for forskning og kvalitetssikring)
systemer og rappotering)
Administrativ plattfrom Klinisk Integrasjonsplattform Forskningsplattfrom
Pasient Index
Fys. Variable
Pasient Index
Fys. Variable
Labsystemer
Labsystemer
planlegging
Multimedia/
planlegging
Multimedia/
RIS/ PACS
Forskning
RIS/ PACS
Forskning
Booking/
Kvalitets-
Booking/
systemer
Økonomi
Kvalitets-
Ressurs-
systemer
Økonomi
Ressurs-
Spesial-
Spesial-
Journal
(Kurve)
Journal
styring
(Kurve)
sikring
sikring
Lønn
bilder
Adm Klinisk
Lønn
Lønn
Lønn
datavare datavare
hus hus
28. Nyttige lenker
TOGAF versjon 9 online:
http://www.opengroup.org/architecture/togaf9-doc/arch/
NIKT FA WiKi:
http://helsewiki.freecode.no/wiki/index.php/Hovedside
SOA patterns:
http://www.soapatterns.org/default.php
Bra TOGAF introduksjon i 1-10 videoer på YouTube. Del 1 ligger her:
http://www.youtube.com/watch?v=3M4NKwoaLk4
31. Arkitekturvisjon (1 av 2)
• Arkitekturfunksjonen omfatter alle HF i regionen. Den er integrert i foretakenes og regionens
prosesser for program- og porteføljestyring og har etablert nødvendige kontaktpunkter mot
prosjektmetodikk. Compliance er obligatorisk og det er konsekvenser non-compliance. Det er
etablert klare avviksprosedyrer.
• Ledelsen har god forståelse for og støtter aktivt arkitekturarbeidet, og den samme forståelsen og
støtten er også innarbeidet i linjen. Arkitekturfunksjonen er innbakt i virksomhetsstrategien.
• Kliniske trender og teknologitrender er identifisert og forankret, og blir kontinuerlig gjennomgått
og oppdatert.
• Arkitekturkrav for alle arkitekturmessige views (forretning, informasjon, teknologi ++) er
dokumentert og linket til virksomhetsstrategien for å sikre at arkitekturen er drevet og prioriteres
på grunnlag av virksomhetsstrategien.
• Arkitekturprinsipper er definert for alle arkitekturviews og er linket til arkitekturkravene.
• Målarkitekturer for alle views er utarbeidet i tråd med relevante arkitekturprinsipper. De er
støttet av modeller av AS-IS arkitektur der det er utarbeidet og er nødvendig.
• GAP-analyser mellom mål- og AS-IS-arkitekturer er gjennomført og videreformidlet til relevante
strategiske- og porteføljestyringsfora.
32. Arkitekturvisjon (2 av 2)
• Arkitekturen er vel dokumentert og tilgjengelig for alle interessenter. Det finnes views
tilpasset behovene til ulike interessentgrupper.
• Arkitekturutviklingsprosessen følges og oppdateres i årlig gjennomganger. Arkitektur
er også integrert i teknologianskaffelsesprosessen.
• Arkitektursyklusene er optimalisert for å gi både kort- og langsiktige gevinster, og den
langsiktige strategiske arkitekturplanlegging er synkronisert med
virksomhetsstrategiene.
• Alle faste virksomhetsarkitekter er godt kurset, og opplæring for arkitekturforståelse i
bredere miljøer er gjennomført.
• Arkitekturverktøy er på plass for forvaltning av arkitekturprodukter, og brukes som
hub for å kommunisere arkitekturen med relevante interessenter.
• Det er etablert metrikker og rapportering som viser verdi og resultater av
virksomhetsarkitetkurarbeidet.
Hinweis der Redaktion
To definisjoner: The addition of the word "enterprise" extends the coverage of architecture to span both IT and the business realm - mission, value chain, business strategy, business functions and processes. The business-level part may or may not include the application of IT. Nye systemer skal baseres på eksisterende prinsipper og retningslinjer for samhandling/ koeksistens med eksisterende systemer. Hensikten med en slik plan er å bidra til at ulike IT-løsninger passer sammen og kan benyttes i sammenheng. Twenty years ago, a new field was born that soon came to be known as enterprise architecture . The field initially began to address two problems: System complexity —Organizations were spending more and more money building IT systems; and Poor business alignment —Organizations were finding it more and more difficult to keep those increasingly expensive IT systems aligned with business need. The bottom line: more cost, less value. These problems, first recognized 20 years ago, have today reached a crisis point. Enterprise Architecture is about understanding all of the different elements that go to make up the enterprise and how those elements interrelate A good definition of “enterprise” in this context is any collection of organizations that has a common set of goals/principles and/or single bottom line. In that sense, an enterprise can be a whole corporation, a division of a corporation, a government organization, a single department, or a network of geographically distant organizations linked together by common objectives A good definition of “elements” in this context is all the elements that enclose the areas of People, Processes, Business and Technology. In that sense, examples of elements are: strategies, business drivers, principles, stakeholders, units, locations, budgets, domains, functions, activities, processes, services, products, information, communications, applications, systems, infrastructure, etc.
Ikke som definert prosjekt med klar start og sluttdato. Konintuerlig prosess for å styre utviklingen av virksomheten og dens IT-systemer.
Føler du at mesteparten av IKT budsjettet går med til drift og vedlikehold? Føler du at enhver endring i eksisterende systemer blir uforholdsmessig dyr? Sliter du med at ingen lenger har oversikt over systemer, data og teknologi – at endringer får uforutsette konsekvenser? Er det slik at IKT er blitt en bremsekloss ifm. endring av virksomheten? Dersom du kan svare ja på noen av spørsmålene ovenfor, er det sannsynlig at du trenger å gjøre noe med virksomhetsarkitekturen din.
Systemarkitektur - Application software inventories and diagrams Interfaces between applications - that is: events, messages and data flows Intranet, Extranet, Internet, eCommerce, EDI links with parties within and outside of the organization - funksonalitet ex. Booking i PiMS, Albert og Ultragenda. Kobling mot forretning - Strategy maps, goals, corporate policies, Operating Model Functional decompositions (e.g. IDEF0, SADT), capabilities and organizational models Architecture – what part of the system has cross-system influence – has ramifications outside. Forretningsarkitektur: Baseres på forretningsstrategien og er et direkte grunnlag for alle videre arkitekturer. Formelle beskrivelser av organisasjon, viktigste aktiviteter og prosesser. Prosessene beskriver bedriftens verdiskapning. Clustrer forretningsaktiviteter i domener og ansvarsområder. Overordnede prosessbeskrivelser viser hvordan domenene jobber sammen for å nå organsiasjonens mål. Forretningsarktiekt – kjenne forholdet mellom ulike avdelinger. Systemarkitektur: applikasjoner, mellomvare og databaser, samling av funksjonalitet realisering av forretningprosesser og tjenester i en tjenesteorientert arkitektur brukergrensesnitt Informasjonsarkitektur: Felles begreper, kodeapparat og informasjonsmodeller Information Management – definere eierskap til informasjon og sikre konsistens, integritet og kvalitet på informasjon Informasjonsflyt – hvordan gjøres informasjon tilgjengelig for interesserte parter – både internt og eksternt. Prosess for design og bygging av IT maskinvare og infrastruktur for å skape skalerbare, åpne og feiltolerante løsninger: servere nettverk databaser og lagring back-up high availability og failoverløsning
EA – Binder alt sammen. Classification schema used to view tan organisation holistically. Tool for manageming and communicating the vast information needed to make broad decisions. The EA framework is a structure for EA modeling work. You need one, but it's value is limited — it's what you DO with it that matters. The advantage of the Zachman framework is that it is easy to understand, it addresses the enterprise as a whole, it is defined independently of tools or methodologies, and any issues can be mapped against it to understand where they fit. An important drawback is the large number of cells, which is an obstacle for the practical applicability of the framework. The Framework, as it applies to enterprises, is a logical structure for identifying and organizing the descriptive representations (models) that are important in the management of enterprises and to the development of the systems, both automated and manual, that comprise them Hva trengs for å gjøre noe nyttig, nå gevinster. Ikke gjøre totalt kartleggingsarbeid bare for å gjøre det. Arkitektur må ikke ende med å bli produksjon av døde dokumenter. Finne et sett av view som gir mening for oss. Vanligvis brukes subsett.
Hva er vår naturlige rolle her? AS-IS – forskjellig fra sykehus til sykehus og på noen områder meget ressurskrevende. Må få frem at dette tas frem i hjulet.
Viewed as an architectural process , TOGAF complements Zachman—which, recall, I categorized as an architectural taxonomy . Zachman tells you how to categorize your artifacts. TOGAF gives you a process for creating them. The final architecture might be good, bad, or indifferent. TOGAF merely describes how to generate an enterprise architecture, not necessarily how to generate a good enterprise architecture. Preliminaries: Prosjektmetodikk – Prosjektmetodikk – Klassifisering – Sektorspesifikke arkitekturer Archtectural repository – må tilgjengeliggjøres for at det skal være lett for prosjekter å finne føringer. Nasjonalt – Regionalt – Lokalt – Uavhengig Referansearkitektur – NIKT Implementation Governance – vedlig viktig - UTDYP
Prosjektfokus i TOGAF
Må definere prosesser med krav til compliance og avvikshåndtering NIKT utarbeider metodikk for hvordan prosjekter forholder seg til arkitektur. I tråd med TOGAF preliminary: Forhold prosjekter vs linje/governance Prosjektrepository
Langsiktiig og helhetlig utvikling – må sees i sammenheng med prinsipper ellers i offentlig sektor, samt på nasjonalt, regionalt og lokalt nivå innen sektorene.
DIFIs arktiekturprinsipper
Systems that are built to change is more valuable than systems that are build to last. In reality, systems that are built to change are the only ones that last.
Langsiktiig og helhetlig utvikling – må sees i sammenheng med prinsipper ellers i offentlig sektor, samt på nasjonalt, regionalt og lokalt nivå innen sektorene.
Prinsipper
Langsiktiig og helhetlig utvikling – må sees i sammenheng med prinsipper ellers i offentlig sektor, samt på nasjonalt, regionalt og lokalt nivå innen sektorene.
Tjenesteorientering og HL7 versjon 3 Regulerte grensesnitt mellom plattformer Føderert til regionale/ nasjonale fellestjenester