Determinarea limitelor arhitecturii și a tehnicilor utilizate
Următorul element important care trebuie definit este limitele arhitecturii. De exemplu, dacă sunteți responsabil pentru dezvoltarea arhitecturii de e-guvernare la nivel regional, municipal, este posibil să se concentreze în mod conștient efortul principal în dezvoltarea arhitecturii în problemele legate de interacțiunea informațiilor interdepartamentala (cum ar fi se face în cadrul proiectului electronic de proiect de e-GIF Guvernul Marii Britanii).
Dacă decideți că arhitectura întreprinderii ar trebui să vă afecteze partenerii și furnizorii, atunci, va fi necesară o participare a reprezentanților acestora la lucrări. Sau, dimpotrivă, veți alege în mod conștient o parte a întreprinderii, cea mai importantă într-un anumit sens, și doar o parte din procesele de afaceri ale organizației.
Să presupunem că echipa echipei de proiectare arhitecturală este formată și gata să-și înceapă activitatea. În ceea ce privește proiectele tradiționale, în primul rând, este necesar să se asigure formalizarea acestui proces prin elaborarea și aprobarea Cartei proiectului. O astfel de cartă definește sarcinile proiectului, calendarul implementării, abordarea și procedurile utilizate și evidențiază faptul că această activitate este susținută de conducerea organizației. În consecință, o astfel de cartă va trebui revizuită periodic și de obicei o dată pe an și aprobată de Comitetul de conducere al organizației. În detaliu, problemele de management sunt discutate mai jos în "Procesul de dezvoltare a arhitecturilor: management și control, analiza golurilor, implementare".
Odată cu trecerea la implementarea practică, este evident că, pentru a atinge obiectivul final, este necesar să se stabilească mai întâi o bază convenită. Un set de modele arhitecturale la nivel înalt poate servi ca bază [6.11]. În "Elementele de arhitectură a întreprinderii: arhitectura de afaceri și arhitectura informațională", am prezentat o descriere detaliată a modului în care pot fi utilizate modelele de procese de afaceri la nivel înalt în stadiul inițial de lucru.
Încă o dată, trebuie subliniat faptul că, în acest stadiu, nu ar trebui să meargă excesiv în detaliu. Dimpotrivă, este mai importantă "extinderea" zonei de acoperire. În același interval de timp fază ar trebui să fie, de asemenea, în mod clar definite și limitate - astfel încât chiar și pentru perioada mare de companii etapa de implementare, pe baza discuțiilor și acordurile nu trebuie să depășească trei luni, iar pentru întreprinderile mici și mijlocii - mult mai puțin.
O altă sarcină importantă va fi faza inițială a selecției și coordonarea în cadrul echipei cea mai adecvată metodă sau model (cadru) pentru o descriere detaliată a arhitecturii. Mai devreme în „Metode pentru a descrie arhitecturi. Modelele Zachman si Gartner, metodologia META Group si TOGAF“. „NASCIO. Modele“ 4 + 1 „și SAM. Microsoft și alte tehnici. Alegerea“ „metodologie“ cel mai bine ne-am uitat deja la mai multe tehnici comune, și chiar a subliniat unele caracteristici comparative. Orice unul care este legat de utilizarea unei tehnici nu există - fiecare organizație are dreptul de a alege cel care este cel mai confortabil pentru ea. Alegerea cea mai potrivită va fi una dintre procedurile ca principalele elemente pentru a completa alte metode. Un pas necesar este de a documenta soluția aleasă (sau mai precis, un subset selectat) pentru a face scurt, nu mai mult de 10 de pagini, descrierea ar putea fi utilizate de către echipa de proiect ca bază metodologică.
Alte documente importante care vor fi utilizate ca bază sunt:
- strategia de comunicare, și anume diseminarea informațiilor cu privire la proiect în cadrul organizației, ținând seama de nevoile de informare ale tuturor părților interesate - care este, de la este necesar chiar de la începutul proiectului să se prevadă măsuri pentru a asigura punerea în aplicare a rezultatelor sale, așa cum este descris mai jos în „Procesul de dezvoltare arhitecturi: management și control, Gap-analiză, implementare ";
- proceduri de examinare și analiză a excepțiilor și abaterilor de la standardele de arhitectură.
- planificare atentă;
- finanțarea adecvată și furnizarea de resurse (participanți, timp);
- motivație și implementare ("stick și morcov");
- talentul și abilitățile echipei;
- viziunea obiectivului.
Efectul real se realizează datorită unei combinații sinergice a tuturor acestor elemente, astfel încât absența sau insuficiența părților individuale poate duce la următoarele variante de eșecuri:
- finanțarea insuficientă și lipsa resurselor conduc, de obicei, la faptul că proiectul se limitează la rezolvarea sarcinilor tactice la nivelul serviciilor IT, cum ar fi alegerea unei versiuni a unui produs fără a ține seama de nevoile reale ale afacerii. Arhitectura viitoare nu va fi definită în mod clar și nu va permite obținerea unei reveniri reale în implementarea practică;
- lipsa de motivare a personalului echipei poate fi legată de sentimentul de "lucru pe raft" - dacă soluțiile arhitecturale dezvoltate nu sunt susținute de măsurile de organizare adecvate și de politicile de implementare în practică;
- teama de schimbare - soluțiile propuse nu ar trebui să fie percepute ca imposibile. Modificările propuse ar trebui să fie sprijinite prin dezvoltarea adecvată a calificării;
- dispersia - modificările sunt, de regulă, mai degrabă dureroase și, prin urmare, vor fi prelungite în mod obiectiv sub diverse pretexte, fără a lua măsuri adecvate. Este important să se concentreze în mod clar asupra obiectivului final, determinat de viziune, în caz contrar multe din inițiativele implementate pot fi risipite.
Structura exemplară a descrierii arhitecturii IT
Desigur, este important să se determine încă de la început formatul și structura descrierii arhitecturii. Formatul documentului prezentat mai jos poate fi cel mai util, în primul rând, pentru întreprinderile mici și mijlocii și pentru sistemele de informații relativ simple.