NIST-yritysarkkitehtuurimalli - NIST Enterprise Architecture Model

NIST-yritysarkkitehtuurimalli.

NIST Enterprise Architecture Model ( NIST EA Model ) on 1980-luvun lopussa referenssimallin varten kokonaisarkkitehtuuri . Se määrittelee yritysarkkitehtuurin yrityksen liike-, tieto- ja teknologiaympäristöjen keskinäisillä suhteilla.

Yhdysvaltain liittohallitus on kehittänyt 1980-luvun lopun National Institute of Standards and Technology (NIST) ja muut. Yhdysvaltojen liittohallitus edisti tätä viitemallia 1990-luvulla yksittäisten Yhdysvaltain valtion virastojen yritysarkkitehtuurien perustana ja koko liittovaltion yritysarkkitehtuurina. .

Johdanto

NIST- yritysarkkitehtuurimalli on viisikerroksinen yritysarkkitehtuurimalli , joka on suunniteltu integroitujen tieto- ja tietotekniikka-arkkitehtuurien järjestämiseen, suunnitteluun ja rakentamiseen. Viisi kerrosta on määritelty erikseen, mutta ne ovat yhteydessä toisiinsa. Malli määritteli keskinäisen suhteen seuraavasti:

Yritysarkkitehtuuri ohjaa tietorakennetta
Informaatioarkkitehtuuri määrää tietojärjestelmien arkkitehtuurin
Tietojärjestelmäarkkitehtuuri tunnistaa tietoarkkitehtuurin
Dataarkkitehtuuri ehdottaa erityisiä tiedonsiirtojärjestelmiä ja
Tiedonsiirtojärjestelmät (ohjelmistot, laitteistot, tietoliikenne) tukevat tietoarkkitehtuuria.

Mallin hierarkia perustuu käsitykseen, että organisaatiolla on useita liiketoimintatoimintoja, kukin toiminto vaatii tietoja useista lähteistä, ja jokainen näistä lähteistä voi käyttää yhtä tai useampaa käyttöjärjestelmää, jotka puolestaan sisältävät järjestettyjä ja järjestettyjä tietoja. tallennettu mihin tahansa määrään tietojärjestelmiä.

Historia

NIST-yritysarkkitehtuurimalli aloitettiin vuonna 1988 viidennessä tietohallinnon työpajassa, jonka NIST sponsoroi yhteistyössä tietokonekoneiden liiton (ACM), IEEE-tietokonejärjestön ja liittovaltion tiedonhallinnan käyttäjäryhmän (FEDMUG) kanssa. Tämän tutkimushankkeen tulokset julkaistiin nimellä NIST Special Publication 500-167, Information Management Directions: The Integration Challenge .

Uuden tietohallinnon ala

Kanssa leviämisen tietotekniikan alkaa vuonna 1970, jonka tehtävänä on tietohallinnon oli ottanut uudessa valossa, ja alkoi myös sisällyttää alan tietojen ylläpito . Tiedonhallinta ei enää ollut yksinkertainen työ, jonka melkein kuka tahansa voisi suorittaa. Ymmärtäminen mukana olevasta tekniikasta ja sen taustalla olevasta teoriasta tuli tarpeelliseksi. Kun tietojen tallennus siirtyi sähköisiin välineisiin, siitä tuli yhä vaikeampi.

Kolmen skeeman mallin käsite otettiin ensimmäisen kerran käyttöön vuonna 1975 ANSI / X3 / SPARC-kolmitasoisella arkkitehtuurilla , joka määritti mallin tiedoille kolme tasoa.

Yksi ensimmäisistä lähestymistavoista tietojärjestelmien rakentamiseen ja järjestelmien tietohallintoon 1970-luvulta lähtien oli kolmen mallin mukainen lähestymistapa . Se ehdottaa, että järjestelmäkehityksessä käytetään kolmea eri näkemystä , joissa käsitteellisen mallinnuksen katsotaan olevan avain tietojen integroimiseen :

