Este nevoie de traducător. Problema este complicată și mai mult că fiecare dintre cele patru tipuri (PAEI) pune înțelesuri diferite cuvintelor „a fi”, „a vrea” și „a fi cerut” în funcție de unicitatea lor. propria poză Un antreprenor, de regulă, ia decizii, percepând

Necesar: Cunoștințe de economie Pentru a te pregăti pentru o carieră în relații publice, trebuie să obții o educație solidă în economie. Fiind angajat ca profesionist, va trebui să se ocupe de aspecte financiare

Pasul 6: Aplicarea arhitecturii Orice organizație care dorește să utilizeze o arhitectură de proces trebuie să stabilească disciplina necesara. Aceasta înseamnă că toate proiectele relevante trebuie să ia în considerare arhitectura și să identifice unde se abate de la convenit

Exemplu de obiective generale de arhitectură: Obținerea unei creșteri de 200% a veniturilor din vânzări în următorii trei ani; asigura o crestere a profitului de 150% in urmatorii trei ani Principii generale: valorile noastre corporative: cel mai bun raport calitate-pret

De ce avem nevoie de conceptul de „aprobare”? De ce folosim termenul „afirmare”? Dacă scrie „lipsește o afirmație”, atunci un element important (cauză, efect, scop sau sarcină intermediară etc.) nu este menționat în arborele logic. Folosind

Ce este necesar pentru asta? Dacă există o dorință, nu este deloc dificil să creezi beneficiile enumerate. Luați, de exemplu, împărtășirea abilităților și experienței în cadrul unei unități. Acest lucru necesită o unitate care să funcționeze bine, cu capacitatea de a

Capitolul 1 De ce aveți nevoie de un model de arhitectură de afaceri: Declarații de probleme de modelare standard a proceselor de afaceri O mare parte din rațiunea dezvoltării unui model de arhitectură de afaceri se bazează pe înțelegerea factorilor care împing o întreprindere să caute optimizare.

O anumită experiență necesară Aceste planuri antreprenoriale ne-au adus amintiri din prima noastră experiență cu VC.

Este nevoie de un geniu. Abilitatea medie nu mai este suficientă. Ne dezvoltăm. Ceea ce este mediu astăzi va fi sub medie mâine. Nu suntem pe un carusel de târg, unde este suficient doar să ne ținem de un inel de cupru pentru a nu cădea. Înaintăm constant. merge mai departe

Software-ul TSF din afara nucleului constă din aplicații de încredere care sunt utilizate pentru implementarea caracteristicilor de securitate. Rețineți că bibliotecile partajate, inclusiv modulele PAM în unele cazuri, sunt folosite de aplicațiile de încredere. Cu toate acestea, nu există nicio instanță în care biblioteca partajată în sine să fie tratată ca un obiect de încredere. Comenzile de încredere pot fi grupate după cum urmează.

• Inițializarea sistemului
• Identificare și autentificare
• Aplicații de rețea
• procesare în lot
• Managementul sistemului
• Audit la nivel de utilizator
• Suport criptografic
• Suport pentru mașini virtuale

Componentele de execuție ale nucleului pot fi împărțite în trei părți: nucleul principal, firele de execuție ale nucleului și modulele nucleului, în funcție de modul în care vor fi executate.

• Nucleul de bază include codul care este executat pentru a furniza un serviciu, cum ar fi deservirea unui apel de sistem al utilizatorului sau deservirea unui eveniment de excepție sau întrerupere. Majoritatea codului kernel-ului compilat se încadrează în această categorie.
• Fire de nucleu. Pentru a efectua anumite sarcini de rutină, cum ar fi golirea memoriei cache a discului sau eliberarea memoriei prin schimbarea cadrelor de pagină neutilizate, nucleul creează procese interne sau fire de execuție. Threadurile sunt programate la fel ca procesele obișnuite, dar nu au un context în modul non-privilegiat. Firele nucleului îndeplinesc anumite funcții ale limbajului C kernel. Firele de nucleu rezidă în spațiul kernelului și rulează doar în modul privilegiat.
• Modulul nucleului și modulul nucleului driverului de dispozitiv sunt bucăți de cod care pot fi încărcate și descărcate în și din nucleu, după cum este necesar. Ele se extind funcţionalitate nucleul fără a fi nevoie să reporniți sistemul. Odată încărcat, codul obiect al modulului kernel poate accesa alte coduri și date kernel în același mod ca și codul obiect al nucleului legat static.

Nucleul este format din subsisteme logice care oferă diverse funcționalități. Chiar dacă nucleul este singurul program executabil, diversele servicii pe care le oferă pot fi separate și combinate în diferite componente logice. Aceste componente interacționează pentru a oferi funcționalități specifice. Nucleul constă din următoarele subsisteme logice:

