Kes vajab ettevõtte arhitektuuri ja miks?

Autoriõigus © 2009 Zabegalin E.V.

1 Arhitektuurimetoodikate ja -tavade hetkeseis

AT välisriikides on metoodiliselt ja praktiliselt pikka aega välja töötatud teatud teemade ring, mille teemaks on kompleksi arhitektuur. organisatsioonilised ja tehnilised objektid, nagu ettevõtted, "elektroonilised valitsused", ettevõtete infosüsteemid.

AT Venemaa, hoolimata asjaolust, et mõisted "infosüsteemi arhitektuur"“Ettevõtte IT-arhitektuur”, “elektrooniline valitsusarhitektuur” on ammu moes ja IT-spetsialistide seas laialdaselt kasutusel, tõsine metoodiline huvi “arhitektuuriliste” teemade vastu on olemas vaid kitsas entusiastlike spetsialistide ringis (sh publikatsioonide autorid), tegevused, mis selles valdkonnas on peamiselt harivad ja oma olemuselt populariseerivad.

Seega, kui rääkida "arhitektuuriliste" metoodikate standardiseerimisest Venemaal ja nende hilisemast laialdasest praktilisest kasutamisest kodumaistes ettevõtetes, siis tundub see olevat ebakindla tuleviku küsimus. Kuid praktikas alustada "arhitektuurilist" liikumist Venemaa ettevõtted nüüd vaja.

"Enterprise Architecture", vene keeles "Enterprise Architecture" (AP), on arenenud üldiseks distsipliiniks sammuna paljude automatiseeritud infosüsteemide arhitektuuriga seotud metoodikate ajaloolises arengus – need on J. Zachmani metoodikad, St. . Spivak, CIMOSA, GERAM, TOGAF jne. Selle ajaloolise protsessi analüüs on esitatud piisavalt üksikasjalikult.

Siiani on EA kaasaegsete metodoloogiliste ideede ja praktikate silmapaistvamad ja olulisemad allikad järgmised:

Zachmani raamistik ettevõtte arhitektuuri jaoks;

ISO 19439:2006 "Ettevõtte integreerimine – ettevõtte modelleerimise raamistik";

ISO 15704:2000 standard. Tööstuslikud automatiseerimissüsteemid – nõuded ettevõtte võrdlusarhitektuuridele ja metoodikatele;

"Federal Enterprise Architecture" (FEA), mida praktiseerib ja arendab USA valitsus;

"Extended Enterprise Architecture Framework" (E2AF), mille on välja töötanud sõltumatu organisatsioon "Institute For Enterprise Architecture Developments";

Open Group Architecture Framework (TOGAF).

Koos sellega töötati 2000. aastal Venemaal välja ja avaldati kontseptuaalne arhitektuurne skeem "3D-Ettevõte", milles J. Zachmani maatriksideid täiendati kolmanda – ajutise – dimensiooniga, kajastamaks ettevõtte struktuuri ümberkujundamist.

Märgitakse, et märkimisväärne huvi AP teema vastu on seletatav kaasaegsete juhtide ja analüütikute tungiva vajadusega organisatsioonide (sh ettevõtete) arenguprotsessi mitmemõõtmelise süsteemse kirjeldamise ja planeerimise järele. Huvi sellise kirjelduse vastu tingib vähemalt praktiline vajadus omada alati piisavalt sisukaid teadmisi organisatsiooni hetkestruktuuri kohta, mida saaks kasutada ka organisatsiooni ümberkujundamise ratsionaalseks planeerimiseks muutuvates tingimustes. Kui sellised teadmised on organisatsioonis võõrandunud kujul kättesaadavad, hooldatud ja kasutatavad, siis muutub see tõhusaks juhtimisvahendiks. See kehtib eriti organisatsioonide (ettevõtete) uute juhtide ja juhtide kohta.

Joonis 1 – Juhtidel ja analüütikutel on praktiline vajadus omada alati piisavalt sisukaid teadmisi organisatsiooni (ettevõtte) struktuuri kohta

Samas jääb enamiku loetletud metoodikate abstraktsioonitase ja keerukus väga kõrgeks ning võib takistada nende efektiivset kasutamist organisatsioonides nende praktiliste juhtide ja spetsialistide poolt. erinevat tüüpi Loetletud metoodikates pakutud "maatriksid" ja "kuubikud" võivad tunduda tarbetult kunstlikud ja seetõttu praktilise kasutamise jaoks ebamugavad. Nii näiteks näib seesama “Zachmani maatriksi” olemus olevat pigem filosoofiline kui praktiline insener, see on pigem skemaatiliselt visualiseeritud spetsifikatsioon süstemaatilisest lähenemisest suurte ja keerulise struktuuriga organisatsiooniliste ja tehniliste objektide analüüsimisel. See aga ei muuda vähimalgi määral olematuks AP areneva distsipliini tohutut metodoloogilist väärtust ja praktilist tähtsust.

EA distsipliini praktilise rakendamise huvides võib selle kunstlikkuse ületamist alustada, otsides vastust küsimusele: kes ja miks võib ettevõttes vajada “Ettevõtte arhitektuuri”?

2 "Ettevõtlusarhitektuuri" eesmärk

Joonis 2 kujutab skemaatiliselt üldistatud ettevõtte struktuuri ja sisu. Antud skeemist on näha, et mudelina käsitletav ja kasutatav AP saab ettevõttes praktiliselt nõutud olla vaid juhtimisvahendina, sest ei tehniline ega tootmispersonal ei vaja AP-d oma tootmisfunktsioonide täitmiseks.

See järeldus tuleneb asjaolust, et kõik diagrammil näidatud juhtimisobjektid on samaaegselt EA mudelis kajastatavad objektid, millest tulevikus saab ka juhtimisobjekt (skeemi komponendina on näidatud ettevõtte arhitektuurne mudel ).

Joonis 2 - Ettevõtte üldistatud struktuur

Juhtimisvahendina saab EA-d kasutada kõigi selle põhifunktsioonide toetamiseks – analüüs, planeerimine, organiseerimine, motiveerimine, kontroll, koordineerimine.

Joonis 3 – "Enterprise Architecture" saab kasutada põhiliste haldusfunktsioonide toetamiseks

EA rollist haldustööriistana võib tuletada vähemalt kaks ettevõtte arhitektuuri põhifunktsiooni:

kontuuris operatiivjuhtimine ettevõte - see on võõrandunud teadmiste vormistamine ja andmine ettevõtte olemasoleva struktuuri ja toimimise kohta;

ettevõtte strateegilise juhtimise kontuuris - on vormistamine ja säte

võõrandunud teadmised ettevõtte kavandatavatest struktuursetest ja funktsionaalsetest muutustest.

Joonis 4 – "Ettevõtlusarhitektuuri" põhifunktsioonid

AP-d saab nende funktsioonidega kasutada kõigil juhtimistasanditel: alates ettevõtte juhtimistasandist kuni töökojani. Seda pakuvad (selgelt või kaudselt) tuntud metoodikad -

"Zachman Framework for Enterprise Architecture", "Extended Enterprise Architecture Framework", "TOGAF",

"GERAM", ISO 19439-2006 standard ("Generic", "Partial", "Particular" tasemed).

J. Zachmani järgi kõige konkreetsemalt ja järjekindlamalt juhtimistasandid AP kasutamine on pakutud skeemis "3D-Enterprise" - "Peamised vajadused, eesmärgid, plaanid, piirangud", "Ärimudel", "Loogikamudel", "Tehniline arhitektuur", "Üksikasjalik juurutamine", "Kasutuspraktika" .

3 "Ettevõtlusarhitektuuri" koosseis

Kõik arhitektuurimetoodikad nõustuvad, et ettevõtte (organisatsiooni) seadme piisavalt sisukaks kirjeldamiseks on selle seadme puhul vaja kasutada palju erinevaid vaatenurki (vaateid). Neid vaatenurki võib nimetada ka arhitektuurivaldkondadeks, sisuaspektideks jms. Ettevõtte struktuuri kirjeldamine (ja modelleerimine) paljudest erinevatest vaatenurkadest annab tulemuseks "Enterprise Architecture".

Erinevad metoodikad kasutavad erinevaid arhitektuurilisi vaatenurki. Näiteks:

Zachman Framework for Enterprise Architecture'is on need "Andmed", "Funktsioon", "Võrk", "Inimesed", "Aeg", "Motivatsioon";

laiendatud ettevõttearhitektuuri raamistikus (E2AF) on "äri", "teave", "teave".

Süsteemid", "Tehnoloogia infrastruktuur";

standardis GERAM ja ISO 19439-2006 on need "Funktsioon", "Teave", "Ressurss", "Organisatsioon";

TOGAF-is on need "Äri", "Teave", "Rakendus", "Tehnoloogia".

Käesoleva artikli autor peab praktiliselt otstarbekaks ületada EA sisuliste aspektide valikul nii palju erinevaid metodoloogilisi lähenemisviise, kasutades nende aspektide loogiliseks tuletamiseks mis tahes lihtsat ja arusaadavat põhimõtet.

Selline põhimõte võib tuleneda üldisest fundamentaalsest arusaamast "süsteemist" kui sihipäraselt interakteeruvate elementide kogumist. Selle põhjal saab põhimõtteliselt eristada järgmisi "Ettevõtlusarhitektuuri" põhilisi ja kergesti mõistetavaid sisulisi aspekte:

1) Ehituslik aspekt- ettevõte on üles ehitatud paljudest erinevatest füüsilistest ja infokomponentidest, sealhulgas: põhivara ja muu vara, tarbitud ja toodetud energia, personal, paberdokumendid, elektrooniline informatsioon, automatiseerimisvahendid ja automaatjuhtimine st need on “ehitustellised”, millest ettevõte füüsiliselt koosneb. Selle aspekti puhul võite kasutada ka sünonüümi terminit – struktuurne aspekt.

2) Funktsionaalne aspekt- ettevõte tegutseb, toodab tooteid, osutab teenuseid, ostab ja müüb toorainet, materjale, tooteid, tehnoloogilisi ja äriprotsesse, see tähendab, et see aspekt eristab ettevõtte tegevuse välist ja sisemist ilmingut;

3) Loogiline aspekt- ettevõtte tegevus on sihipärane, kooskõlas ettevõtte eesmärkidega, määratakse selle ülesehitus ja funktsionaalsed struktuurid. See aspekt tõstab esile ettevõtte loomise ja toimimise ärilise tähenduse.

Ettevõtte loogilise struktuuri põhikomponendid on sellised spekulatiivsed komponendid nagu ettevõtte eesmärk, missioon, visioon, eesmärgid, koht turul, ehituskomponentide põhitüüpide valimise põhimõtted, toimimise põhimõtted ja ettevõtte arengut.

AT Zachmani maatriksis tähistab seda aspekti esimese rea nimi "Uurimisala" ("Rea 1 eesmärk on määratleda ettevõtte piirid, mis kaasatakse ..." ).

AT Federal Enterprise Architecture (FEA) on "jõudluse võrdlusmudel".

AT E2AF-is ja GERAM-is ei ole loogilist aspekti selgelt eristatud ja see sisaldub "Äri" aspektis. Kuid E2AF-i põhiprintsiibid ütlevad: "Pole strateegiat, pole ettevõtte arhitektuuri ... Ei kohaldamisala – puudub ettevõtte arhitektuur

Reguleerimisala ning eesmärgid ja eesmärgid määravad ettevõtte arhitektuuri abstraktsioonitaseme ... Äritegevuse ajendid, eesmärgid ja eesmärgid on juhtivad ..." .