Ulkoinen malli käyttäjien näkymille
Käsitteellinen skeema integroi ulkoiset kaaviot
Sisäinen skeema, joka määrittelee fyysiset tallennusrakenteet

Keskiössä käsitteellinen skeema määrittelee ontologian ja käsitteitä kuin käyttäjät ajatella niitä ja puhua niistä. Fyysinen skeema mukainen Sowan (2004) "kuvaa sisäistä muotoilut tiedot tallennetaan tietokantaan , ja ulkoinen Malli määrittää ottaen huomioon tiedot esitetään sovellusohjelmat ".

1970-luvulta lähtien NIST oli järjestänyt sarjan neljästä työpajasta tietokanta- ja tiedonhallintasuunnitelmista. Jokainen työpaja käsittelee tiettyä teemaa:

"Mitä tietoja tietokantateknologiasta johtajan on tehtävä varovaisten päätösten tekemiseksi uuden tekniikan käytöstä", vuonna 1975.
"Mitä tietoja voi auttaa johtajaa arvioimaan vaikutuksia tietokantajärjestelmään?" vuonna 1977.
" Tiedonhallintatyökalut seuraavien näkökulmasta: käyttötarkoitukset, käytännöt ja ohjaukset; looginen ja fyysinen tietokannan suunnittelu" vuonna 1980 ja
" Tietoresurssien hallinnan käytäntö ja ongelmat" vuonna 1985.

Viidennen työpajan vuonna 1989 piti NIST: n kansallinen tietojärjestelmälaboratorio (NCSL). Siihen mennessä tämä oli yksi neljästä instituutista, jotka suorittivat NIST: n teknisen työn. NCSL: n erityisenä tavoitteena oli tehdä tutkimusta ja tarjota tieteellisiä ja teknisiä palveluja liittovaltion virastojen auttamiseksi tietotekniikan valinnassa, hankinnassa, sovelluksessa ja käytössä.

NIST-työpaja tiedonhallinnan ohjeista

Vuonna 1989 viides tiedonhallintatyöpaja keskittyi integraatioon ja tuottavuuteen tiedonhallinnassa . Viisi työryhmää tarkasteli tietämyksen integrointia, tiedonhallintaa , järjestelmien suunnittelua, kehittämistä ja ylläpitoa, laskentaympäristöjä, arkkitehtuureja ja standardeja. Osallistujia tuli korkeakouluista, teollisuudesta, hallituksesta ja konsulttiyrityksistä. Niistä 72 osallistujat olivat Tom DeMarco , Ahmed K. Elmagarmid , Elizabeth N. Fong, Andrew U. Frank , Robert E. Fulton, Alan H. Goldfine, Dale L. Goodhue , Richard J. Mayer , Shamkant Navathe , T. William Olle , W. Bradford Rigdon , Judith A. Quillard, Stanley YW Su ja John Zachman .

Tom DeMarco piti pääpuheen väittäen, että standardit aiheuttavat enemmän haittaa kuin hyötyä, kun ne toimivat vallitsevan kulttuurin vastaisesti, ja että standardoinnin ydin on löytö, ei innovaatio. Viisi työryhmää kokoontuivat keskustelemaan integraation eri näkökohdista:

tiedon ja tiedonhallinnan integrointi
teknisen ja yritystietojen hallinnan integrointi
järjestelmien suunnittelu-, kehitys- ja ylläpitotyökalujen ja -menetelmien integrointi
- hajautettujen, heterogeenisten tietokoneympäristöjen integrointi ja -
arkkitehtuurit ja standardit.

Kolmannessa järjestelmäsuunnittelutyöryhmässä puheenjohtajana toimi John Zachman , ja se hyväksyi Zachman-puitteet keskustelun perustaksi.

Yritysarkkitehtuurin malli, 1989