• Subsistemul de fișiere și subsistemul I/O: Acest subsistem implementează funcții legate de obiectele sistemului de fișiere. Funcțiile implementate le includ pe cele care permit unui proces să creeze, să mențină, să interacționeze cu și să șteargă obiecte ale sistemului de fișiere. Aceste obiecte includ fișiere obișnuite, directoare, legături simbolice, legături rigide, fișiere specifice dispozitivului, conducte numite și socluri.
• Subsistemul de proces: Acest subsistem implementează funcții legate de controlul procesului și controlul firelor. Funcțiile implementate permit crearea, programarea, executarea și ștergerea proceselor și subiectelor firelor.
• Subsistemul de memorie: Acest subsistem implementează funcții legate de gestionarea resurselor de memorie a sistemului. Funcțiile implementate includ cele care creează și gestionează memoria virtuală, inclusiv gestionarea algoritmilor de paginare și a tabelelor de pagini.
• Subsistemul de rețea: Acest subsistem implementează socket-uri pentru domeniul UNIX și Internet, precum și algoritmii folosiți pentru programarea pachetelor de rețea.
• Subsistemul IPC: Acest subsistem implementează funcții legate de mecanismele IPC. Caracteristicile implementate includ cele care facilitează schimbul controlat de informații între procese, permițându-le să partajeze date și să sincronizeze execuția lor atunci când interacționează cu o resursă partajată.
• Subsistemul Modulului Kernel: Acest subsistem implementează infrastructura pentru a suporta module încărcate. Funcțiile implementate includ încărcarea, inițializarea și descărcarea modulelor nucleului.
• Extensii de securitate Linux: Extensiile de securitate Linux implementează diverse aspecte de securitate care sunt furnizate în întregul nucleu, inclusiv cadrul Linux Security Module (LSM). Cadrul LSM servește drept bază pentru module care vă permit să implementați diverse politici de securitate, inclusiv SELinux. SELinux este un subsistem logic important. Acest subsistem implementează funcțiile obligatorii de control al accesului pentru a obține accesul între toți subiecții și obiectele.
• Subsistemul driver de dispozitiv: Acest subsistem implementează suport pentru diverse dispozitive hardware și software printr-o interfață comună, independentă de dispozitiv.
• Subsistemul de audit: Acest subsistem implementează funcții legate de înregistrarea evenimentelor critice pentru securitate în sistem. Funcțiile implementate includ cele care captează fiecare apel de sistem pentru a înregistra evenimente critice pentru securitate și cele care implementează colectarea și înregistrarea datelor de control.
• Subsistemul KVM: Acest subsistem implementează întreținerea ciclu de viață mașină virtuală. Efectuează completarea declarațiilor, care este utilizată pentru declarațiile care necesită doar verificări minore. Pentru completarea oricărei alte instrucțiuni, KVM invocă componenta de spațiu utilizator a QEMU.
• Crypto API: Acest subsistem oferă o bibliotecă criptografică internă a nucleului pentru toate componentele nucleului. Oferă primitive criptografice pentru apelanți.

Nucleul este partea principală a sistemului de operare. Interacționează direct cu hardware-ul, implementează partajarea resurselor, oferă servicii partajate pentru aplicații și împiedică aplicațiile să acceseze direct funcțiile dependente de hardware. Serviciile oferite de nucleu includ:

1. Managementul execuției proceselor, inclusiv operațiunile de creare, încetare sau suspendare a acestora și schimbul de date între procese. Acestea includ:

• Programarea echivalentă a proceselor pentru a rula pe CPU.
• Separarea proceselor din CPU folosind modul de partajare a timpului.
• Execuția procesului în CPU.
• Suspendați nucleul după expirarea cuantumului său de timp.
• Alocarea timpului nucleului pentru a executa un alt proces.
• Reprogramarea timpului nucleului pentru a executa un proces suspendat.
• Gestionați metadatele legate de securitatea procesului, cum ar fi UID-uri, GID-uri, etichete SELinux, ID-uri de caracteristică.

• Permisiunea acordată de nucleu proceselor de a partaja o parte din spațiul lor de adrese în anumite condiții; totuși, făcând acest lucru, nucleul protejează spațiul de adrese propriu al procesului de interferențe externe.
• Dacă sistemul nu dispune de memorie liberă, nucleul eliberează memorie prin scrierea temporară a procesului în memoria de nivel al doilea sau în partiția de swap.
• O interacțiune consistentă cu hardware-ul mașinii pentru a stabili o mapare a adreselor virtuale la adrese fizice care stabilește o mapare între adresele generate de compilator și adresele fizice.

