De av oss som har til oppgave å jobbe med emner på høyere nivå, For Eksempel Bedriftsarkitektur og Strategi, frykter når de blir spurt det enkle spørsmålet – » hva gjør du — «Når leveranser mangler tangibility og klarhet, gir svar på dette spørsmålet spørsmålet og nesten beklager respondenten. Et vanlig begrep kastet inn i svaret, som en plassholder for usikkerhet og ufullstendighet, er referansearkitektur.
dette begrepet kan bety mange ting eller noe for forskjellige mennesker. Hvis venstre udefinert, det gir inntrykk av fluffiness og fuzziness som avler frustrasjon og avfall. De som har til oppgave å implementere, kan stille spørsmål ved din evne til å skape konsepter og tenkning til virkelighet og konkrethet. Derfor er definisjoner nyttige. Her er min definisjon av en referansearkitektur:
artikulasjon av hensyn, alternativer og kjente standarder for å veilede utformingen av et produkt, en løsning eller et system, basert på observasjoner fra undersøkelser, erfaring og eksperimentering, i et språk og visuelt format kjent for målgruppen.
sannheten er at når hensikten, verdien og konteksten for bruken er gjort klar for et gitt publikum, har en formell definisjon ingen rolle.
det virkelige spørsmålet er—
«hva er det vi vil gjøre?»
For Det Andre—
«hva vil vi at folk (hvem de er) skal gjøre?»
å ha klare svar på disse spørsmålene er starten på å de-fuzzing betydningen og levering av referansearkitektur. Hensikten, innholdet, publikum og verdien må være tydelig. Ordet «referanse» antyder at utgangen gir veiledning og standarder fra observasjon, erfaring og eksperimentering, i motsetning til en definisjon av hva som skal bygges. En «arkitektur» antyder at den er strukturert, sammenhengende og verifiserbar.
det finnes ulike definisjoner av referansearkitektur på Internett, men ovennevnte klarhetsregel (hensikt, innhold, publikum, verdi) finnes i hver. Vurder en alternativ definisjon til min som kommer opp som toppresultatet i et google-søk:
(1) Klargjøre medium og format for hva som skal leveres, f. eks. «et dokument». Dette informerer verktøyene som kreves, arten av arbeidet som skal utføres og ferdighetssettet av bidragsytere som skal involveres. Alternative måter levering kan være en presentasjon eller spørring-stand kunnskapsbase.
(2) Bli Enige om strukturen og omfanget av hva som skal leveres, f. eks. «et sett med dokumenter». En leveranse kan være utilstrekkelig, men omfanget av systemdomenet under spørsmålet kan kreve at leveransen skal dekomponeres i flere dokumenter.
(3) Identifiser primærpublikum og interessent (e) f. eks. «prosjektleder». Ha en forståelse av typen og formatet av informasjon de regelmessig forbruker. Status quo kan også spille en rolle her. I noen tilfeller er referansearkitekturen «overlevert» rapporteringslinjene som policy, mens den i andre tilfeller behandles som en «hyggelig å ha», med forventning om at den beskriver den beste måten og alternativene som skal vurderes.
(4) Identifiser andre interesserte som kanskje må bruke referansearkitekturen. Er det nødvendig å lage forskjellige visninger eller lag? Er det behov for og plass til å trene andre på hvordan man skal tolke og anvende referansearkitekturen?
(5) Gjør det klart hva publikum / leseren skal gjøre med dokumentet, f. eks. «se for beste praksis.»Utgangene skal levere det de sier på forsiden, inkludert bevis og lenker til kilder for validering. En referansearkitektur kan også levere «læring» fra eksperimentering på en sammenhengende, praktisk måte.
(6) Gjør domenet av relevans klart. En referansearkitektur uten et bestemt domene er en filosofi om høyere veiledende prinsipper i stedet for en arkitektur. En arkitektur, selv en referansearkitektur, må være domenebundet. Jo mindre dette domenet er, desto mer relevant og handlekraftig er referansearkitekturen.
(7) referansearkitekturens tiltenkte verdi skal kommuniseres, da dette hjelper publikum til å bedømme formål og begrensninger, f. eks. » velg den beste leveringsmetoden.»Implementeringsteam vet da hvor de skal gå når denne beslutningen må gjøres.
(8) Å Ha eksempler fra domenet og angi relevante teknologier, bidrar til å avklare konteksten til referansearkitekturen.
(9) Alternativer og kilder til komponenter og evner som skal vurderes ved implementering, bør være godt dokumentert og koblet sammen.
en referansearkitektur er ikke nødvendigvis en blokkering før et teknologiprosjekt startes. Den kan utvikles parallelt eller etter levering, som fungerer som dokumentasjon av en postmortem og erfaringer. Hvis det er opprettet før et prosjekt starter, krever det undersøkelser, forsøk og eksperimenter for å informere god praksis. Nedenfor er en foreslått taksonomi av mulige klasser av referansearkitektur, avhengig av publikum, løsning og nåværende gap i kunnskap i en organisasjon eller prosjektteam.
akronymet for de fem ulike aspekter av en referanse arkitektur ER MUSIKK, som har vist seg å være minneverdig i samtaler på alle organisasjonsnivå eller domene forståelse:
- embership: oppføring og kategorisering av arkitekturelementer som anses som relevante for domenet.
- sage: brukerhistorier, business cases, prosesser, arbeidsflyter og metoder for å forklare aktiviteter i domenet.
- tructure: hvordan de ulike elementene i et domene er sammenkoblet for å støtte bruk.
- Nteraction (Eller Integrasjon): grensesnittene og meldingene som utveksles mellom arkitekturelementer under bruk.
- ontrols: begrensningene og retningslinjene som brukes til å styre interaksjoner.
Nå tyder Dette Ikke på at alle referansearkitekturer må levere 25 dokumenter eller underavsnitt, som dekker hvert av de identifiserte områdene. Dette illustrerer at det sannsynligvis er 25 forskjellige områder der hensyn, alternativer og ansvar må artikuleres i en organisasjon eller et prosjekt. Dette vil endres avhengig av publikum. Det er ingen fuzziness eller fluffiness i referansearkitekturer. De er et resultat av utforskende innsats og er de konkrete utgangene til nærtids anvendt forskning.