Viidennen arkkitehtuuria ja standardeja käsittelevän työryhmän puheenjohtajana toimi W. Bradford Rigdon McDonnell Douglas Information Systems Companysta (MDISC), joka on McDonnell Douglasin osasto . Rigdon et ai. (1989) selitti, että arkkitehtuurikeskustelut tuolloin keskittyvät enimmäkseen teknologiaongelmiin. Heidän tavoitteensa oli "ottaa laajempi näkemys ja kuvata tarvetta yritysarkkitehtuurille , jossa korostetaan liike- ja tietovaatimuksia. Nämä korkeamman tason kysymykset vaikuttavat data- ja teknologiaarkkitehtuureihin ja päätöksiin". Tätä varten työryhmä käsitteli kolmea asiaa:

Yrityksen arkkitehtuuritasot
Arkkitehtuurin käsittelemät ongelmat
Arkkitehtuurin hyödyt ja riskit

Arkkitehtuurin tasojen havainnollistamiseksi esiteltiin NIST-yritysarkkitehtuurimalliksi kutsuttu nimi (katso kuva). Tässä konseptissa kolmen skeeman lähestymistavan kolme kerrosta on jaettu viiteen kerrokseen.

Soveltaminen 1990-luvulla

Tavallaan NIST-yritysarkkitehtuurimalli oli aikansa edellä. Zachmanin (1993) mukaan 1980-luvulla "arkkitehtuuri" tunnustettiin kiinnostavaksi aiheeksi, mutta konseptista oli vielä vähän konsolidoitua teoriaa. Esimerkiksi ohjelmistoarkkitehtuuri . tärkeä aihe vasta 1990-luvun jälkipuoliskolla.

NIST-yritysarkkitehtuurimallin tukemiseksi 1990-luvulla sitä mainostettiin laajalti Yhdysvaltain liittohallituksessa yritysarkkitehtuurin hallintatyökaluna. NIST-yritysarkkitehtuurimallia käytetään perustana useissa Yhdysvaltain liittovaltion valtion virastojen yritysarkkitehtuurikehyksissä ja yleisessä liittovaltion yritysarkkitehtuurikehyksessä . Tämän toiminnan koordinoimiseksi NIST-mallia selitettiin ja laajennettiin edelleen Yhdysvaltojen hallinto- ja budjettitoimiston vuonna 1997 julkaisemissa "Memoranda 97-16 (Information Technology Architectures)". Katso lisätietoja tietotekniikan arkkitehtuurista .

NIST-yritysarkkitehtuurimallin aiheet

Säätiöt

Rigdon et ai. (1989) arkkitehtuuri on "selkeä esitys komponenttien käsitteellisestä kehyksestä ja niiden suhteesta hetkessä". Se voi esimerkiksi edustaa "näkymää nykytilanteesta automatisointisaarien, turhien prosessien ja tietojen epäjohdonmukaisuuksien kanssa" tai "tulevaa integroitua automaatiotietorakennetta, johon yritys siirtyy määrätyn määrän vuosia." Standardien rooli arkkitehtuurissa on "sallia tai rajoittaa arkkitehtuuria ja toimia sen perustana".

Yritysarkkitehtuurin kehittämiseksi Rigdon tunnustaa:

On useita tapoja kehittää arkkitehtuuria
On olemassa useita tapoja toteuttaa standardeja
Kehitys ja toteutus tulisi räätälöidä ympäristöön
Jokainen arkkitehtuuri itsessään voidaan kuitenkin jakaa eri tasoille.

Yritysarkkitehtuurin eri tasot voidaan visualisoida pyramidina: Yrityksen liiketoimintayksikön päällä ja alareunassa yrityksen toimitusjärjestelmä. Yritys voi koostua yhdestä tai useammasta liiketoimintayksiköstä, jotka työskentelevät tietyllä liiketoiminta-alueella. Arkkitehtuurin viisi tasoa määritellään seuraavasti: liiketoimintayksikkö, tieto, tietojärjestelmä, data ja toimitusjärjestelmä.

Yritysarkkitehtuurin erilliset tasot liittyvät toisiinsa erityisellä tavalla. Jokaisella tasolla arkkitehtuurit omaksuvat tai sanelevat korkeamman tason arkkitehtuurit. Oikealla oleva kuva antaa esimerkin siitä, mitkä elementit voivat muodostaa yritysarkkitehtuurin.