• Setați limite pentru resursele configurate de aplicația de emulare pentru această mașină virtuală.
• Rularea codului de program al mașinii virtuale pentru execuție.
• Gestionarea opririi mașinilor virtuale fie prin terminarea instrucțiunii, fie prin întârzierea finalizării instrucțiunii pentru a emula spațiul utilizatorului.

• Alocarea memoriei secundare pentru stocarea și recuperarea eficientă a datelor utilizatorului.
• Alocarea memoriei externe pentru fișierele utilizator.
• Utilizați spațiul de stocare nefolosit.
• Organizarea structurii sistemului de fișiere (folosind principii clare de structurare).
• Protecția fișierelor utilizatorului împotriva accesului neautorizat.
• Organizarea accesului controlat al proceselor la dispozitivele periferice, cum ar fi terminale, unități de bandă, unități de disc și dispozitive de rețea.
• Organizarea accesului reciproc la date pentru subiecți și obiecte, oferind acces controlat pe baza politicii DAC și a oricărei alte politici implementate de LSM încărcat.

Am început să lucrez cu o companie pe tema arhitecturii întreprinderii (Arhitectura întreprinderii) și am decis să-mi corectez înțelegerea despre EA, pentru a o face mai clară și mai simplă. Publicarea din 1987 a lui John A. Zachman „A Framework for Information Systems Architecture” este în general creditată drept data de naștere a EA, deși termenul în sine a apărut în scrierile anterioare. În ciuda faptului că arhitectura întreprinderii este un lucru destul de tânăr, aceasta a reușit deja să-și strice reputația. Ca orice altă arhitectură, arhitectura întreprinderii nu este bine definită (vezi, de exemplu, 10 definiții ale arhitecturii întreprinderii), dar are un număr mare de proiecte eșuate (vezi Gartner identifică zece capcane în arhitectura întreprinderii sau 8 motive pentru care programele de arhitectură întreprindere eșuează) . De obicei, după finalizarea unui proiect de arhitectură întreprindere, puteți auzi următoarea frază: Am desenat toate imaginile necesare, dar habar n-avem cum să obținem măcar un anumit beneficiu de pe urma ei.". Prin urmare, să vorbim totul de la bun început.

Și vom începe de departe. Există două puncte de vedere asupra utilităţii tehnologiei informaţiei. Conform primului punct de vedere, tehnologiile informaţionale fac posibilă creşterea productivităţii muncii, adică. oamenii vor lucra mai eficient dacă activitățile lor sunt automatizate. Există și un punct de vedere opus, exprimat, de exemplu, în cărți precum „Strălucirea și sărăcia tehnologiei informației. De ce IT-ul nu este un avantaj competitiv” de Nicholas J. Carr sau „What Business Wants from IT” de Terry White. În mod surprinzător, ambele puncte de vedere sunt corecte. Dar să restrângem cercul raționamentului nostru și să vorbim nu despre tehnologia informației în general, ci doar despre aplicațiile de afaceri, adică. sisteme care automatizează procesele de afaceri ale organizației. La început, dezvoltarea și implementarea unor astfel de sisteme aduce un efect tangibil. Când diferiți angajați încep să reflecte operațiuni similare într-o singură bază de date accesibilă prin rețea din diferite locuri de muncă, interacționează între ei prin astfel de soluții și se specializează în anumite funcții, productivitatea acestora crește. Acest lucru este mult mai bine decât să ne suni unul pe altul la telefon sau să schimbi mesaje încărcate emoțional e-mail. Prin urmare, încep să fie automatizate diverse alte procese, poate nu atât de frecvente și nici atât de necesare. Eficiența unei astfel de automatizări nu este atât de mare. Merele de jos au fost deja smulse și trebuie să inventăm modalități mai sofisticate de a obține rezultatul. La un moment dat, costurile utilizării aplicațiilor de afaceri devin mai mari decât beneficiile derivate din utilizarea lor, dar nu mai este posibilă oprirea locomotivei overclockate. Motivul acestui prag este complexitatea organică a sistemelor informaționale (complexitatea IT). De fapt, la un moment dat pur și simplu devenim confuzi cu privire la ceea ce facem și Sisteme de informare ajută-ne să fim mai confuzi. Arhitectura (întreprinderea) este doar o modalitate de a controla complexitatea inerentă sistemelor, de a ține cont de o imagine mai mult sau mai puțin adecvată, permițând totuși gestionarea acestei complexități.

Următoarea problemă este că o astfel de imagine nu poate fi pregătită pentru viitor. (În acest moment, arhitecții vă vor spune o mulțime de cuvinte la modă despre diferite puncte de vedere, puncte de vedere, părți interesate și preocupări). Prin urmare, pentru a răspunde la întrebarea „De ce facem arhitectură de întreprindere?” necesare încă de la început. Permiteți-mi să subliniez cele mai frecvente trei răspunsuri:

1. Avem o strategie care răspunde la întrebarea ce ne dorim, dar nu știm cum să o facem.
2. Nu avem o strategie, dar avem un val de cereri de schimbare pe care nu le putem face față.
3. Informațiile despre activitățile noastre sunt contradictorii și nu avem timp să ne dăm seama în fiecare caz de ce se întâmplă acest lucru.

(Dacă crezi că mai sunt alții variante frecvente vă rugăm să-l notați în comentarii).

În primul caz, trebuie să facem Strategii –> Plan. Este despreîn principal despre strategia de afaceri. De obicei arată ca un set de niște delte între ceea ce ai și ceea ce îți dorești, exprimate în termeni destul de simpli: cota de piață în ceea ce privește veniturile, baza de clienți etc. În general, știi, o strategie este un document despre aricii de mâine. , care vor deveni șoarecii de astăzi. Despre ce ar trebui făcut în acest caz, voi scrie mesaj separat, dar deocamdată câteva cuvinte despre cum să organizăm un astfel de proces. În opinia mea, forma organizatorică a dezvoltării arhitecturii întreprinderii este un proiect care durează 8-16 săptămâni. Metodologie - TOGAF ADM, etc. Trebuie atrase resurse, în principal interne. Rezultatele proiectului sunt: ​​o foaie de parcurs, o listă de modificări organizaționale și de proces, riscuri, propuneri de monitorizare și gestionare a mișcării într-o direcție dată. În general, se numește tot ceea ce se face în proiectele tradiționale în faza de planificare cuvânt frumos Planul principal. Despre echipa unui astfel de proiect, un set de activități și artefacte - aceleași într-unul dintre următoarele mesaje.

Opțiunea numărul 2: Managementul schimbării. În loc de o strategie, există un set de obiective diferite pentru diferiți clienți de afaceri. Unii trebuie să reducă costurile, alții trebuie să aducă noi produse și servicii pe piață, iar alții trebuie să îmbunătățească satisfacția clienților (consultați Despre arhitectura întreprinderii pe scurt). Toți clienții sunt oameni respectați și toată lumea are nevoie de ajutor. Dar complexitatea a crescut deja și nu înțelegem cum să ajutăm pe toți în același timp. O modalitate simplă și greșită de a-i alinia pe toată lumea cu un nume frumos precum " o singură foaie priorități", și metoda de distribuire a sarcinilor între sistemele informaționale - "Cash desk gratuit!" - cine o poate face mai repede si mai ieftin, ii vom incredinta. Soluția corectă este o clasificare multifactorială a interogărilor, cu alte cuvinte, o taxonomie. Metodologie - în stilul lui Zachman. Organizare - crearea unei unități funcționale. Într-o notă anterioară Analiștii de afaceri sunt prieteni, vecini sau rude îndepărtate? Am scris că odată cu apariția și adoptarea celei de-a treia versiuni a BABOK, analiștii de afaceri vor putea face această muncă. Dar până acum nu pot. În prezent, analiștii de afaceri sunt capabili să răspundă la întrebarea „Ce trebuie făcut?”, iar arhitecții de soluții pot răspunde la întrebarea „Cum se face?”. De asemenea, necesită un răspuns la întrebarea „De ce?”, modul în care această modificare este legată de produsele și procesele existente, alte modificări, aplicații.