AT TOGAF-i loogiline aspekt vastab "Arhitektuurivisioonile" ("... "Arhitektuuri visiooni" põhielemendid"- ...

ettevõtte missioon, visioon, strateegia ja eesmärgid ..., hõlmavad arhitektuuri põhimõtteid, määratlevad ettevõtte ulatuse, konkreetsed arhitektuurivaldkonnad ..." ).

Võttes kokku loogilise aspekti ülevaate ja kasutades filosoofilist keelt, võib väita, et ettevõtte struktuuri loogiline aspekt on vajalik, et esindada "ettevõtte terviklikku ideed", "ettevõtte terviklikku kontseptsiooni", " Integral concept of the enterprise", inglise keeles saame pakkuda - "The Notion of the Enterprise" .

4) Kronoloogiline aspekt- ettevõte luuakse, tegutseb ja muutub ajas. Tuleks registreerida ettevõtte mineviku, hetke ja kavandatud struktuursed seisundid, s.t - see on "Elu ajalugu".

GERAMis on standardites ISO 15704-2000, ISO 19439-2006 pakutud aja aspekti struktureerimiseks palju etappe eluring: "Identifitseerimine", "Konseptsioon", "Nõuded", "Disain", "Rakendamine", "Kasutus", "Kasutusest kõrvaldamine".

AT metoodika TOGAF - Architecture Development Method (ADM) - ajaline aspekt kajastub "Ettevõtlusarhitektuuri" enda arendamise, rakendamise ja muutmise etappide järjestuses.

Skeem "3D-Ettevõte" võimaldab planeerida ettevõtte perspektiivseid olekuid EA aja dimensioonis, sealhulgas üksikprojekte ja arendusprogramme. Eelkõige võib ettevõtte tehnoloogiliste komponentide (süsteemide) rakendamise järjestus hõlmata: eesmärkide ja vajaduste strateegilist analüüsi, tehniliste lahenduste kavandamist, lahenduste süsteemi üksikasjalikku rakendamist, lahenduste rakendamist, süsteemi kasutamist (töötamist). , süsteemi täiustamine.

Joonis 5 – Peamised seisukohad ettevõtte struktuuri kohta

Seega võib "ettevõtte arhitektuuri" määratleda kui ettevõtte struktuuri, mida selle juhtkond on vaaginud vähemalt neljast peamisest vaatepunktist (neljast põhiaspektist) ja mida esindab (sh modelleeritud) sobiv neljast peamised arhitektuuritüübid Ettevõtted: loogiline, ehituslik (struktuuriline), funktsionaalne ja kronoloogiline.

Ettevõtte hoone arhitektuuri komponente võib käsitleda:

organisatsiooni arhitektuur on organisatsiooniline struktuur ettevõtted;

kinnisvaraarhitektuur on ettevõtte omandistruktuur;

infoarhitektuur on dokumentide (organisatsiooniline, regulatiivne, tehniline jne) ja ettevõtte teabeandmebaaside struktuur;

tootmis- ja tehnoloogiline arhitektuur on ettevõtte tootmis- ja energiavõimsuste struktuur, samuti mõõteriistade ja automaatikakomplekside ning automaatikakomplekside struktuur.

To Ettevõtte funktsionaalse arhitektuuri komponente võib seostada:

ettevõtte funktsionaalsete süsteemide ja allsüsteemide struktuur;

ettevõtte ärifunktsioonide ja äriprotsesside struktuur;

materjali- ja teabevoogude struktuurid ettevõttes.

Joonis 6 – "Enterprise Architecture" integreeritud vaade

Lisaks neljale peamisele ettevõttearhitektuuri tüübile on võimalikud ka teised, mis vastavad teistele vaatenurkadele, näiteks:

IT arhitektuur on ettevõtte automatiseeritud infosüsteemide (infotehnoloogia) kogumi struktuur;

Äriarhitektuur on ettevõtte arhitektuur ilma IT-arhitektuurita.

4 Enterprise Architecture hankimine ja kasutamine

Ettevõtte juhtkond saab AP hankida kahel viisil: esimene on AP väljatöötamine meeskonna liikmed teiseks on pöörduda väliskonsultantide poole.

Esimene tee nõuab ettevõtte juhtimist:

töörühma moodustamine, mis seejärel tuleb ümber kujundada ettevõtte alaliseks arhitektuuriteenistuseks;

õnnetuste elektrooniliseks modelleerimiseks valmis spetsialiseeritud arvutiprogrammi valimine ja soetamine ning ettevõtte spetsialistide selle kasutamise koolitamine;

sõltumatu arendus ja dokumentatsioon metoodiline tugi AP;

AP iseseisev areng.

AP väljatöötamine väliskonsultantide poolt nõuab ettevõtte juhtkonnalt lepingu sõlmimist tööde tegemiseks:

AP otseseks arendamiseks;

ÄP metoodilise toe väljatöötamise ja dokumenteerimise kohta;

ettevõtte arhitektuuriteenistuse loomise kohta.

Turul olevad äriprotsesside ja süsteemistruktuuride elektroonilise modelleerimise arvutiprogrammid võimaldavad teisendada elektrooniliste mudelite andmebaasid nende spetsialiseeritud vormingutest www-vormingusse ja seejärel avaldada need ettevõttesisesel (intraneti) saidil. See võimaldab realiseerida

ettevõtte juhtide ja spetsialistide mugav ja litsentsivaba juurdepääs AP elektroonilisele mudelile.

Seejärel saab ettevõtte moodustatud ja ettevalmistatud arhitektuuriteenistus juhtkonna heakskiidu huvides iseseisvalt lahendada EA tulevase olukorra modelleerimisvõimaluste probleeme. strateegilisi otsuseid ettevõtte arendamiseks.

Kasutatud allikate loetelu

1. Zinder E. "3D-ettevõte" - transformeeriva süsteemi strateegia mudel. "Teabeteenistuse direktor", nr 4, 2000. http://www.sept2000.ru/articles/2008/03/03/1/.

2. Zinder E. Ettevõtte arhitektuur kontekstisäri ümberkorraldamine. "Intelligentne ettevõte / ettevõtte süsteemid", nr 4, nr 7, 2008.

3. Galaktionov V. Süsteemiarhitektuur ja selle koht ettevõtte arhitektuuris. "Teabeteenistuse direktor", nr 5, 2002.

4. Danilin A., Slyusarenko A. Arhitektuur ja strateegia. "Yin" ja "Yang" infotehnoloogia ettevõtetest. M. Interneti-infotehnoloogiaülikool, 2005.

5. Drozhzhinov V., Shtrik A. USA valitsusasutuste arhitektuuri standardimine. PC Week/RE. nr 28, nr 31, 2005.

6. Zachman John A. Zachmani raamistik.http://www.zachmaninternational.com/

7. Juhtimis- ja eelarvebüroo. Föderaalne ettevõttearhitektuur (FEA).http://www.whitehouse.gov/omb/e-gov/fea/

8. Schekkerman J. Extended Enterprise Architecture Framework Essentials Guide. Ettevõtlusarhitektuuri arenduste instituut, 2006.http://www.enterprise-architecture.info/

9. Open Group Architecture Framework (TOGAF).http://www.opengroup.org/architecture/togaf8doc/arch/toc.html

10. Generalized Enterprise Reference Architecture and Methodology (GERAM). IFIP–IFAC, 1999.

11. Ivanova I.A. Juhtimine: Õpik. - M.: Kirjastus RIOR, 2004.

1. Ettevõtte arhitektuurne kirjeldus: kuidas muuta töökorraldus nähtavaks

Ettevõtte arhitektuur on see, kuidas see on korraldatud. Kui organiseeritud (arhitektuur) on, kes mille kallal töötab ja kellele seda tööd vaja on. Ettevõte on alati kuidagi organiseeritud, olgu see hea või halb. Ettevõtte korraldus (arhitektuur) on nähtamatu, kuid võimalik on teha täiesti nähtav arhitektuurne kirjeldus. Kui arhitektuurne kirjeldus on olemas, siis saavad selle abil kõik sellest organisatsioonist huvitatud osapooled (ka korraldusküsimustes pädevad inimesed) ettevõtte korraldust arutada – ja siis on võimalus organisatsiooni paremaks muuta. Kui mõnel peast võõrandunud infokandjal pole arhitektuurset kirjeldust dokumenteeritud, siis on igaühel mingi (ärge küsi millise) kirjeldus mingil (ärge küsi millisel) kujul enda peas ja isegi ühe vestluse käigus võib see kirjeldus muutuda. kolm-neli korda ühes isikus. Ettevõtte töökorralduse üle arutledes on kõigil garanteeritud erinevad arusaamad lepingutest ning selliste lepingute kallal töö tulemust kirjeldab Krylovi muinasjutt luigest, vähist ja haugist.

Arhitektuurne kirjeldus koosneb diagrammide seeriast, mida inimesed kasutavad organisatsiooni toimimise mõistmiseks ja seejärel lepivad kokku, mida organisatsioonis muuta tuleb. Arhitektuurne kirjeldus on eelkõige vahend oluliste isikutega (huvigruppidega) lepingute sõlmimiseks selle kohta olulisi aspekte töökorraldus. Ärge ajage segamini organisatsioonilisi eeskirju (mis sisaldavad nii olulisi kui ka mitte väga olulisi ja üldiselt palju sõnu) arhitektuurikirjeldusega, mis sisaldab ainult kõige olulisemat, kuid vigade vältimiseks võimalikult formaalselt väljendatud.

Ettevõtte arhitektuuri kirjeldamiseks kasutatakse spetsiaalset keelt Archimate. See keel võimaldab teil ettevõtte korralduses kõige olulisemat kirja panna - ja ignoreerida pisiasju.

Teeme kohe reservatsiooni, et Archimeites on võimalik kirjeldada vaid kontoriplanktoni töökorraldust. Archimeites ei saa kirjeldada ühtegi reaalse materjali tootmise objekti, kirjeldatakse ainult teavet nende objektide kohta. Ei mingit keedukartulit, ei mingit valuplokkide ülekandmist masinast masinasse – ainult ja eranditult teave selle kõige kohta. Archimate sobib ideaalselt pankadele ja kindlustusfirmadele, peakontoritele (kust päris töökodasid ei paista), projekteerimisbüroodele (kus rasked talad on ainult arvutimudelites ja paberväljatrükkides) ja isegi ehituse peakorterisse (kus nad jagavad tellimusi ja fikseerivad tehtu , kuid nad ise ei tee midagi käsitsi). Kuid neid ettevõtte osi, mis ei võta arvesse mutrite pingutamist, vaid tõesti pingutavad roostes mutreid, olles need laost saanud, ei suuda Archimate kirjeldada. Aga kujutada laoarvestust ehk tööde projekteerimist ja arvestust - palun.

Arhitekt on keegi, kes mõtleb välja arhitektuuri, mis rahuldab kõiki huvilisi. Ta mõtleb selle arhitektuuri välja, kirjeldab seda Archimate diagrammide kujul ja kooskõlastab selle erinevate oluliste inimestega. Archimeite arhitektuuri kirjeldamise hetk pole oluline. Arhitektideks ei saa nimetada neid, kes kirjutavad lihtsalt arhimeite (hispaania, suahiili) keeles diktaadi järgi, nad on lihtsalt asjaajajad (kirjatundjad). Olgu, peapiiskopid (peapiiskopid).

Paljude arhitektideks määratud inimeste jaoks osutub täielikuks üllatuseks, et paratamatu üleminek Archimete'is erinevate intervjuude tulemuste kujutamiselt "arhitektuurikirjeldusena sellisena nagu on" "arhitektuurikirjelduse kirjutamisele sellisena nagu on" ja vahetult pärast tihedat suhtlemist ülemused värskelt joonistatud Archimate diagrammide muutmisest ettevõtte organisatsiooniliseks reaalsuseks. Arhimaat ei aita teid teie ettevõttes rohkem kui õigekirjakontroll Vord Nobeli kirjandusauhinna saamiseks.

Sind on hoiatatud.

