Budowa celów architektury korporacyjnej IT dla środowisk zintegrowanych w sektorze publicznym

Transkrypt

1 Budowa celów architektury korporacyjnej IT dla środowisk zintegrowanych w sektorze publicznym Autorzy: Dr Jerzy Roszkowski 1

2 KONIECZNOŚĆ ZARZĄDZANIA ARCHITEKTURĄ KORPORACYJNĄ Koszt złoŝoności IT -ZłoŜoność IT wiąŝe się z realnym kosztem, który musi ponosić organizacja w długim okresie czasu Złożoność niweluje efekty biznesowe związane z inwestycjami Negatywne aspekty wzrostu złożoności Zwiększenie kosztów projektu WydłuŜenie TTM w długim okresie Zwiększenie kosztów utrzymania Zwiększenie awaryjności i TTR (dostępność) Przeniesienie kosztów danego projektu w przyszłość (zwiększenie w długim okresie) Zmniejszenie strategicznej elastyczności Czy projekty biznesowe uwzględniają te aspekty realizacji celów biznesowych? 2

3 Przedmiot badania - zarządzanie architekturą poprzez cele Przedmiotem badania jest określenie zarządzania architekturą IT poprzez cele (architektoniczne) Cele te następnie są dekomponowane na odpowiednie wytyczne techniczne dla konkretnego środowiska IT Biznesowe cele architektury są realizowane poprzez cele architektoniczne Cele biznesowe są dekomponowane na cele architektoniczne Cele architektoniczne prowadzą do realizacji celów biznesowych, ale są one celami nieprojektowymi tzn. nie są celami projektów Zadaniem operacyjnym architektury korporacyjnej jest realizacja celów architektonicznych zdefiniowanych w ten sposób

4 Model celów architektonicznych Dr J. Roszkowski Cel architektoniczny (Aris) A1.1 Minimalna ilość miejsc konfiguracji dla danej klasy zagadnień A1.2 Wysoka liczba konfigurowalnych parametrów BC5.1.3 A1 A Elastyczne środowisko Wysoka konfigurowalność A2 Niska złoŝoność developmentu A3 Automatyzacja testów A4 Wystarczająca skalowalność procesów Minimalna redundancja metadanych B Proste środowisko B3 Odpowiednie pokrycie funkcji przez systemy B4 Optymalne procesy systemowe B3.1 Minimalna redundancja funkcjonalności B3.2 Prawidłowa allokacja funkcjonalności Optymalna liczba kroków procesowych B4.1 Maksymalna automatyzacja B4.2 Wysoka uniwesalność zast. B4.3 procesów C Niezawodne środowisko C1 Wysoka dostępność C2 Niska liczba błędów Niska liczba awarii Krótki czas niedostępności planowej Niska liczba błędów w środowisku testowym Niska liczba błedów w środowisku produkcyjnym C1.1 C1.2 D Minimalizacja ryzyka C2.1 C2.2 D1 Gotowość na nieprzewidziane zdarzenia D2 Unikanie katastrof architektonicznych E Efekywne środowisko E1 Niska pracochłonność zmian w środowisku E2 Niskie koszty utrzmania F Kompletne środowisko F1 Gotowość na projekty z roadmapy F2 Dostosowanie do moŝliwości organizacji F3 Uwzglednienie ograniczeń prawnych technicznych i pozostałych B5.2 B5.3 B5.1.4 Wysoka jakość danych Prawidłowa alokacja danych Odpowiedni model konceptualny B5 Właściwa jakość danych i metadanych B6 Optymalny dobór sprzętu i technologii B7 Optymalne komponenty systemowe Optymalny dobór sprzętu i licencji Ujednolicenie technologii B6.1 B6.2 ReuŜycie komponentów B7.1 Cel Cel elementarny Czynnik sukcesu Minimalizacja zaleŝności B7.2 4

5 Cele architektoniczne (1) 5

6 Cele architektoniczne (2) 6

7 Mierniki (A)

8 Mierniki (B) 8

9 Mierniki (C) 9

10 Mierniki D, E, F 10