Esimerkkejä yritysarkkitehtuurista (1989).

Arkkitehtuurin tasot

Jokaisella mallin kerroksella on oma tarkoitus:

Yritysarkkitehtuurin taso: Tämä taso voi kuvata minkä tahansa yrityksen tai sen alayksikön, joka on yhteydessä ulkoisiin organisaatioihin.
Informaatioarkkitehtuurin taso: Tällä tasolla määritetään vaadittavien tietojen tyypit, esityslomakkeet ja muoto.
Tietojärjestelmien arkkitehtuuritaso: Automaattisten ja menettelytapojen mukaisten tietojärjestelmien tekniset tiedot.
Dataarkkitehtuuritaso: Kehys tietojen ylläpidolle, saatavuudelle ja käytölle sekä tietokirjastolla ja muilla nimeämiskäytännöillä.
Tiedonsiirtojärjestelmien taso: Tietoarkkitehtuuria tukevien ohjelmistojen, laitteistojen ja viestinnän tekninen toteutustaso

Joitakin esimerkkielementtejä siitä, miten yritysarkkitehtuuria voidaan kuvata tarkemmin, on esitetty kuvassa.

Tietotekniikan arkkitehtuuri

"Memorandat 97-16 (tietotekniikan arkkitehtuurit)" antoi seuraavan määritelmän yritysarkkitehtuurille:

Yritysarkkitehtuuri on selkeä kuvaus nykyisistä ja toivotuista suhteista liiketoiminnan, johtamisprosessin ja tietotekniikan välillä. Siinä kuvataan "kohdetilanne", jonka virasto haluaa luoda ja ylläpitää hallinnoimalla IT-salkkuaan.

Yritysarkkitehtuurin dokumentaation tulisi sisältää keskustelu periaatteista ja tavoitteista. Esimerkiksi viraston yleinen johtamisympäristö, mukaan lukien keskittämisen ja hajauttamisen välinen tasapaino ja viraston muutosvauhti, tulisi ymmärtää selkeästi yritysarkkitehtuuria kehitettäessä. Tässä ympäristössä periaatteet ja tavoitteet asettavat suuntaviivoja esimerkiksi yhteentoimivuuden, avoimien järjestelmien, yleisön saatavuuden, loppukäyttäjien tyytyväisyyden ja turvallisuuden edistämiseksi.

Tässä ohjeessa otettiin käyttöön ja selitettiin tarkemmin NIST: n viiden komponentin malli. Virastojen sallittiin yksilöidä eri osat tarvittaessa ja määritellä organisaatiotaso, jolla komponenttien erityispiirteet toteutetaan. Vaikka näiden komponenttien, joita joskus kutsutaan "arkkitehtuureiksi" tai "aliarkkitehtuureiksi", sisältöön on puututtava jokaisen viraston täydellisessä yritysarkkitehtuurissa, virastoilla on suuri joustavuus kuvata, yhdistää ja nimetä komponentteja, jotka koostuvat:

Liiketoimintaprosessit : Tämä yritysarkkitehtuurin osa kuvaa keskeiset liiketoimintaprosessit, jotka tukevat organisaation tehtäviä. Liiketoimintaprosessit-komponentti on korkean tason analyysi työstä, jonka virasto tekee organisaatioiden tehtävän, vision ja tavoitteiden tukemiseksi, ja se on ITA: n perusta. Liiketoimintaprosessien analysointi määrittää viraston tarvitsemat ja käsittelemät tiedot. Tämän ITA-osan on kehitettävä vanhempien ohjelmapäälliköiden kanssa yhdessä IT-johtajien kanssa. Ilman perusteellista ymmärrystä liiketoimintaprosesseistaan ja niiden suhteesta viraston tehtäviin virasto ei voi käyttää ITA: ta tehokkaasti.
Liiketoimintaprosesseja voidaan kuvata hajottamalla prosessit johdannaisyrityksiin. On olemassa useita menetelmiä ja niihin liittyviä työkaluja, jotka auttavat virastoja hajottamaan prosesseja. Käytetystä työkalusta riippumatta mallin tulisi pysyä riittävän korkealla tasolla, jotta virasto voisi keskittyä laajasti, mutta kuitenkin riittävän yksityiskohtainen, jotta siitä olisi hyötyä päätöksenteossa, kun virasto tunnistaa tietotarpeet. Virastojen tulisi välttää liiallista painotusta liiketoimintaprosessien mallintamisessa, mikä voi johtaa agentuuriresurssien tuhlaamiseen.
Tietovirrat ja suhteet : Tämä komponentti analysoi organisaation liiketoimintaprosesseissa käyttämän informaation tunnistamalla käytetyt tiedot ja tietojen liikkumisen viraston sisällä. Eri tietovirtojen väliset suhteet on kuvattu tässä komponentissa. Nämä tietovirrat osoittavat, missä tietoja tarvitaan ja miten tietoja jaetaan operaatiotoimintojen tukemiseksi.
Sovellukset : Sovellukset-komponentti tunnistaa, määrittelee ja järjestää toiminnot, jotka sieppaavat, käsittelevät ja hallitsevat yritystietoja operaatioiden tukemiseksi. Se kuvaa myös liiketoiminnan loogiset riippuvuudet ja suhteet.
Tietojen kuvaukset : Tämä yritysarkkitehtuurin komponentti tunnistaa tietojen ylläpidon, käytön ja käytön. Korkealla tasolla virastot määrittelevät tiedot ja kuvaavat viraston tietojärjestelmissä käytettyjen tietoelementtien välisiä suhteita. Tietojen kuvaukset ja suhteet -komponentti voi sisältää tietomalleja, jotka kuvaavat viraston liiketoiminnan ja tietotarpeiden taustalla olevia tietoja. Tietojen ja tietoyhteyksien selkeä esittäminen on tärkeää yritysten tunnistettavien tietojen tunnistamiseksi, redundanssin minimoimiseksi ja uusien sovellusten tukemiseksi
Teknologiainfrastruktuuri : Teknologiainfrastruktuuri-komponentti kuvaa ja tunnistaa fyysisen kerroksen, mukaan lukien laitteiston, ohjelmiston ja viestinnän, mukaan lukien verkot, protokollat ja solmut, toiminnalliset ominaisuudet, ominaisuudet ja yhteenliitännät. Se on fyysisen IT-infrastruktuurin "kytkentäkaavio" .

Liiketoimintaprosessien komponenttia lukuun ottamatta näiden ohjeiden välisiä suhteita ja prioriteetteja ei määrätä tässä ohjeessa; implisiittistä suhteiden hierarkiaa ei ole. Lisäksi virastojen olisi dokumentoitava paitsi nykyinen ympäristö jokaiselle näistä komponenteista myös haluttu kohdeympäristö.

Sovellukset

FDIC EA -kehys.

Useat Yhdysvaltain liittovaltion virastot valitsivat NIST Frameworkin, ja sitä käytettiin tietostrategiansa perustana. Vertailumalliin sovelletaan seuraavia kehyksiä:

Energiaosaston (DOE) tietorakenne
FDIC Enterprise Architecture Framework on Federal Deposit Insurance Corporationin (FDIC) yritysarkkitehtuurikehys.
Federal Enterprise Architecture Framework (FEAF): Federal Enterprise Architecture Framework -version 1.1 dokumentaatio 1999 selittää, kuinka NIST-kehystä käytetään FEA- kehyksen perustana .
NWS Enterprise Architecture: Kansallisen sääpalvelun yritysarkkitehtuuri

Katso myös

Huomautuksia

Viitteet

Tämä artikkeli sisältää julkista aineistoa päässä National Institute of Standards and Technology verkkosivuilla https://www.nist.gov .

Languages

In other projects