2. Inimesed, programmid, seadmed

Archimate peab ettevõttes kõige olulisemaks kolme olemasolu töötasemed, millest igaühel inimprintsiip väheneb: inimestest, programmid ja varustus. Tarkvarata inimesed on abitud, riistvarata tarkvara on surnud. Seadmed ilma programmideta on kasutu rauatükk, samuti pole vaja programme, kus inimesed ei tööta. Nii et ettevõtte arhitektuuris tuleb esitada kõik kolm töö tulemuslikkuse taset nende vastastikuses seoses.

Igal tasemel on oma tööde teostajad, ja nende tööobjektid tööd. Tegelikult on töö see, et esitajad muudavad teose objekte kuidagi. Töötegijaid ja tööobjekte tähistatakse tavaliselt nimisõnadega, teoseid tegusõnade ja verbaalsete nimisõnadega. Oluline on, et tööobjektid ise ei oskaks midagi teha, nad on passiivsed. Kuid täitjad on aktiivsed, nad töötavad objektide kallal ja kasutavad objekte.

Inimeste tase on tähendusrikas. Info taga olevad inimesed näevad neid ümbritseva maailma objekte, mida see informatsioon kujutab. Nad vaatavad ilmateadet ja näevad homset ilma (ja mitte ilma kirjeldust), vaatavad ehitusaruannet ja näevad reaalsete korruste arvu (ja mitte tegelikku aruannet), vaatavad kasumiaruannet ja näevad sama kasumit . Inimestel on eesmärgid, jõud (nad võivad anda mõnele teisele inimesele korraldusi töö tegemiseks) ja vastutus (peab lubama, et täidavad mõne teise inimese korraldusi). Sihipärane tegevus eksisteerib ainult sellel tasandil.

Programmitasand on andmetes sisalduva teabe töötlemine. Osadest andmetest teevad programmid muid andmeid, mis erinevad nii vormingu kui sisu poolest. Keegi ei luba kellelegi midagi (programmid ei saa lubada, ainult inimesed saavad) ja ei anna juhiseid (ainult inimesed saavad juhendada), ei taotle mingeid eesmärke (ainult inimestel on eesmärgid). Sellel tasemel teame, mida andmed reaalses maailmas tähendavad: kilomeetreid kilogrammidele liita on ohtlik. peamine ülesanne programmi tasandil – et õigel viisil töödeldud andmed oleksid õigel ajal õigete inimestega.

Riistvaratasand on hingetu maailm, kus enam ei toimu andmetöötlust, vaid ainult andmete salvestamine ja edastamine. Muidugi on ka riistvara tasemel programme, aga need on teist laadi – siin ei tea keegi, mida need andmed reaalses maailmas tähendavad. Riistvara ülesanne on salvestada kuidagi adresseeritud baite, ilma nende tähendusse süvenemata, saata need programmide nõudmisel ning ka programmid ise salvestada ja võimaldada nende täitmist.

3. Elemendid ja seosed
Ettevõtet Archimeitis kirjeldatakse elementide kujul (esitatud erinevate kujunditega), mis on omavahel mingis suhtes (suhted on kujutatud elementide figuuride ühendusjoontena). Archimate on väärtuslik selle poolest, et ta pakub kõike, mis kirjeldab ettevõtte tööd.
-- 16 üksuse tüüpi inimeste tasemel,
-- 7 üksuse tüüpi programmi tasemel,
-- 9 kaubatüüpi varustustaseme jaoks,
-- 11 tüüpi suhteid, milles elemendid võivad olla üksteisega, ja nende suhete kahvlite näitamine.

Kui kavatsete reaalses elus ettevõtte arhitektuuri kuidagi muuta (muidu miks te üldse Archimate diagramme joonistama hakkasite?), siis võite kasutada ka:
-- 7 tüüpi elemente eesmärkide seadmiseks ja organisatsiooni muudatuste põhjendamiseks
-- 4 tüüpi elemente uuele arhitektuurile ülemineku kujundamiseks

Seal on ka kommentaar ja kommentaari seos mõne muu elemendiga, samuti raam elementide rühmitamiseks.

See on kogu Archimete. Kuid ärge laske end selle lihtsusest petta. Suurel ja Vägeval on samuti ainult 33 tähte.

4. Me ei vaja teid, me vajame teie teenust.

Oluline on, et ettevõttes ei tehtaks ühtki tööd niisama, neid kõiki on kellelegi millegipärast vaja. Teenused on teosed, mis on kasulikud mõnele teisele esitajale (täpsemalt nende esinejate tööle). Teenuste tarbijate jaoks on absoluutselt ebaoluline, kuidas nende tööde teostamine on korraldatud: kes millega töötab, et teenus välistarbimiseks välja tuua. Nende jaoks on oluline ainult see, milliste kanalite (e-post, tüdrukuga aken, telefonikõne jne) ja liideste (kui need on programmid) kaudu neid teenuseid osutatakse.

Programmidele pakutakse riistvarateenuseid ja inimestele osutatavaid tarkvarateenuseid. Need teenused liimivad kokku ettevõtte kolm kihti – igast kihist on enamasti nähtavad ainult teiste kihtide teenused.

See tähendab, et saate kõik seadmed välja vahetada ja programmid ei märka seda, kui seadmete teenused jäävad samaks. Sama on programmidega: asendage need kõik, aga kui teenused jäävad samaks, siis inimesed elavad selle üle. Põhimõtteliselt kehtib see ka ettevõtte enda kohta: kui inimeste teenuseid, mida ettevõte välismaailmale pakub (ja nende teenuste ja neid ühendava lepingu kombinatsiooni nimetatakse nn. toode) hakkavad tegema väga erineval viisil organiseeritud inimesed, kes kasutavad väga erinevaid programme, mis töötavad väga erineval riistvaral, siis kliendid seda ei märka. Seda kasutavad ettevõtte arhitektid: nad kirjeldavad ettevõtet ja muudavad seejärel aeglaselt tarkvara ja riistvara, et toetada missioonikriitiliste teenuste pakkumist. Seda nimetatakse teenustele orienteeritud lähenemiseks: jaga (teenindustöö erinevad tasemed) ja valluta. Nii et ikkagi on see, kuidas vaadata: ettevõtmise liimivad kokku teenused, arhitekti jaoks aga jaotuvad need teenused.

Soov arhitektide vahel jaguneda ja valitseda on nii suur, et nad jagavad teenuseid ja töid isegi samal tasemel. Näiteks on lihtne ette kujutada programme, mis pakuvad teenuseid inimeste asemel teistele programmidele. Või seadmed, mille eesmärk on teenindada (teenuse osutamine, st "töötada") muid seadmeid.

Varustama väliselt nähtavat tööd-teenust tuleb teha palju nähtamatust väljastpoolt sisemine töö -- tööobjektide muudatused tööde teostajate poolt. Selle sisemise ja välise kaalutluse piiri olemasolu ("must kast" nähtamatute sisemiste esinejate, tööde ja objektidega versus "läbipaistev kast", kui need on täiesti nähtavad) on piiri olemasolu. süsteemid. Arhimeeritud mudelid süsteemid, eraldades ettevõtte osad / tasemed teenuste järgi (kuigi Archimate spetsifikatsioonis pole "süsteemide" kohta sõnagi öeldud).

5. Inimesed

Tuletage meelde punkti kolm: inimeste töökorralduse taseme kirjeldamiseks on Archimate'is sama arv elemente (17) kui programmide ja seadmete kombineeritud tasemete (7 + 9) puhul - ja see pole sugugi juhuslik.

Inimesi ennast Archimeites ei esinda nende isiksused. Archimeites ei maali mitte inimene kohta, vaid koht maalib inimest. Archimeites on esineja elav inimene, kuid tal on ainult organisatsiooniline positsioon. Seetõttu nimetab Archimete just neid kohti "inimesteks", olenemata sellest, kes neid parasjagu täidab - üks inimene, terve rühm inimesi organisatsiooni tasandilt (alates sektorist ja osakonnast kuni mõne teise osariigi filiaalini või isegi kogu ettevõte) , ajutised töötajad, juhuslikud kodanikud-kliendid, partnerettevõtted. Arhimaat mõistab, et kõik need organisatsioonilised kohad on hõivatud elavate inimestega, kuid ta nimetab neid inimesi just organisatsiooniliste kohtade nimede järgi. Meistrimees, kohaletoimetamise osakonna juhataja asetäitja, kohaletoimetamise osakond, Mytishchi filiaal, klient, audiitor – need on "inimesed", olenemata sellest, kes on töötajad, kes nendel organisatsioonilistel ametikohtadel on. Arhitekt, nagu ikka, hoolib igavesest: kui meistrimees või president haigestub ja üks inimene asendab haiguse ajaks teist, jääb skeem tõeks: töökorraldus ei muutu.

Arhimeedi inimesed on mitmekesisemad kui need inimesed, keda võib kohata "organisatsioonistruktuuris" (organigrammis): sugugi kõik Arhimeedi inimeste vahelised suhted ei taandu ülemustele-alluvustele. Nii et partnereid ja kliente organisatsioonistruktuuris tavaliselt ei mainita, kuid Archimeites on nende eksponeerimine tavaline asi.

6. Rollid

Arhitektid on nii salakavalad, et töötavad inimeste osadega, nimetades neid "rollideks". rolli see osa ajaliselt eraldatud inimestest kutsutakse, mis teeb teatud arvu töid, mis nõuavad mingit erikvalifikatsiooni. Seega, kui teatritööline on sunnitud kas laulma või tantsima, on tal kaks rolli: kui ta laulab, siis on roll laulja ja kui ta tantsib, on roll tantsija.

Inimesed ametisse nimetatud rollide ja rollide kohta ametisse nimetatud töötama. Eriti tähelepanuväärne on asjaolu, et organisatsiooni arhitektid tegelevad töö korraldamisega, mitte juhtimisega (juhtimisega). Inimeste määramine rollidesse ja rollide määramine töökohtadele on organisatsiooni arhitekti mure. Ja juhi mure on a) perekonnanimede, eesnimede ja isanimede, halbade ja kasulike harjumuste, teatud oskustega elavate "inimeste" määramine "inimeste" kohtadesse ja b) rääkivate inimeste määramine "inimeste" kohtadesse porgandiga ja pulk neile määratud töö tegemiseks. Nii et te ei näe Archimate'i diagrammidel nimesid: ainult ametikohad, rollid, allüksused, ettevõtted, "vastutavad isikud", "esindajad", kollegiaalsed organid, ajutised rühmad ja ühendused jne.

Elus kohtumine rollide ja töö kohta kajastatakse tavaliselt korraldusi, korraldusi, määrusi ja muid "haldusdokumente". Sellist inimeste jagamise süsteemi pole vaja ainult selleks, et näidata inimeste ametite mitmekülgsust (tuletan teile meelde: nii üksikisikud kui ka terved osakonnad - kui 1000 töötajaga suur ettevõte tegutseb nii ühe ettevõtte kui tarnijana kui ka tellija teiste firmade suhtes), aga ka selleks, et arhitektid muudaksid oma skeeme vähem ja töökorraldust kehtestavaid korraldusi väljastatakse harvemini.

Tüüpiline näide: organisatsioon hakkab peterselli istutama, aga pole veel selge, kes selle peterselli istutab – võimud ütlevad, et "näidate, mis seal teha tuleb, ja siis määran sobiva kandidaadi." Nad kirjutavad "Peterselli eeskirjad", kus tutvustavad "peterselli pealiku" ja "peterselli vanema" rolli ning kirjutavad ette kogu oma töö. Pange tähele, et määrus ei ole veel korraldus, mitte korraldus. See on väide tõsiasjast, et töö (peterselli istutamiseks) käimiseks tuleb täita mõned organisatsioonilised kohad (pealik ja vanem petersellis). Juhataja uurib seda määruse eelnõud ja jõuab järeldusele, et peterselli istutamisega peaksid tegelema insenerid ja juristid. Seejärel kirjutab ta korralduse, milles a) kinnitab ametikoha ja b) näeb ette, et peterselli pealiku rolli täidab insener ja peterselli vanem on jurist. See näeb välja järgmine:

Punktilised pistikud on elementide vaheline "sihtkoha seos". Inimeste ja teoste vahelised suhted on muidugi otseselt olemas (kui rolli mainimata jätta). Sellist seost nimetatakse tuletisteks, kuid see on endiselt olemas - võib öelda, et sel juhul on insener ülesandeks tagada istikud ja advokaat hoolitseb istutamise eest.

Pange tähele, et see disain töötab ka siis, kui insener Ivanov läheb pensionile ja tema asemele palgatakse Sidorov. Selles konstruktsioonis on lihtne inseneri vahetada agronoomiks või peterselli direktoraadiks (kui tegevus kasvab) - see mehhanism sihtkoht rollid tööle (näiteks määruste järgi) ja inimesed rollidesse (näiteks käsu järgi) toimib ka juhul, kui "inimesed" on terve hulk inimesi jne. See puudutab organisatsiooni. Kõiki neid eeskirju ja korraldusi tavaliselt skeemile ei märgita: skeemidel lepitakse kokku, kuidas tööd korraldatakse, mitte aga milliste dokumentidega need lepingud koostatakse.

Vihje: Tean mitut organisatsiooni, kus ettevõtte arhitektuursete kirjelduste albumid kinnitati direktori poolt paksu määrustikuvirna asemel. Sest arhitektuursed skeemid osutusid täpsemaks ja ilmekamaks kui arvukad tekstilised kirjeldused, mida nad seejärel proovisid neist koostada.

On selge, et kõige elavamad Ivanov ja Sidorov (või peterselli direktoraadis loetletud töötajad) tegelevad lõpuks peterselli istutamisega. Kuid nad kulutavad ettevõttele ainult osa oma ajast ja annetest (ja ainult seda osa ajast peegeldub ettevõtte arhitektuuri element "inimesed") ning ülejäänud aja magavad, söövad, jalutada, õppida ja lõbutseda. Nad kulutavad peterselli istutustööle vaid murdosa ettevõttele kuluvast ajast – kuna neil on tõenäoliselt palju erinevaid rolle, nad täidavad paljusid. erinevaid teoseid. Jah, ja samasse rolli võib määrata teatud arvu inimesi - üksikuid inimesi või isegi mitut osakonda.

Nii inimesi kui ka rolle saab jagada suvalisteks osadeks, kui soovite näidata mõningaid üksikasju esinevate inimeste tööhõive kohta.

Et natuke tööd teha erinevad inimesed võib mõneks ajaks ühineda (organisatsiooni struktuuris see tavaliselt ei kajastu) ja sellist ajutist ühingut nimetatakse kollegiaalne roll.

7. Inimeste tööd

Inimeste töökohad on:

• juba juhtus - arenguid. Sündmusi nimetatakse tavaliselt mineviku täiusliku vormi tegusõnaga: "petersell on istutatud". Neid töid võivad teha tahtmatult ("tekinud viga"), ettevõtteväliste inimeste poolt (kliendid, konkurendid, partnerid) ja üldjuhul ei saanud seda tööd teha inimesed (aga nt programmid, seadmed, või isegi loodusjõud - - "Päikeseloojang").
• mille eesmärk on saavutada tulemus ja viiakse läbi ajaliselt (sageli üksteise järel) - protsessid. Neid nimetatakse verbiks määramatus vormis - "kaevama", "istutama", "arenema". Protsessid on tavaliselt jooksma sündmus ja käivitada sündmused ja käivitavad ka üksteist, moodustades ahela algsündmusest tulemussündmuseni.
• saadud ajutise meeskonna töö tulemusena, mida ühendab kollegiaalne roll -- kollegiaalsed protsessid. Neid nimetatakse ka määramatus vormis tegusõnaks.
• valitakse tulemuse saavutamiseks millekski muuks kui ajabaasi jaoks (näiteks nõudes neile teatud kvalifikatsiooniga rollide määramist või kulutades mingit laadi konkreetne vaade ressursid) -- tavasid. Praktikaid ei sooritata mitte niivõrd iseenesest, vaid erinevatel hetkedel sooritatakse teatud nende poolt kombineeritud protsesse (või protsesside fragmente, milleni asi diagrammil pole jõudnud, nii et neid kujutati ilma ajas, kägistamata, kott" – see näitab pigem "mida harjutatakse", mitte ei tehta konkreetsel ajal). Seetõttu tähistatakse tavasid mitte tegusõnadega, vaid verbaalsete nimisõnadega: "peterselli istutamine" on täpselt tava.


• kellelegi väljastpoolt antud teosed, kuidas need on olulised ja väljastpoolt vaadatuna -- Teenused. Teenused rakendatud sisemine töö, mida teostavad sisemised rollid, ja kasutatud ajal välistööd mida täidavad välised rollid. Põhimõtteliselt tehakse igasugust inimeste tööd ainult selleks, et seda teha rakendama mingi teenus – see tähendab, et keegi teine ​​(näiteks klient või alltöövõtjad) saaks neid töid kasutada.

Põhimõtteliselt on kogu ettevõte jagatud osadeks ja need osad avaldavad oma olemasolu õigustamiseks väljaspool (ettevõtte teistele osadele või ettevõtte piiridest väljapoole või muule tasemele) teenuseid. Kui on raskusi arusaamisega, kes milles töötabkasutabteatud teenuseid või milliseid teenuseidrakendamateatud teosed - see tähendab, et te ei tea midagi või pole seda läbi mõelnud.

Et selgitada, mille jaoks teenus täpselt väärtuslik on, on Archimetel isegi spetsiaalne element:väline kasu, mis seotud teenindusega.

* * *

Põhimõtteliselt on juba selge, et lugu sellistes mõistetes on üsna edukas - see ei tundu liiga abstraktne ja on abstraktne täpselt niivõrd, kuivõrd absurdne on Archimate ise. Siis ei saa "Arhimaati vene keeles" sarjast enam uusi tekste kirjutada, vaid lihtsalt parandada varem kirjutatud. Noh, jätkake programmi lokaliseerimist.

Lühike on ka teine ​​artikkel mütoloogilisest teadvusest. Täna räägin teile, milliste probleemideni viib mütoloogiline teadvus ettevõtte arhitektuuri modelleerimisel.

Tuntud Zachmani mudel püüab vastata küsimusele, mis on ettevõtte arhitektuur ja kuidas seda modelleerida. Selle mudeli aluseks on küsimused, millele pakutakse vastuseid: kes, millal, kus, miks ja kuidas millegi kallal midagi teeb. Tundub, et see on loogiline raamistik ettevõtte arhitektuuri kirjeldamiseks ja paljud inimesed arvavad, et see on nii.

Kuid isegi põgus pilk sellele raamistikule jätab rahulolematuse tunde, sest pole selge, kuidas vastata küsimusele: kes ja miks detaili masinas? Kes: Ivan Ivanovitš ehk treial, kelle rollis oli Ivan Ivanovitš? Miks: kuna treial sai töökoha või Ivan Ivanovitš sõlmis lepingu, mille järgi kohustub toidu eest treial olema? Miks: sellepärast, et Ivan Ivanovitš tahab süüa või sest osa on montaažikojas vaja?

Selle raamistiku sügavam uurimine paneb mõtlema selle rakendatavuse üle kirjeldusele tehnoloogilised protsessid. Lase näiteks maisil põllul kasvada. Zachmani mudelit rakendades pean vastama küsimustele. WHO? Mais. Mida ta teeb? Kasvab. Miks? Sest nii see maailm toimib. Milleks? Aga kes teab, miks mais kasvab ?!

Ettevõtlusarhitektuuride kirjeldamise koolitatud lugeja parandab mind kiiresti. Ta ütleb, et ma esitan valesid küsimusi. On vaja küsida: kes kasvatab, miks ta kasvab, mida ta kasvatab. Siis aga selgub, et ma võin kirjeldada maisi kasvatava katsealuse tegevust, aga kasvu ennast ei oska. Olles leppinud tõsiasjaga, et ma ei oska kasvuprotsessi kirjeldada, on mul endiselt lahendamata küsimusi: kes ja miks kasvatab maisi (vt ülalt)?

Selgub, et näiliselt loogilisi küsimusi esitades saan parimal juhul mõned vastused ja halvimal juhul ei saa ma neid üldse. Kui võtta äärmuslik juhtum, kui meil on täielikult robotiseeritud ettevõte, milles pole üldse inimesi, siis vastus küsimusele "kes?" saab olema - "mitte keegi". Seetõttu ei saa me selle ettevõtmise kohta üldse midagi öelda! Tõsi, sellest olukorrast on üks väljapääs, veidi kaval – peate lihtsalt kasutama müütilist teadvust ja animeerima roboteid. Siis, kui oleme elutu animeeritud, saame vastata küsimusele: kes? Robot. Miks? Sest see robot on nii loodud või programmeerija programmeeris selle nii. Teisele küsimusele saame jälle kummalised vastused. Miks see juhtus ja milliseid küsimusi tasub tõesti küsida? Püüan lühidalt avaldada oma arvamust sellel teemal, rääkides Zachmani mudelist leitud loogikavigadest.

Kui vaatate Zachmani mudelis esitatavaid küsimusi, näete, et need vastavad täpselt tegevusteooriale. Tegevus on subjekti (subjektide rühma) vaimne funktsioon. Seetõttu ehitame Zachmani küsimustele vastates subjekti (subjektide) vaimse funktsiooni mudeli. Teadust, mis uurib subjektide vaimseid funktsioone, nimetatakse psühholoogiaks. Selgub, et Zachman vastab küsimustele, mida psühholoogid küsivad: miks subjekt teeb seda või teist tegevust? Või kuidas motiveerida subjekti teatud toiminguid sooritama? Need küsimused on kindlasti huvitavad ja olulised, kuid kas vastused neile on ettevõtte arhitektuuri kirjeldus? Sellele küsimusele vastamiseks peate mõistma, mis on ettevõte?

Kuidas ettevõtte kujundamine tegelikult toimub ja millised artefaktid selle protsessi käigus tekivad? Enne ettevõtte projekteerimist koostatakse sellele esitatavate nõuete mudel. Nõudemudel koostatakse nõuete alusel, mida ettevõttele esitavad kõik selle osalejad, töövõtjad ja sidusrühmad. IT-s on analoogiks tarkvaratootele esitatavad nõuded. Lisaks koostatakse nende nõuete alusel ettevõtte protsesside mudel, mis on nõutava detailsusega. IT-s on analoogiks tarkvaratoote funktsioonide loend. Järgmisena ehitatakse funktsionaalsete objektide mudel, või kui rääkida spetsialiseeritud keel, tehnilised kohad, mis peaksid osalema ülalloetletud protsessides. IT-s on analoogiks protseduuride kirjeldus ja selgitus, millised protseduurid milliste funktsioonidega on seotud. Järgmisena valitakse välja need seadmed, mis suudavad täita loetletud tehniliste kohtade rolle. IT vasteks on programmikood.

Ettevõte on funktsionaalne objekt, mis on loodud teatud nõuete täitmiseks. Selles mõttes ei erine ettevõte objektist nagu kell või tootmisliin. Sageli võib termini funktsionaalne objekt asemel kuulda terminit tehniline koht. Funktsionaalne asukoht erineb seadmest selle poolest, et seade toimib funktsionaalse asukohana. Näiteks trafo toimib pingemuundurina, samas kui sees erinev aeg erinevad trafod võivad täita sama muunduri rolli. Teine näide tehnilisest kohast on ametikoht, osakond, osakond, osariik. Näiteks treial osaleb detailide valmistamise funktsioonis. See on tehniline koht, mille rolli saavad täita erinevad seadmed erinevatel aegadel ( üksikisikud). Tehniliste kohtade ja seadmete modelleerimise raskustest kirjutasin lühidalt ühes artiklis.

Tehniliste kohtade modelleerimisel kirjeldame protsesse ja nendes protsessides osalejaid. Märgin, et trafo ei saa pinget teisendada osalejad, mitte esinejad, sest see ei ole animeeritud olend. Kirjutasin sellest ühes eelmises artiklis. Kui siiski öelda, et trafo "muundab" pinget, siis on tegemist metonüümiaga, mis ilmneb järgmiselt: trafo täidab pingemuunduri rolli, mis (muundur) osaleb pinge muundamise protsessis. Metonüümiast saab lugeda raamatust "Metaphors We Live By", autorid: George Lakoff, Mark Johnson. Teine levinud metonüümia oleks "arvuti lahendab probleeme". Need, kes tõesti usuvad, et trafo või arvuti tegelikult midagi teeb, animeerivad elutut, kasutades müütilist teadvust.

Pange tähele, et siiani pole me sõnagi rääkinud eesmärkidest, sooritajatest ja põhjus-tagajärg seostest. Rääkisime ainult nõuetest, funktsioonidest ja nende funktsioonide osalejatest - tehnilistest kohtadest. Eesmärgid jäid ettevõttele esitatavate nõuete kujunemise staadiumisse ja kaugemale ei jõutud. Me võime neid eesmärke teada, aga ei pruugi – see ei oma ettevõtte mudelit vahet. Ettevõtlusmudel vastab küsimusele: kuidas me vastame nõuetele, mitte aga kust need nõuded tulevad. Samuti pole esinejaid, sest me ei pea tegevuses osalejate kirjeldamiseks kasutama tegevusteooriat. Me ei loo põhjuslikke seoseid. Kui on vaja luua põhjus-tagajärg seoste mudel, siis see on veel üks lisamudel. See on teadmine, mida tehnoloogid ettevõtte projekteerimisel kasutavad ja ma pole näinud, et keegi selliseid mudeleid ehitaks. Need on haruteadmised ja neid on instituutides õpetatud juba aastaid. Modelleerida, miks lennuk lendab, on ebareaalselt keeruline ja keegi ei tee seda. Lihtsalt simuleerige lennuki lendu.

Niisiis, Zachmani mudel ei sisalda ettevõttele esitatavaid nõudeid, see sisaldab protsesside mudelit, kuid üsna spetsiifilisel viisil - protsessi teostajate viitega, mida, nagu ma ütlesin, võib leida ainult teooriast tegevusest ning ei eralda tehniliste kohtade mudelit ja näidisseadmeid.

Nagu ma varem ütlesin, on Zachmani mudel rohkem seotud tegevusega. Samas oleks tore, kui Zachmani mudelit kasutataks sihipäraselt – tegevuste kirjeldamise viisina. See võimaldaks analüüsida inimeste motiive ja huvi nende töö vastu, kuid häda on selles, et seda mudelit kasutatakse valesti. Näiteks küsimusele "miks treial osa teritab?" saate vastuse: "seda on vaja koostetsehhis." Kuid selle vajadus koostetsehhis ei vasta küsimusele, miks treial detaili teritab. Vastus ei olnud esitatud küsimusele, vaid mõnele muule. Näiteks sellise vastuse puhul oleks õige küsimus: millises protsessis või millises toimingus peaks töödeldud detail osalema? Või millisel töökohal seda vaja on? Näete, see pole üldse "miks" küsimus. Lisaks on mul väga piinlik Zachmani oskuse pärast anda arvutile või infosüsteemile võime midagi teha. Tõenäoliselt ei animeeri ta neid, vaid kasutab modelleerimisel metonüümiat, mis on minu arvates vastuvõetamatu.

Õiged küsimused on järgmised: millised on nõuded ettevõttele? Millised protsessid ettevõttes toimuvad? Millised tehnilised kohad millistes protsessides osalevad? Millised seadmed täidavad milliste funktsionaalsete asukohtade rolli ja millal?

Tegelikult kõike. Head uut aastat ja peatse kohtumiseni!

Alustasin ühe ettevõttega koostööd ettevõtte arhitektuuri teemal (Enterprise Architecture) ja otsustasin oma arusaama EA-st parandada, et muuta see selgemaks ja lihtsamaks. EA sünnikuupäevaks peetakse üldiselt John A. Zachmani teose "A Framework for Information Systems Architecture" 1987. aastal avaldatud väljaannet, kuigi see termin ise on esinenud varasemates kirjutistes. Hoolimata asjaolust, et ettevõtte arhitektuur on üsna noor asi, on see juba suutnud oma maine rikkuda. Nagu iga teine ​​arhitektuur, pole ka ettevõtte arhitektuur täpselt määratletud (vt näiteks 10 ettevõttearhitektuuri definitsiooni), kuid sellel on palju ebaõnnestunud projekte (vt Gartner tuvastab kümme ettevõtte arhitektuuri lõksu või 8 põhjust, miks ettevõtte arhitektuuriprogrammid ebaõnnestuvad) . Tavaliselt võite pärast ettevõtte arhitektuuriprojekti lõpetamist kuulda järgmist fraasi: " Oleme kõik vajalikud pildid joonistanud, aga meil pole õrna aimugi, kuidas sellest vähemalt mingit kasu saada.". Seetõttu räägime kõigest algusest peale.

Ja me alustame kaugelt. Infotehnoloogia kasulikkuse kohta on kaks seisukohta. Esimese vaatenurga kohaselt võimaldavad infotehnoloogiad tõsta tööviljakust, s.o. inimesed töötavad tõhusamalt, kui nende tegevus on automatiseeritud. On ka vastupidine seisukoht, mida väljendavad näiteks sellised raamatud nagu „Infotehnoloogia sära ja vaesus. Miks IT ei ole konkurentsieelis" Nicholas J. Carr või "What Business Wants from IT" autor Terry White. Üllataval kombel on mõlemad seisukohad õiged. Aga kitsendagem oma mõttekäigu ringi ja rääkigem mitte infotehnoloogiast üldiselt, vaid ainult ärirakendustest, s.t. süsteemid, mis automatiseerivad organisatsiooni äriprotsesse. Esialgu annab selliste süsteemide väljatöötamine ja juurutamine käegakatsutava efekti. Kui erinevad töötajad hakkavad sarnaseid toiminguid kajastama ühes võrgu kaudu erinevatest töökohtadest ligipääsetavas andmebaasis, suhtlevad omavahel selliste lahenduste kaudu ja spetsialiseeruvad teatud funktsioonidele, suureneb nende tootlikkus. See on palju parem kui üksteisele telefoni teel helistamine või emotsionaalselt laetud sõnumite vahetamine e-mail. Seetõttu hakkavad automatiseerima mitmesugused muud protsessid, võib-olla mitte nii sagedased ja mitte nii vajalikud. Sellise automatiseerimise efektiivsus ei ole nii kõrge. Madalalt rippuvad õunad on juba ära kitkutud ja tulemuse saavutamiseks peame leiutama keerukamaid viise. Mingil hetkel muutuvad ärirakenduste kasutamise kulud suuremaks kui nende kasutamisest saadav kasu, kuid ülekiirenenud vedurit pole enam võimalik peatada. Selle künnise põhjuseks on infosüsteemide orgaaniline keerukus (IT Complexity). Tegelikult satume ühel hetkel lihtsalt segadusse, mida me teeme, ja infosüsteemid aitavad meil veelgi rohkem segadusse sattuda. Arhitektuur (ettevõte) on vaid viis kontrollida süsteemidele omast keerukust, pidada silmas enam-vähem adekvaatset pilti, võimaldades samas seda keerukust juhtida.

Järgmine probleem on see, et sellist pilti ei saa tulevikuks ette valmistada. (Siinkohal räägivad arhitektid teile palju moesõnu erinevate seisukohtade, vaadete, sidusrühmade ja murede kohta). Seega, et vastata küsimusele "Miks me tegeleme ettevõtte arhitektuuriga?" vaja juba algusest peale. Lubage mul esile tõsta kolm kõige levinumat vastust:

1. Meil on strateegia, mis vastab küsimusele, mida me tahame, kuid me ei tea, kuidas seda teha.
2. Meil ei ole strateegiat, kuid meil on tulva muutmistaotlusi, millega me hakkama ei saa.
3. Teave meie tegevuse kohta on vastuoluline ja meil pole aega igast aru saada konkreetne juhtum, miks see juhtub.

(Kui arvate, et on muid, sagedamini esinevaid võimalusi, märkige see kommentaarides).

Esimesel juhul peame tegema Strateegiad –> Plaan. See puudutab peamiselt äristrateegiat. Tavaliselt näeb see välja nagu mõned deltad selle vahel, mis teil on ja mida soovite, väljendatuna üsna lihtsas sõnastuses: turuosa tulude, kliendibaasi jms osas. Üldiselt on strateegia dokument homsete siilide kohta. , millest saavad tänapäeva hiired. Sellest, mida sel juhul teha tuleks, kirjutan eraldi sõnumis, aga praegu paar sõna sellest, kuidas sellist protsessi korraldada. Minu arvates, organisatsiooniline vorm Enterprise Architecture Development on projekt, mis kestab 8-16 nädalat. Metoodika - TOGAF ADM jne. Ressursid tuleks kaasata, peamiselt sisemised. Projekti tulemused on: teekaart, organisatsiooniliste ja protsesside muudatuste loetelu, riskid, ettepanekud liikumise jälgimiseks ja juhtimiseks antud suunas. Üldiselt nimetatakse ilusaks sõnaks kõike, mida traditsioonilistes projektides planeerimisfaasis tehakse koondplaan. Sellise projekti meeskonna, tegevuste ja artefaktide komplekti kohta - sama ühes järgmistest sõnumitest.

Valik number 2: Muutuste juhtimine. Strateegia asemel on erinevate äriklientide jaoks erinevate eesmärkide kogum. Mõned peavad kulusid vähendama, teised peavad turule tooma uusi tooteid ja teenuseid ning kolmandad peavad parandama klientide rahulolu (vt lühidalt Enterprise Architecture'i kohta). Kõik kliendid on lugupeetud inimesed ja kõik vajavad abi. Kuid keerukus on juba kasvanud ja me ei mõista, kuidas kõiki korraga aidata. Lihtne ja vale viis kõigi joondumiseks ilus nimi, näiteks "Üks prioriteetide loetelu" ja infosüsteemide vahel ülesannete jaotamise meetod - "Tasuta kassa!" - kes saab kiiremini ja odavamalt hakkama, selle usaldame. Õige lahendus on päringute mitmefaktoriline klassifikatsioon, teisisõnu taksonoomia. Metoodika - Zachmani stiilis. Organisatsioon – loomine funktsionaalne üksus. Eelmises märkuses Kas ärianalüütikud on sõbrad, naabrid või kauged sugulased? Kirjutasin, et BABOKi kolmanda versiooni tuleku ja kasutuselevõtuga saavad ärianalüütikud seda tööd teha. Aga siiani ei saa. Praegu oskavad ärianalüütikud vastata küsimusele “Mida on vaja teha?”, lahendusarhitektid aga küsimusele “Kuidas seda teha?”. See nõuab ka vastust küsimusele “Miks?”, kuidas see muudatus on seotud olemasolevate toodete ja protsessidega, muude muudatustega, rakendustega.

Ja lõpuks olukord, kus keerukus on juba võitnud ja organisatsiooni juhid on sellest teadlikud. umbes sama Pildid, mida pole siis, kui neid vaja läheb, et mõni vastuoluline probleem kiiresti lahendada ja mis ülejäänud aja lamavad täiesti kasutut lasti. See olukord räägib arhitektuurihoidlast. Kusagil võib olla arhitektuuri kirjeldavaid pilte, aga kui neid minuti või paari jooksul ei saa, siis ei tee pea ega suvaline juht seda ise, vaid palub kellelgi teisel pildi teha (“Helista arhitektile siia !"). Kui inimene ei tööta rakendusega vähemalt kord 1-2 nädala jooksul, siis ta ei tee seda üldse. Kui infosüsteemi arendajal puuduvad lihtsad, arusaadavad ja kasutusvalmis API-d klienditüüpide hankimiseks, filiaalide loetelu, toimiv organisatsiooniline struktuur vms, siis lisab ta oma infosüsteemi kindlasti veel ühe plaadi. , milles ta sunnib kasutajaid uuesti nendest kataloogidest andmeid sisestama. Ma ei ole teadlik ühestki EA tööriistast, mis sobiks samaväärselt demonstreerimiseks ilusaid pilte tippjuhid ja samal ajal kaasasündinud koostalitlusvõime tõelistesse ärirakendustesse integreerimiseks. Loodan, et varem või hiljem sellised ilmuvad. Ja siis muutub variant number kolm lihtsaks projektiks infosüsteemi juurutamiseks ning selle hilisemaks kasutamiseks ja arendamiseks.

Jätkub (ettevõtlusarhitektuuri lugu)!

Teoreetilised aspektid ettevõtte arhitektuur. Ettevõtte arhitektuuri põhielemendid. Ettevõtte arhitektuur on kõige üldisem ja terviklikum esitus ettevõttest kui majandusüksusest, millel on oma põhitegevuse läbiviimiseks lühi- ja pikaajalised eesmärgid, mille määrab missioon regionaalsel ja globaalsel turul ning arengustrateegia, välised ning missiooni täitmiseks ja püstitatud eesmärkide saavutamiseks vajalikud sisemised ressursid, samuti põhitegevuse läbiviimiseks kehtestatud reeglid.äri. Teoreetiline...

Jagage tööd sotsiaalvõrgustikes

Kui see töö teile ei sobi, on lehe allosas nimekiri sarnastest töödest. Võite kasutada ka otsingunuppu

Sissejuhatus

1.3. Kihid arhitektuuris

Bibliograafia

Sissejuhatus

Hiljuti väliskeskkond muutub väga kiiresti, mistõttu ettevõtete kohanemisvõime nõuded kasvavad aasta-aastalt. Erinevad analüütilised uuringud on näidanud, et enamik rahvusvahelised ettevõtted ei ole aega kohaneda käimasolevate muutustega, samas kui trend selles valdkonnas on negatiivne. Ettevõtete kohanemisvõime tagamise peamiseks probleemiks on selle raames tehtavate muudatuste koordineerimine ja kontroll. Kui eesmärgid muutuvad, muutub strateegia, mis omakorda toob kaasa äriprotsesside ja projekti prioriteetide ning organisatsioonilise struktuuri muutumise. Kõik see mõjutab kaudselt teadmiste ja autoriteedi taset ettevõttes ning sellest tulenevalt ka infovooge, mis omakorda eeldab muudatusi olemasolevates infosüsteemides.

Ettevõtte arhitektuur on kõige üldisem ja terviklikum esitus ettevõttest kui majandusüksusest, millel on oma põhitegevuse läbiviimiseks lühi- ja pikaajalised eesmärgid, mis on määratletud missiooniga regionaalsel ja globaalsel turul ning arengustrateegiaga. , missiooni täitmiseks ja seatud eesmärkide saavutamiseks vajalikud välised ja sisemised ressursid. , samuti põhitegevuse – äritegevuse – läbiviimise reeglid.

1. Ettevõtte arhitektuuri teoreetilised aspektid

1.1. Ettevõtlusarhitektuuri põhielemendid

Enterprise Architecture Management pakub raamistikku objektide sünkroonimiseks ettevõttes, tagades samal ajal nende pideva muutmise äri optimeerimise eesmärgil.

Muudatuste kontroll ja kõigi arhitektuurielementide järjepidevus aitavad kaasa ettevõtte kohanemisvõime suurendamisele, mis on hetkel konkurentsis oluline tegur. Samas võivad infosüsteemid muutuda sageli muutuste peletajaks, mis tähendab, et erilist tähelepanu tuleks pöörata äriarhitektuuri ja IT-arhitektuuri elementide sünkroniseerimisele. Ettevõtte arhitektuuri haldamiseks kasutatakse standardset tsüklit, mis koosneb järgmistest sammudest: olemasoleva arhitektuuri kirjeldamine, selle sihtoleku kujundamine, üleminekuplaani koostamine olemasolevalt sihtarhitektuurile. Esimese sammuna tuleb kindlaks teha, milliseid arhitektuuri elemente ja millises mahus kirjeldada.

Ühest küljest tähendab loodud kirjelduse detailsus sügavamat uurimist, teisalt aga tarbetuid tööjõukulusid nii kirjelduse enda loomisel kui ka ajakohasena hoidmisel. Nagu öeldakse, "parim on hea vaenlane" ja seega ka Täpsem kirjeldus arhitektuurielemendid ei ole kasulikud. Selles etapis on oluline luua kõik võimalikud ettevõtte arhitektuuri põhielemendid ning keskenduda nende kirjeldamisele ja analüüsile.

Praktika näitab, et esimene ebakõla ettevõtte arhitektuuris ilmneb reeglina eesmärkide, äriprotsesside ja organisatsiooni struktuuri vahel. Paljudel juhtudel ei toetata mitut sihtmärki vajalikke ressursse ja äriprotsessid. Seetõttu on juba arhitektuuri analüüsimise käigus võimalik koostada tööplaan ettevõtte tegevuse optimeerimiseks selles valdkonnas. Kui analüüsime ettevõtte infotehnoloogiaid, siis on need sageli vastuolus tema olemasolevate ja veelgi enam suunatud äriprotsessidega. Ka siin on tegevuste optimeerimiseks avar valdkond.

Lisaks ebakõlale ettevõtte arhitektuuri põhielementide vahel on sageli probleeme ka sees individuaalne element, esiteks on see dubleerimine, samuti organisatsioonilised ja infolüngad jne. Kuid mitte ainult muudatuste arv ja ettevõtte paindlikkuse nõue ei ole põhjustanud nii tõsist tähelepanu arhitektuurihaldusprobleemidele. Tehnoloogiliste süsteemide keerukus suureneb, mis tähendab nende töökindluse vähenemist. Sel juhul saab ettevõttes operatsiooniriski juhtimise protseduuride pakkumise aluseks arhitektuuri formaliseerimine, sest kui selle põhielemendid on formaliseeritud, ei ole enam keeruline riske tuvastada ja kontrolliprotseduuride tõhusust analüüsida. Seetõttu on kõige kriitilisem arhitektuurihaldus suured ettevõtted mis kasutavad keerulisi tehnoloogiaid, mis on seotud paljude tegevus- ja tehnoloogiliste riskidega.

Vaatamata arhitektuurihalduse valdkonna metoodikate mitmekesisusele, piirdub enamik ettevõtteid praktikas selle järgmiste elementidega: ärieesmärgid; organisatsiooniline struktuur; peamised tulemusnäitajad; äriprotsessid; projektide portfell; dokumendid; Infosüsteemid; personali teadmised. See on vajalik miinimum, mis võimaldab teil arhitektuuri põhielemente omavahel kooskõlastada. Kui aga eesmärgid, näitajad, organisatsiooni struktuur ja äriprotsessid on sageli juba kuidagi omavahel seotud, siis protsesside ja infosüsteemid sageli sellist suhet ei ole. Sellega seoses on paljude ettevõtete jaoks üheks prioriteediks üleminek äriarhitektuuri mudelitelt ja regulatsioonidelt infotehnoloogia nõuete määratlemisele ja sobiva IT-arhitektuuri ülesehitamisele.

Infolünga põhjuseks on info edastamine ärianalüütikutelt IT-spetsialistidele ning siinkohal võimaldab selliste arhitektuurielementide vormistamine nagu nõuded, IT funktsioonid, tehingud, andmestruktuur koos äriprotsessidega. peal see etapp Oluline on õigesti kasutada ettevõtte arhitektuuri kirjeldamise metoodikates (nt TOGAF) sisalduvaid soovitusi.

Seega on “infolünga” likvideerimiseks vajalik laiendada olemasoleva ettevõttearhitektuuri ja eelkõige äriarhitektuuri kirjeldust IT-arhitektuuri suunas, arvestades kasutatava kirjeldamismetoodika ühtsust. nii ärianalüütikud kui IT-spetsialistid. Sellel üleminekul äriprotsesside arhitektuuri kirjeldamiselt IT-arhitektuuri kirjeldamisele on oluline vormistada mitmeid arhitektuuri lisaelemente. Kõigepealt on vaja kirjeldada andmearhitektuuri, mis on üles ehitatud äriprotsessides kasutatava info ja dokumentide põhjal, mille järel tuleks kujundada rakenduste arhitektuur ja IT infrastruktuur.

Andmearhitektuuri ülesehitamiseks on vaja tuvastada peamised olemid ja koondada neile kogu äriprotsesside kirjeldusest kogutud teabe “kvant”. Praktika näitab, et selle probleemi lahendamiseks tuleks kasutada standardset andmete kirjeldamise metoodikat Entity-Relationship Model ERM, mille raames saab kogu info selgelt struktureerida. Järgmine etapp IT arhitektuuri vormistamine üleminek äriprotsesside arhitektuurilt ja andmearhitektuurilt rakendusarhitektuuri loomisele. Selles etapis on oluline määratleda automatiseerimiseks vajalike infosüsteemide klassid ning iga infosüsteemi moodulid. Rakenduse arhitektuuri kujundamise ja äriarhitektuuriga sünkroniseerimise aluseks on protsessikaart (kõikide ettevõtte äriprotsesside üldistatud esitus). Peamised infosüsteemide tüübid paiknevad rakendusarhitektuuri mudelil, mida on täpsemalt kirjeldatud infosüsteemi moodulite mudelil ja edasi kuni üksikute ekraanivormide tehingute tasemele.

Arhitektuuri teine ​​võtmeelement äriarhitektuuri ja IT-arhitektuuri vahelise seose seisukohast on infosüsteemi nõuded. Tegelikult on nõuete mudelid IT-lahenduse sihtfunktsioonid, mis on struktureeritud äriprotsesside või osakondade kaupa. Nendest nõuetest ja olemasolevatest äriprotsesside mudelitest lähtuvalt, samuti ehitatud andmemudeleid arvesse võttes kujundatakse uus (siht)rakenduse arhitektuur. Samas tuleb ülesannete lahendamisel kasutada lisaks ettevõtte arhitektuuri haldamise metoodikatele ka valdkonna standardeid. Näiteks telekommunikatsiooniettevõtete puhul saab aluseks võtta 2001. aastal TeleManagement Forumi poolt loodud uue põlvkonna operatsioonisüsteemi ja tarkvara (NGOSS) metoodika materjalid, mis sisaldab järgmisi mudeleid:

1. telekommunikatsiooniettevõtte eTOM (Enhanced Telecom Operations Map eTOM) tegevusmudel;
2. teabemudel telekommunikatsioon ettevõtetele (Ettevõtteülese teaberaamistiku jagatud teabe ja andmemudeli SID);
3. telekommunikatsiooniettevõtte rakendusraamistik ( Rakenduste raamistik Telekommunikatsiooni rakenduste kaart TAM ).

1.2. Rakendusarhitektuuri mudelid ja tööriistad

Rakenduse arhitektuur hõlmab üsna laia valdkonda, mis algab tuvastamisega, milliseid rakendussüsteeme ettevõte vajab äriprotsesside läbiviimiseks, ning hõlmab selliseid aspekte nagu projekteerimine, arendus (või hankimine) ja rakendussüsteemide integreerimine. Rakenduste arhitektuuris eristatakse reeglina kahte põhivaldkonda: ettevõtte rakendussüsteemide portfelli moodustamine ja haldamine ning rakendussüsteemide arendamine.

Ettevõtte rakenduste portfell on üldine plaan selle kohta, kuidas ettevõtte äriprotsesside vajadused rahuldavad rakendussüsteemide komplekti. See määrab iga rakenduse ulatuse ja prioriteedi, samuti selle, kuidas vajalik funktsionaalsus saavutatakse: süsteemi arendamise, valmisrakenduste ostmise, rakenduse rentimise või olemasolevate võimaluste integreerimise ja kasutamise kaudu. rakendusi. Rakendussüsteemide portfell kirjeldab rakendusi, mis on loodud täitma organisatsiooni funktsioone ning vahetama teavet ettevõtte klientide, tarnijate ja partnerite vahel. Samas kirjeldatakse ka kasutaja võimaliku suhtluse kanaleid rakendustega: veebibrauserid, “paksu” kliendi graafiline liides, mobiilseadmed jne.

Rakendussüsteemide arenduse valdkond kirjeldab neid tehnoloogiaid, mille abil ehitatakse süsteeme, jaotatakse need funktsionaalseteks komponentideks, luuakse liideseid, seadistusi, samuti selleks kasutatavaid malle, käsiraamatuid jms. See valdkond määratleb ka arendusprotsessi korralduse, selleks kasutatavad tööriistad, ettevõtte poolt vastuvõetava süsteemi arendustsükli, versioonikontrolli, konfiguratsioonihalduse, kasutatava vahevara, disainitööriistad. Valdkonna põhiülesanne on rakendussüsteemide loomise kulude vähendamine ja nende kvaliteedi parandamine, pakkudes ühtseid arengukäsitlusi. See omakorda toob kaasa languse kokku erinevad tehnilised stsenaariumid, mis on seotud arhitektuuri disaini, operatiivtoe, süsteemide integreerimise arhitektuuri, personali koolitusega. Siin on vaja rakendussüsteemide arhitektide kaasamist. Loomulikult on see valdkond erinevalt allhanke mudelist mõttekas eraldada ainult neile organisatsioonidele, kus toimub rakenduste sõltumatu arendus või täiustamine. Nende kommentaaride ja kahe valdkonna eraldamise põhjal rakendusarhitektuuri rakenduste portfellis ja arenduses võib öelda, et mõne uue süsteemi juurutamine ettevõttes, näiteks arveldamine, on osa ettevõtte rakenduste portfelli haldamisest. Samas kuuluvad arendusvaldkonda tehnoloogiad ja põhimõtted, mida süsteemi projekteerimisel ning selle juurutamisel ja hooldamisel kasutatakse. Edaspidi räägime rakenduste arhitektuurist, pidades eelkõige silmas rakendussüsteemide portfelli. Ideaalis peaks ettevõtte rakenduste portfell sisaldama praegust rakenduste komplekti ja mõnda mudelit, et mõista, milliseid rakendusi on vaja tulevikus uute äri- ja organisatsioonivajaduste rahuldamiseks. Samuti tuleks rakenduste portfellis täpsustada ettevõtte infotehnoloogilise keskkonna funktsionaalsete ja tehnoloogiliste (operatiivsete) komponentide vahelised seosed, s.o. selgitage, miks teatud tehnoloogiad kaasati ettevõtte rakendussüsteemide portfelli koostamise infrastruktuuri. See aspekt on oluline, sest infrastruktuuriinvesteeringud moodustavad olulise osa kapitalikuludest ja peavad olema hästi põhjendatud. Lõpuks peaks rakenduste portfell andma aimu, mis see rahaliste kulude osas maksma läheb ja kui kaua kulub organisatsioonil nende rakendussüsteemide abil soovitud tulevasesse olekusse migreerumine. Seega on rakendussüsteemide portfell integreeritud ettevõtte IS-i komplekt, mis vastab ettevõtte vajadustele ja sisaldab järgmisi aspekte:

1. Olemasolev rakendussüsteemide portfell. See on olemasolevate rakenduste kataloog ja komponent, mis kajastab nende seoseid nende toetatavate äriprotsessidega, liideseid teiste süsteemidega, kasutatavat ja nõutavat teavet ning kasutatavaid infrastruktuuri mustreid. Et see oleks tõeliselt kasulik tööriist, peab see aitama tuvastada ka need portfelli elemendid, mida saab kogu ettevõttes taaskasutada, ning soodustama sellist taaskasutamist.
2. Planeeritud rakendussüsteemide portfell. Esindab funktsionaalsust, mis on vajalik äri- ja ettevõtteteabe arhitektuuri soovitud oleku tagamiseks.
3. Rändeplaan. IT-projektide raames liikumine praeguselt rakendussüsteemide portfellilt tulevasse. Projekte saab ühendada ka projektiportfellideks. Rakendussüsteemide portfoolio planeerimise esimene samm on hinnata portfelli hetkeseisu ja seda, kuidas see sobib organisatsiooni vajadustega strateegilisest ja tehnoloogilisest vaatenurgast, s.t. ülesannete, äristrateegiate ning tehnilise seisu ja tehnoloogiate ettevõttes kasutamise strateegiate seisukohalt. Äristrateegiatele vastavust hinnatakse rakendussüsteemide panuse põhjal äritulemuste saavutamisse, mille määrab ettevõtte äriarhitektuur. Tehnoloogia vastavust hinnatakse analüüsi põhjal, kuidas rakendussüsteemid vastavad ettevõtte tehnoloogilises arhitektuuris omaksvõetud põhimõtetele ja tehnoloogilistele standarditele. Portfelli väärtustamiseks on erinevaid viise ja erinevad klassifikatsioonid ettevõtte rakendussüsteemid. Üheks võimalikuks mudeliks rakendatud süsteemide portfelli hindamisel on nende hindamine kahe kriteeriumi – äriväärtuse ja tehnilise seisukorra – alusel. Portfelli hindamine teenib Alguspunkt probleemsete kohtade ja võimaluste väljaselgitamisel ärivajaduste paremaks rahuldamiseks ning otsustamisel, kas investeerida uutesse süsteemidesse või uuendada olemasolevaid. Selle hindamise tulemusena jagunevad rakendussüsteemid ühte neljast võimalikust kategooriast:
   1. süsteeme ähvardab dekomisjoneerimine (asendamine) või konsolideerimine;
   2. ümberhindamist või ümberpositsioneerimist vajavad süsteemid;
   3. uuendamist vajavad süsteemid;
   4. hooldust ja arendust vajavad süsteemid.

Tehnilist seisukorda hinnatakse mitmete näitajate järgi, sealhulgas andmete täpsus ja korrektsus, arhitektuur, koodi struktuur, reageerimisvõime, seisakud, hooldustase, aruandlusvõime jne. Süsteemi väärtus ärilisest seisukohast viitab süsteemi võimele toetada ettevõtte, osakonna või protsessi põhifunktsioone. Järgmises numbris antakse iga süsteemide kategooria omadused vastavalt sellele klassifikatsioonile.

1.3. Kihid arhitektuuris

Kihtide kontseptsioon on üks levinumaid mudeleid, mida arendajad kasutavad tarkvara keerukate süsteemide jaotamiseks lihtsamateks osadeks. Näiteks arvutisüsteemide arhitektuurid eristavad programmeerimiskeele koodi kihte, operatsioonisüsteemi funktsioone, seadme draivereid, protsessori käsukomplekte ja sisemist kiibiloogikat. Keskkonnas võrgustumine FTP-protokoll töötab TCP-protokolli alusel, mis omakorda töötab Etherneti protokolli "üleval" asuva IP-protokolli peal. Vaatleme siis tarkvarasüsteemide arhitektuuri kihtide vastu huvi tundmise peamisi põhjuseid:

Kihid vormistatakse kergesti. On intuitiivselt selge, et kui süsteem on jagatud mitmeks kihiks, siis kiht n on komponent või süsteemi komponentide kogum, mis kasutab ainult kihi n-1 komponente ja mida saavad kasutada ainult kihi n + 1 komponendid.

Kihtidel on lihtne ja kirjeldav semantika. Üldiselt tähistavad kihid tarkvarasüsteemi arhitektuuris abstraktsioonitaset. Kiht n+1 kasutab kihti n, mistõttu kihi n+1 mõistete abstraktsioon ei ole vähemalt kihi n omast madalam ning ideaaljuhul, kui süsteemi arhitektuur on efektiivne, peaks selle abstraktsioonitase olema kõrgem. Vastavalt sellele peidab (kapseldab) kiht n sellel kihil määratletud mõistetega töötamise loogikat, võimaldades seega kihil n + 1 rakendada tööd keerukamate kontseptsioonidega, korraldada keerukamat loogikat kasutades alloleva kihi väljendusvahendeid.

Kihid on laialt levinud. Tõepoolest, üsna suur hulk tarkvarasüsteeme, eriti kui tegemist on tarkvarasüsteemid ettevõtte mastaabis (ettevõttesüsteemid) on kihiline struktuur. Muidugi tuleb üsna sageli ette olukordi, kus reeglina rikutakse süsteemi ranget kihilist ülesehitust, see on arhitektuurse erosiooni (arhitektuurse defekti) tagajärg ja selle kõrvaldamine võib enamikul juhtudel tuua käegakatsutavat kasu (neid aspekte käsitletakse allpool ).

Alternatiivne rakendamine. Aluskihtidele saab valida alternatiivse teostuse, mille ülemise kihi komponendid on võimelised töötama ilma aluskihtide muutusteta, eeldusel, et liidesed on säilinud.

Kihtide vahelist sõltuvust, st tegelikult alumiste kihtide pakutavaid liideseid ülemisele, saab minimeerida. Selline liideste minimeerimine suurendab süsteemi paindlikkust.

Arhitektuurikihtide skeemil on ka teatud puudused:

kaskaadsed muutused. Kihid suudavad kapseldada hästi palju, kuid mitte kõike: ühe kihi muutmine nõuab mõnikord teiste kihtide kaskaadmuutusi. Klassikaline näide ettevõtte tarkvararakenduste valdkonnast: andmebaasi tabelisse lisatud väli tuleb taasesitada graafilises liideses ja peab leidma igas vahekihis vastava kuva.

Jõudluse langus. Üleliigsete kihtide olemasolu vähendab sageli süsteemi jõudlust. Kihist kihti liikudes teisendatakse andmeid tavaliselt ühest esitusest teise. Sellele vaatamata võib aluseks olevate funktsioonide kapseldamine sageli saavutada väga olulise eelise. Näiteks tehingukihi optimeerimine annab tavaliselt parema jõudluse kõigi selle kohal olevate kihtide jaoks.

Süsteemianalüüsi jaoks võib ettevõtte arhitektuuri vaadelda kahes aspektis:

1. staatiline - vastavalt panga seisundile mingil kindlal ajahetkel;
2. dünaamiline - kui panga ülemineku (migratsiooni) protsess praegusest seisundist mõnda soovitud olekusse tulevikus.

Staatikas käsitletav ettevõtte arhitektuur koosneb järgmistest elementidest:

1. missioon ja strateegia, strateegilised eesmärgid ja eesmärgid;
2. äriarhitektuur;
3. süsteemi arhitektuur.

Vaadates dünaamilise ettevõtte arhitektuurina, on see sidus, sidus tegevuskava ja koordineeritud projektid, mis on vajalikud organisatsiooni praeguse arhitektuuri muutmiseks olekusse, mis on määratletud pikaajalise eesmärgina, mis põhineb praegusel ja kavandataval.ärilistel eesmärkidel ja äriprotsessid organisatsioonid.

Seega kirjeldatakse ettevõtte arhitektuuri üldiselt järgmiste järjestikku sõltuvate jaotistega:

1. sõnastatud panga missioon ja strateegia, strateegilised eesmärgid ja eesmärgid;
2. äriarhitektuur praeguses (nagu on) ja kavandatud (olemas) olekus,
3. süsteemi arhitektuur praeguses (nagu on) ja kavandatud (olemas) olekus;
4. tegevuskavad ja projektid üleminekuks praegusest seisust kavandatule.

Seega on kavandatud süsteemiarhitektuur "olema" arhitektuur ainult ettevõtte arengu teatud etapis.

Samas ei tähenda naasmine missiooni strateegilisele tasemele ning strateegilistele eesmärkidele ja eesmärkidele vajadust missiooni ja strateegiat üle vaadata. Kuid iga tsükli lõpus viiakse tingimata läbi väljatöötatud ja rakendatud meetmete tõhususe analüüs, vajadusel teisel iteratsioonil kohandatakse äriarhitektuuri, süsteemiarhitektuuri ja rakendatakse uusi migratsiooniplaane. Igal ajahetkel võib olla mitu tsüklit, iga selline tsükkel ei pruugi mõjutada kogu ettevõtet tervikuna, tsükkel võib mõjutada teatud valdkondi, teatud äriprobleeme ja seda saab kajastada eraldi projektina.

Etapiviisilise migratsiooniplaaniga on saavutatud tulemuste fikseerimiseks võimalik ehitada vahepealset (migratsiooni) ühte või mitut arhitektuuri. Missioon, strateegia ja ärieesmärgid määravad ettevõtte arengu suuna ning seavad pikaajalised eesmärgid ja eesmärgid.

Ettevõtte arhitektuuris tuleks eristada järgmisi kihte:

1. Front office (Front-Office)

Esindus (esindus)välise raamatupidamissüsteemina (inettevõtte äriarhitektuur- on kollektsioonäriprotsessid, protseduurid, normdokumendid (määrused), teatmeteosed, trükitud vormid, organisatsioonilised ja personaliüksused, mis pakuvad otsest suhtlust kliendiga ettevõtte poolelt:

1. Vastuvõtmine ja sisend edasiseks töötlemiseks esmased dokumendid,
2. Printimine ja kliendile teabe ja dokumentide edastamine,
3. klientidele helistamine ja klientidele infosõnumite saatmine,
4. Sissetulevate telefonikõnede, päringute vastuvõtmine ja info edastamine.

Front-Office (Front office) välise raamatupidamissüsteemina (inettevõtte süsteemi arhitektuuron automatiseerimisele suunatud infosüsteemide kogum, sealhulgas andmebaasid ja kataloogidäriprotsessidsuhtlemine kliendiga.

1. Keskkontor (Middle-office)

Keskkontor sisse äriarhitektuur - see on äriprotsesside, protseduuride, regulatiivsete dokumentide (määruste), teatmeteoste, trükitud vormide, organisatsiooni- ja personaliüksuste kogum, mis pakuvad ettevalmistusi ja otsuste tegemist.

Näited keskmiste kontorijaotuste kohta:

turvateenistuse laenuvõtja kontrollimise üksus,

Riskijuhtimise osakond.

Keskkontor sisse süsteemi arhitektuur -see on infosüsteemide komplekt, sealhulgas andmebaasid ja kataloogid, mille eesmärk on automatiseerida ettevalmistamise ja otsuste tegemisega seotud äriprotsesse.

Näited keskmise kontori infosüsteemidest:

positsioonide arvestussüsteem,

laenuvõtja kontrollimise süsteem krediidiajaloo büroos,

Laenutaotluse skoori arvutamise süsteem.

1. Back Office

Back office (back office) kuidas sisemine süsteem raamatupidamine (inäriarhitektuur) ettevõtted on äriprotsesside, protseduuride,normdokumendid (määrused), teatmeteosed, trükitud vormid, organisatsiooni- ja personaliüksused, mis rakendavad toimingute päeviku (registri) arvestust. Tavaliselt, registriraamatupidamine on tehingute päevik osapooltega, pole seotud raamatupidamiskontod, ei ole kahepoolne.

Tagakontor sisse süsteemi arhitektuurettevõtted on infosüsteemide kogum, sealhulgas andmebaasid ja kataloogid, mis rakendavad toimingute ajakirja (registri) arvestust.

1. Raamatupidamine

ettevõtte raamatupidamine ( äriarhitektuur) on äriprotsesside, protseduuride, regulatiivsete dokumentide (määruste), teatmeteoste, trükitud vormide, organisatsiooni- ja personaliüksuste kogum, mis rakendavad raamatupidamist ja aruandlust vastavalt RAP-ile (Raamatupidamise eeskirjad - Venemaa raamatupidamisstandardid) ja IFRS-ile ( Rahvusvahelised standardid finantsaruandlus), ettevõtte bilansi pidamine.

1. Infoladu (DWH)
2. Aruandlus

Aruandmine aadressile süsteemiarhitektuur - infosüsteemide kogum, sealhulgas andmebaasid ja kataloogid, mis automatiseerivad infolao andmete põhjal aruannete koostamist.

Näited aruandlussüsteemidest:

juhtimisaruannete süsteem,

Analüütiline aruandlussüsteem,

Süsteem põhinäitajadäriüksuste tõhusus,

Laenutaotluse skoori arvutamise näitajate genereerimise süsteem.

Bibliograafia

1. Vassiljev R. B., Kaljanov G. N., Levochkin G. A., Lukinova O. V. Strateegiline juhtimine infosüsteemid; Interneti-infotehnoloogiaülikool, Binom. Teadmiste labor - Moskva, 2013 . - 512 c.
2. Gritsenko Yu. B. Ettevõtte arhitektuur: õpik / Gritsenko Yu. B. 2011. 256 lk.
3. Danilin A.V., Slyusarenko A.I., Koolituskursus Ettevõtte arhitektuur [Elektrooniline ressurss] - Juurdepääsurežiim:http://www.intuit.ru/department/itmngt/entarc/
4. Kalyanov G.N. Äriprotsesside modelleerimine, analüüs, reorganiseerimine ja automatiseerimine. Õpik: M.: Rahandus ja statistika, 2006.

17. lk

Muud seotud tööd, mis võivad teile huvi pakkuda.vshm>
803.		Külalislahkuse arhitektuur	36,04KB
	Hotellide ehitamise ja majutuse arhitektuurilised aspektid. Hotellide interjööri ja disaini roll hotellipakkumises. Sissejuhatus Hotellide eripära seisneb nende objektide funktsioonide mitmekesisuses. soodsad tingimused inimeste elutegevus hotellides tagatakse mugavuse loomisega nii hotellihoones endas kui ka sellega külgneval territooriumil.
17390.		Veliki Novgorodi arhitektuur	324,25 KB
	Valitseb seisukoht, et vanalinn on nn Asula, mis asub Volhovi paremal kaldal, tänapäevasest linnast kahe kilomeetri kaugusel. Selle linna arhitektuuriga sügavamalt tutvumiseks valiti töö teemaks XI-XV sajandi Novgorodi arhitektuur. Selliste tööde tehnika seisnes selles, et mustaks tehtud vasklehtedele kanti lõikuriga muster ja selle soontesse sulatati kuldtraat. Selle võib omistada kõige iidsemale: tahvel, millele see on kirjutatud, on mitmete tunnuste ja iseloomu poolest väga vana...
19556.		Stalinistlik vertikaalism ja arhitektuur	24,72 KB
	Et mõista nõukogude tee enda eripära ning nõukogude arhitektuuri kujunemist ja sisu, on vaja uurida piiranguid ja regulatsioone, mida üleriigiline organisatsioon kehtestas. ametialane tegevus konkreetsete meistrite mõtteviisil. ja teisalt stalinistliku impeeriumi stiilis korterite plaanid, mis sisaldavad terrasse, majahoidjate elutubasid jne: Neoklassitsism Neoklassitsism on nõukogude kunstiajaloos omaks võetud termin, mis viitab erinevatele sotsiaalsetele orientatsioonidele ja ideoloogilistele ...
17255.		Moskva templiarhitektuur	595,99 KB
	Kolmainu kiriku telliskiviseinte särav värv, mida lahkasid elegantsed valgest nikerdatud kivist ja värvilistest glasuurplaatidest dekoratiivsed ääristused, valge saksa raua kate, kuldsed ristid roheliste kahhelkividega kuplitel, kõik kokku lõid vastupandamatu mulje. ..
13405.		Vana-Babüloonia kuningriigi arhitektuur	528,04 KB
	Selle keskus oli Babüloni linn Babili tähendab selle jumala väravat, kelle kuningad II aastatuhandel Vana-Babüloonia kuningriigi õitseaeg langes I Babüloonia dünastia kuuenda kuninga Hammurapi valitsusajale. Tema alluvuses muutus Babülon väikesest linnast suurimaks majanduslikuks poliitiliseks ja Kultuurikeskus Aasia esiosa.
7046.		Arvuti arhitektuur ja struktuur. Von Neumanni põhimõte	9,14 KB
	Arvuti on suhteliselt odav universaalne mikroarvuti, mis on mõeldud ühele kasutajale. Kaasaegsed arvutid on loodud avatud arhitektuuri põhimõttel.
6695.		Andmebaasi arhitektuur. Füüsiline ja loogiline sõltumatus	106,36 KB
	See annab järgmised andmebaasiandmebaasi ja DBMS-i definitsioonid: BnD andmepank on tarkvara tehnilise keele organisatsiooniliste ja metoodiliste tööriistade spetsiaalselt organiseeritud andmebaaside süsteem, mis on loodud andmete tsentraliseeritud kogumise ja kollektiivse mitmeotstarbelise kasutamise tagamiseks. Andmebaas DB on nimeline andmekogu, mis kajastab objektide olekut ja nende seoseid vaadeldavas teemavaldkonnas. Andmebaasihaldussüsteem DBMS on keele- ja ...
18392.		Haridusliku ja metoodilise kompleksi väljatöötamine erialale "Arvutiarhitektuur"	606,23 KB
	Seejärel laienes kasutajate ring eelkõige tänu teadlastele, kes kasutasid masineksperimentide läbiviimiseks arvuteid. Elektrooniline õpik on õppetoode, mida saab reprodutseerida ainult arvutiteaduse vahenditega, sealhulgas arvutiga, mis vastab heakskiidetud koolitusprogrammile või autori poolt kavandatava kursuse jaoks välja töötatud programmile ja millel on tavapärase õpikuga võrreldes põhimõtteliselt uued omadused. elektrooniline õpik võib olla mõeldud ...
9225.		KOHALIKE ARVUTIVÕRKUDE ARHITEKTUUR JA KOMPONENDIBAAS LA	150,96 KB
	Saabunud 21. sajand ja kolmas aastatuhat tõstatavad üha enam küsimust: mida lennukid(LA) kas hävitajalennundus annab paremuse õhus? Esitatud küsimusele järgneb ühemõtteline vastus – neist saavad järgmise, 5. põlvkonna, lennunduse reaktiivajastu hävitajad. Lennukipõlvkondade vahele on raske ja mitte alati võimalik selget piiri tõmmata. Jah, ja põlvkondade vahetus on üsna aeglane protsess.
21769.		Inteli protsessorid, protsessori arhitektuur, kiibistikud ja nende omadused	95,27KB
	Keskprotsessor (mikroprotsessor, CPU) - arvuti riistvara, mis vastutab programmide poolt määratud aritmeetiliste toimingute tegemise ja kõigi arvutiseadmete töö koordineerimise eest. Protsessor on spetsiaalselt kasvatatud pooljuhtkristall, millel asuvad transistorid.