11 Architektura linia lotnicza cmp Components HTTP HTTP Konkurencja BillBird (5) BillBird File format SFTP-port Ubezpieczenia (6) SFTP-port CSV Format SMS Gates (7) ODBC-ORACLE port JDBC Port Oracle ODBC SMS.jar MSSQL ODBC Bank Transactions (8) HTTPS-Port MT940 on HTTPS FK (9) MSSQL DB Port MSSQL DB PORT Revenue Management (10) MySQL Port ODBC for MySQL ODBC for MySQL Revenue Mapper.NET MSSQL DB Port Helpdesk (11) Agents (12) HTTP-WebApplication HTTPS SMTP-Port MSSQL Server Data WebApp on HTTPS Kadry (13) MS SQL Server MS SQL Se rver Data Netline Crew (14) SFTP-Port XML Files JDBC for MSSQL Server MS SQL Server Data Pła tności Ubezpieczenia SMS M odule Ba nk Transactions FK Rev enue Management Database Warehouse Helpdesk Rozliczenia agentów Kadry Netline Crew For Agents App CallCenter Bibit Potwierdzenia płatności do NAV SFTP-port SFTP-port CallCenterData Webservices on HTTPS CSV Format XML File Format SFTP-Port BulLoadDB BulkLoad Text File format CurrencyValue File MSSQL Data Wszystkie aplikacje działały na Warstwie MS SQL SERVER..NET słuŝył jedynie do prezentacji i wprowadzania danych. Wszelkie obliczenia w procedurach wbudowanych MSSQL SERVER CallCenter (18) GetCCData SFTP-Port Potwierdzenia płatności do NAV (3) BulkLoadMapper (2) SFTP-port Import XML data IVR (17) SFTP-port NBP (16) SFTP-Port SQL Intranet.NET Application + MS SQL SERVER Stored Procedures Raporty FK, Navitaire, Statystyczne Obieg dokument ów kosztowych (15) Helpdesk Bibit (4) SFTP-port Navitaire (1) Rozliczenia Agnetów IIS Web Server Wynagrodzenia personelu pokładowego 11

12 Kluczowe elementy architektury System rezerwacyjny przez www Hurtownia danych Revenue Management Netline Crew zarządzanie załogami i rejsami Rozliczenia agentów 12

13 Dopasowanie Miar W rysunku powyŝszym dla wskaźników o wartościach nx% i identyfikatorach: B5.1, B5.2, C1.1, C1.2, C2.1, C2.2, D2,E1, zostały odwrócone wskaźniki, do postaci 100%-nx% aby uzyskać stan wskaźnika 100% obrazującego najlepsze moŝliwe rozwiązanie architektoniczne. Przykład: Minimalna redundancja (dublowanie się danych) -> Opis miernika wskazuje, Ŝe im mniejsza wartość wskaźnika, tym lepiej. Po odwróceniu wskaźnika, Miernik = 100% obrazuje najlepszą z moŝliwych sytuacji dla tego miernika czyli 0 % redundancji 13

14 Analiza oceny A i E -Środowisko jest mało elastyczne, w zakresie: MoŜliwości konfiguracyjne środowiska Łatwość developmentu Automatyzacja testów B: Redundancja i pokrycie funkcji przez systemy Ponad 70% Redundancja hurtowni wzorcowa Do weryfikacji procesy biznesowe) Część architektury zaprojektowano ad-hoc C i D Niezawodność i ryzyko DuŜy nacisk na niezawodność, dostępność oraz wydajnoć - 98% F Kompletne środowisko Ponadprzeciętnie przygotowana na nowe projekty Łatwe będzie pokrycie funkcjonalne i rozwój

15 Podsumowanie oceny Badana Architektura: 67,66 % Przeciętna Architektura dla niedojrzałych organizacji: ~30% Przygotowana przez specjalistów od: SLA / Dostępności Hurtowni danych Integracji

16 Jak wykorzystać ocenę (IT vs Business)? Mapowanie Grup miar na cele biznesowe. Siła oddziaływania elementów architektury na cele biznesowe Pokazuje, które z elementów architektury wymagające modernizacji, Zarząd powinien potraktować jako waŝne

17 Podsumowanie Definiowanie celów architektonicznych i biznesowych jest podstawowym i pierwszym krokiem w budowaniu architektury korporacyjnej. W TOGAF ADM zostaje to ustalone w kroku Architecture Vision. W pracy przedstawiono wyniki badań w tym zakresie przeprowadzonych przez autorów w kilku sektorach: telekomunikacyjnym, publicznym. Cele architektoniczne mogą posłuŝyć do oceny aktualnego stany architektury IT i wytyczenia jej kierunków rozwoju. Kolejnym krokiem po zdefiniowaniu celów architektonicznych jest budowa repozytorium wytycznych i zasad, określonych dla powyŝszych celów. Wytyczne i zasady słuŝą kontroli realizacji celów podczas iteracyjnego rozwoju architektury IT. Dalszych pogłębionych analiz i badań wymaga przełoŝenie celów biznesowych (w sektorze) na cele architektoniczne. DZIĘKUJEMY ZA UWAGĘ