Și, în sfârșit, situația în care complexitatea a câștigat deja și liderii organizației au conștientizarea acestui lucru. cam aceleași Poze, care nu sunt acolo atunci când sunt necesare pentru a rezolva rapid o problemă controversată și care zac încărcături complet inutile în restul timpului. Această situație este vorba despre un depozit de arhitectură. Pot exista imagini care descriu arhitectura pe undeva, dar dacă nu pot fi obținute într-un minut sau două, atunci managerul, și orice manager, nu o va face el însuși, ci va cere altcuiva să obțină poza („Apelați arhitectul aici !"). Dacă o persoană nu lucrează cu aplicația cel puțin o dată la 1-2 săptămâni, atunci nu o va face deloc. Dacă dezvoltatorul sistemului informațional nu are API-uri simple, ușor de înțeles și gata de utilizat pentru obținerea unor tipuri de clienți, o listă de sucursale, o structură organizațională funcțională etc., atunci cu siguranță va adăuga o altă placă în sistemul său informatic. , în care va forța utilizatorii să introducă din nou date din aceste directoare. Nu cunosc niciun instrument EA care este la fel de potrivit pentru demonstrație imagini frumoase manageri de top și, în același timp, posedă interoperabilitate înnăscută pentru integrarea în aplicații de afaceri reale. Sper ca asa ceva, mai devreme sau mai tarziu, sa apara. Și apoi opțiunea numărul trei se va transforma într-un proiect simplu pentru implementarea unui sistem informațional și utilizarea și dezvoltarea ulterioară a acestuia.

De continuat (povestea arhitecturii întreprinderii)!

Al doilea articol despre conștiința mitologică va fi și el scurt. Astăzi vă voi spune la ce probleme duce conștiința mitologică atunci când modelați arhitectura întreprinderii.

Cunoscutul model Zachman încearcă să răspundă la întrebarea ce este o arhitectură de întreprindere și cum ar trebui să fie modelată. La baza acestui model se află întrebările la care se propun să se răspundă: cine, când, unde, de ce și cum face ceva pe ceva. Pare a fi un cadru logic pentru descrierea arhitecturii întreprinderii și mulți oameni cred că este.

Cu toate acestea, chiar și o privire superficială asupra acestui cadru lasă un sentiment de nemulțumire, deoarece nu este clar cum să răspundem la întrebarea: cine și de ce a prelucrat detaliul? Cine: Ivan Ivanovici, sau strungarul, al cărui rol a fost jucat de Ivan Ivanovici? De ce: pentru că strungarul a primit slujba sau pentru că Ivan Ivanovici a semnat un contract, conform căruia se angajează să acționeze ca strungar în schimbul hranei? De ce: pentru că Ivan Ivanovici vrea să mănânce sau pentru că piesa este necesară în atelierul de asamblare?

Un studiu mai profund al acestui cadru face să ne gândim la aplicabilitatea lui la descriere procese tehnologice. De exemplu, lăsați porumbul să crească pe un câmp. Aplicând modelul Zachman, trebuie să răspund la întrebări. OMS? Porumb. Ce face? Dezvoltă. De ce? Pentru că așa funcționează lumea. Pentru ce? Dar cine știe de ce crește porumbul?!

Un cititor instruit în descrierea arhitecturilor de întreprindere mă va corecta rapid. El va spune că pun întrebări greșite. Este necesar să ne întrebăm: cine crește, de ce crește, ce crește. Dar apoi se dovedește că pot descrie activitatea subiectului care cultivă porumb, dar nu pot descrie creșterea în sine. Resemnat cu faptul că nu pot descrie procesul de creștere, mai am întrebări nerezolvate: cine și de ce crește porumb (vezi mai sus)?

Se pare că punând întrebări aparent logice, în cel mai bun caz primesc câteva răspunsuri și, în cel mai rău caz, nu le primesc deloc. Dacă luăm cazul extrem când avem o întreprindere complet robotizată în care nu există deloc oameni, atunci răspunsul la întrebarea „cine?” va fi - „nimeni”. Drept urmare, nu putem spune nimic despre această întreprindere! Adevărat, există o cale de ieșire din această situație, puțin vicleană - trebuie doar să folosiți conștiința mitică și să animați roboții. Apoi, după ce l-am animat pe neînsuflețit, vom putea răspunde la întrebarea: cine? Robot. De ce? Pentru că acest robot este proiectat astfel, sau pentru că programatorul l-a programat astfel. Pentru a doua întrebare, primim din nou răspunsuri ciudate. De ce s-a întâmplat acest lucru și ce întrebări merită cu adevărat adresate? Voi încerca să îmi exprim pe scurt părerea despre acest subiect vorbind despre erorile logice pe care le-am găsit în modelul Zachman.

Dacă te uiți la întrebările care se pun în modelul Zachman, poți vedea că acestea corespund exact teoriei activității. Activitatea este o funcție mentală a unui subiect (un grup de subiecți). Prin urmare, răspunzând la întrebările lui Zachman, construim un model al funcției mentale a subiectului (subiecților). Știința care studiază funcțiile mentale ale subiecților se numește psihologie. Se dovedește că Zachman răspunde întrebărilor pe care le pun psihologii: de ce face subiectul cutare sau cutare acțiune? Sau cum se motivează subiectul să efectueze anumite acțiuni? Aceste întrebări sunt cu siguranță interesante și importante, dar răspunsurile la ele sunt o descriere a arhitecturii întreprinderii? Pentru a răspunde la această întrebare, trebuie să înțelegeți ce este o întreprindere?

Cum are loc de fapt proiectarea întreprinderii și ce artefacte apar în acest proces? Înainte de a proiecta o întreprindere, se construiește un model de cerințe pentru aceasta. Modelul de cerințe este format pe baza cerințelor care sunt prezentate acestei întreprinderi de toți participanții, contractanții și părțile interesate. Un analog în IT sunt cerințele pentru un produs software. Mai mult, pe baza acestor cerințe, se construiește un model de procese de întreprindere cu gradul de detaliu necesar. Un analog în IT va fi o listă de funcții produs software. În continuare, se construiește un model de obiecte funcționale, sau, vorbind limbaj specializat, locuri tehnice care ar trebui să participe la procesele enumerate mai sus. Un analog în IT va fi o descriere a procedurilor și o explicație a procedurilor implicate în care funcții. În continuare, sunt selectate acele echipamente care pot îndeplini rolurile locurilor tehnice enumerate. Omologul în IT este codul software.

O întreprindere este un obiect funcțional care este creat pentru a îndeplini anumite cerințe. În acest sens, o întreprindere nu este diferită de un obiect precum un ceas sau o linie de producție. Adesea, în loc de termenul de obiect funcțional, puteți auzi termenul de loc tehnic. O locație funcțională diferă de un echipament prin faptul că echipamentul acționează ca o locație funcțională. De exemplu, un transformator joacă rolul unui convertor de tensiune, în timp ce în momente diferite transformatoare diferite pot juca rolul aceluiași convertor. Un alt exemplu de loc tehnic este un post, departament, divizie, stat. De exemplu, un strungar este implicat în funcția de fabricare a piesei. Acesta este un loc tehnic, al cărui rol poate fi îndeplinit de diferite echipamente în momente diferite ( indivizii). Am scris pe scurt despre dificultățile de modelare a locurilor tehnice și a pieselor de echipamente într-un articol.

Atunci când modelăm locuri tehnice, descriem procesele și participanții la aceste procese. Observ că participanții, și nu interpreții, transformatorul nu poate converti tensiunea, deoarece nu este o ființă animată. Am scris despre asta într-un articol anterior. Dacă, totuși, să spunem că un transformator „transformă” tensiunea, atunci aceasta este o metonimie, care se dezvăluie după cum urmează: un transformator joacă rolul unui convertor de tensiune, care (convertorul) participă la procesul de conversie a tensiunii. Despre metonimie puteți citi în cartea „Metafore prin care trăim”, autori: George Lakoff, Mark Johnson. O altă metonimie comună ar fi: „calculatorul rezolvă probleme”. Cei care cred cu adevărat că un transformator, sau un computer chiar face ceva, animă neînsuflețitul, folosind conștiința mitică.

Rețineți că până în acest moment nu am spus un cuvânt despre obiective, performanți și relații cauză-efect. Am vorbit doar despre cerințe, despre funcții și participanți la aceste funcții - locuri tehnice. Scopurile au rămas în stadiul formării cerințelor pentru întreprindere și nu au mers mai departe. S-ar putea să cunoaștem sau nu aceste obiective - nu are nicio diferență pentru modelul de întreprindere. Modelul de întreprindere răspunde la întrebarea: cum îndeplinim cerințele, nu de unde provin acele cerințe. Nu există nici interpreți, pentru că nu trebuie să folosim teoria activității pentru a descrie participanții la o activitate. Nu construim relații cauzale. Dacă este necesar să se construiască un model de relații cauză-efect, atunci acesta este un alt model suplimentar. Acestea sunt cunoștințele pe care tehnologii le folosesc atunci când proiectează o întreprindere și nu am văzut pe nimeni să construiască astfel de modele. Acestea sunt cunoștințe de ramură și au fost predate în institute de mulți ani. Modelarea de ce zboară un avion este nerealist de dificilă și nimeni nu o face. Simulează doar zborul unui avion.

Deci, modelul Zachman nu include cerințe pentru întreprindere, include un model de procese, ci într-un mod destul de specific - cu o indicație a executorilor procesului, care, așa cum am spus, poate fi găsit doar în teorie. de activitate și nu separă modelul de locuri tehnice și modelul de echipamente.

După cum am spus mai devreme, modelul Zachman este mai mult despre activitate. În același timp, ar fi bine dacă modelul Zachman ar fi folosit în scopul propus - ca o modalitate de a descrie activități. Acest lucru ar face posibilă analizarea motivelor și interesului oamenilor pentru munca lor, dar problema este că acest model este utilizat incorect. De exemplu, la întrebarea „de ce un strunjitor ascuți o piesă?” puteți obține răspunsul: „este necesar în atelierul de asamblare”. Dar necesitatea acestuia în atelierul de asamblare nu răspunde la întrebarea de ce strunchiul ascutește piesa. Răspunsul nu a fost la întrebarea pusă, ci la alta. De exemplu, pentru un astfel de răspuns, întrebarea ar fi corectă: în ce proces sau în ce operație ar trebui să fie implicată piesa prelucrată? Sau la ce loc de muncă este nevoie? Vedeți, aceasta nu este deloc o întrebare „de ce”. În plus, sunt foarte stânjenit de capacitatea lui Zachman de a dota un computer sau un sistem informațional cu capacitatea de a face ceva. Cel mai probabil, nu le anime, ci folosește metonimia în modelare, ceea ce, după părerea mea, este inacceptabil.

Întrebările potrivite sunt: ​​Care sunt cerințele pentru întreprindere? Ce procese au loc în întreprindere? Ce locuri tehnice sunt implicate în ce procese? Ce echipamente joacă rolul în care locații funcționale și când?

De fapt, totul. La mulți ani și ne vedem curând!

Am observat deja că nu există o singură definiție corectă a ceea ce este o arhitectură de întreprindere. Variat firme de consultanta, asociații industriale, asociatii profesionale utilizați concepte și tehnici ușor diferite pentru a descrie acest concept. Mai mult decât atât, aceste concepte și metodologii sunt în flux constant, așa că încercarea de a descrie cu exactitate ce este o arhitectură de întreprindere într-un mod care reflectă gândirea de astăzi este „împușcarea unei ținte în mișcare”.

În general, atunci când se dezvoltă și se utilizează arhitectura întreprinderii, desigur, este recomandabil să adere la orice metodologie care ar oferi unitate în abordări și seturi adecvate de instrumente pentru descrierea arhitecturii. Trecem în revistă pe scurt cele mai cunoscute tehnici din „Tehnici de descriere a arhitecturii. Modele Zachman și Gartner, tehnici META Group și TOGAF” și „NASCIO. Modele 4 + 1 și SAM. Tehnici Microsoft și altele. Alegerea tehnicii „optimale”” . Aici detaliem înțelegerea noastră generală a conceptului de „arhitectură a întreprinderii”.

Arhitectura întreprinderii este un instrument dinamic și puternic care ajută organizațiile să-și înțeleagă propria structură și modul în care își desfășoară activitatea și funcțiile. Acesta oferă o „hartă” a întreprinderii și un „plan de rută” pentru schimbare atât în ​​domeniile de afaceri, cât și în cele tehnologice.

De obicei, o arhitectură de întreprindere ia forma unui set destul de larg de modele care descriu structura și funcțiile unei întreprinderi. Un domeniu important de aplicare a acestor modele este sistematizarea procesului de planificare a tehnologiei informației și furnizarea de conditii mai bune pentru proces luarea deciziilor.

Modelele individuale de arhitectură de întreprindere sunt organizate logic astfel încât să ofere colectiv o creștere în continuă creștere nivelul de detaliu informații despre întreprindere - scopurile și obiectivele acesteia, programele corporative implementate și structura organizatorică, sistemele și datele, tehnologiile utilizate și toate celelalte domenii de interes.

Aceasta este o definiție destul de plictisitoare și uscată a unui instrument care poate avea, de fapt, un impact uriaș asupra soluționării problemelor complexe și oferă o perspectivă proaspătă asupra situațiilor complexe și controversate care se întâlnesc constant în activitățile oricărei organizații. O arhitectură de întreprindere nu este ușor de creat. Pe de altă parte, dificultățile asociate cu aceasta nu ar trebui să fie exagerate. Concluzia este că, odată dezvoltată, o arhitectură de întreprindere poate aduce beneficii semnificative.

Arhitectura întreprinderii este mai mult un proces decât un lucru static. Nu vom spune că crearea sa este o plimbare ușoară distractivă. Dar, cu toate acestea, poate fi o activitate atractivă și, într-un fel, vrăjitoare. Arhitectura întreprinderii nu este un subiect simplu, dar vom încerca să o facem mai puțin „intimidantă și descurajatoare” în cele ce urmează. Metodele de descriere a arhitecturii unei întreprinderi care există deja astăzi fac posibilă organizarea procesului corespunzător chiar și în prezența unei cantități minime de informații inițiale într-o manieră intuitivă și naturală. În același timp, completitudinea descrierii arhitecturii poate fi crescută treptat, pe măsură ce înțelegerea obiectului descrierii arhitecturii crește - structura și funcțiile întreprinderii, precum și tehnologiile informaționale de sprijin.

Atunci când proiectați o arhitectură de întreprindere, trebuie să vă ocupați de un număr mare de dimensiuni și relații dintre ele care trebuie luate în considerare. Prin urmare, nu este o coincidență că multe dintre tehnicile de descriere a arhitecturii, pe care le vom analiza în continuare, își au rădăcinile într-o disciplină precum analiza sistemelor. În general, proiectarea arhitecturii întreprinderii nu este proces tehnic, care este asociat exclusiv cu tehnologia de informație. Desigur, pentru dezvoltarea sa, de regulă, se folosesc instrumente tehnologice adecvate, dar în cea mai mare parte acestea sunt instrumente care vă permit să creați diagrame și texte, de exemplu. pachete software cunoscute pentru majoritatea oamenilor. Cu toate acestea, utilizarea unor astfel de instrumente destul de simple, bazate pe metodologii adecvate, vă permite să colectați informații de bază despre activitățile organizației, să conectați diverse fapte și să trageți concluzii care simplifică și clarifică procesul complex de luare a deciziilor care se repetă în afaceri în fiecare zi. . Mai importantă este componenta creativă a acestui proces, care va fi discutată în prelegerile 10-12.

O arhitectură bună a întreprinderii oferă o analiză echilibrată a faptelor despre organizație și oferă managementului modalități de a-și examina organizațiile și modul în care acestea funcționează, îi ajută să formuleze noi strategii și oferă direcție în procesul de planificare a dezvoltării pentru a menține organizațiile în concordanță cu evoluția în continuă schimbare. conditii si prioritati. Vorbim, desigur, despre orizonturi de planificare pe termen mediu și lung, atât din punct de vedere al afacerilor, cât și al tehnologiei. O arhitectură de întreprindere bună oferă receptivitate și flexibilitate, ceea ce se reflectă în mod adecvat forme organizatorice, procese, sisteme, informații și un portofoliu de sisteme aplicate.

Utilizatorii arhitecturii întreprinderii sunt un public destul de mare de specialiști și manageri:

• profesioniști în sistemele informaționale care sunt implicați în relevante proiecte corporative crearea de aplicații importante pentru întreprindere;
• arhitecți de sistem, care sunt responsabili pentru crearea arhitecturii sistemelor informaționale individuale;
• analiști de afaceri care conduc procesul de proiectare a structurilor organizaționale și a proceselor de afaceri;
• directori care sunt interesați de o analiză sistematică, structurată a problemelor și oportunităților care se deschid pentru afaceri.

Dacă vă uitați la obiectivele urmărite de o varietate de abordări pentru a descrie arhitectura unei întreprinderi, atunci în metode corecte și de succes, puteți găsi multe în comun:

• utilizare pentru analiza multiplelor puncte de vedere asupra obiectului de studiu (întreprinderea şi sistemele ei informaţionale) în vederea „dezbinării şi cuceririi” în procesul de combatere a complexităţii obiective a lumii reale. Este important să înțelegem că niciun punct de vedere nu este suficient pentru a înțelege întregul;
• pentru a oferi un proces de sinteză, toate modelele care sunt incluse în arhitectură sunt asociate cu alte modele. Sunt fie descompuneri mai detaliate, fie vederi înrudite. Această bogăție de relații între modele determină în mod direct calitatea arhitecturii.

Așadar, înainte de a continua, iată o altă definiție a arhitecturii întreprinderii, care este dată pe site-ul www.geao.org al „Global Enterprise Architecture Organization” (GEAO – Global Enterprise Architecture Organization):

„Arhitectura întreprinderii descrie modurile în care viziunea de ansamblu a unei organizații este reflectată în structura și dinamica unei întreprinderi. La diferite niveluri de abstractizare, oferă un set unificat de modele, principii, linii directoare și politici care sunt utilizate pentru a crea , să evolueze și să impună sisteme la scară și în contextul întregii întreprinderi în ansamblu.

Rețineți că termenul „sistem” aici nu se referă neapărat la sistem informatic- se poate referi și la structuri organizatorice, sisteme de control etc. Dar această definiție în sine este mai degrabă abstractă, așa că vom încerca să-i oferim un grad tot mai mare de detaliu pe măsură ce o prezentăm.

În textul următor, folosim informații din mai multe surse și încercăm să le compilam în cadrul unui concept integrat de arhitectură a întreprinderii, care include elementele principale ale majorității metodologiilor. În special, vom urma recomandările.

Am observat deja că forța motrice din spatele arhitecturii întreprinderii este o viziune holistică care depășește granițele organizaționale. Arată în Fig. 4.1, diagrama propusă de GEAO ilustrează diferitele niveluri de abstractizare asociate descrierii întreprinderii. Rețineți că în cadrul unei organizații există o singură arhitectură de întreprindere, dar în același timp, la nivelul sistemelor individuale, poate exista un număr mare de arhitecturi de soluții (arhitectura soluției). Arhitectura întreprinderii acoperă atât aspectele de afaceri, cât și cele IT, precum și procesele de dezvoltare, evoluția arhitecturii și structura de management și control a acestor procese ( guvernanță ) care asigură o tranziție de la starea curenta arhitectura la starea viitoare dorită.