Zestaw 1 Zad.1 Podaj warunki wdrożenia architektury korporacyjnej Zad.2 Czy proces projektowania architektury korporacyjnej wymaga cyklu kaskadowego? ...
12 downloads
15 Views
778KB Size
Zestaw 1 Zad.1 Podaj warunki wdrożenia architektury korporacyjnej Zad.2 Czy proces projektowania architektury korporacyjnej wymaga cyklu kaskadowego? Zad.3 Kiedy w procesach projektowania systemów należy stosować inżynierie w tył? Odp. 1 Warunkami wdrożenia w Architekturze Korporacyjnej jest wizja architektury, architektura biznesowa, architektura danych i aplikacji, architektura techniczna, możliwości i rozwiązania, planowanie migracji, nadzór nad wdrożeniem, zarządzanie zmianą architektury Odp. 2 Nie. Model kaskadowy jest rzadko używany z następujących powodów:
Nie można przejść do następnej fazy przed zakończeniem poprzedniej Model ten posiada bardzo nieelastyczny podział na kolejne fazy Iteracje są bardzo kosztowne - powtarzamy wiele czynności
Tego typu modelu należy używać wyłącznie w przypadku, gdy wymagania są zrozumiałe i przejrzyste, ponieważ każda iteracja jest czasochłonna i wymaga dużych wydatków na ulepszanie. Odp. 3 Zazwyczaj prowadzony w celu zdobycia informacji niezbędnych do skonstruowania odpowiednika. Innym zastosowaniem jest porównanie lub zapewnienie współdziałania z własnymi produktami.
Zestaw 2 Zad. 1 Podaj warstwę reprezentowania wysokiej jakości systemów informatycznych Zad. 2 Jak można obciąć ryzyko przedsięwzięcia informatycznego? Zad.3 Czy projektowanie architektury korporacyjnej jest niezbędna przed projektowaniem SOA? Odp. 1 Warstwa zajmująca się kontrola i nadzorem jakości systemów informatycznych. Do tych zadań są wykorzystywani analitycy i doświadczeni testerzy. Obszar działania obejmuje na poziomie:
wykonanie testów, automatyzacja procesów testowych, pomoc w przygotowaniu aktualnej i precyzyjnej dokumentacji testowej, audyt pełnego procesu testowego, koordynacja i nadzór nad tym procesem, tworzenie i zarządzanie środowiskiem testowym, analiza i wykonanie testów użyteczności, testy wydajnościowe, testy migracji systemów, przeprowadzenie specjalistycznych warsztatów metodycznych.
Odp. 2 Możliwie najbardziej dokładna i kompletna specyfikacja wymagań pozwala na zmniejszenie liczby funkcjonalności nieplanowanych, a w związku z tym na ograniczenie ryzyka powstania rozbieżności między planowanym i realnym budżetem oraz planowanym i realnym czasem realizacji projektu. Klient decydujący się na zmiany w systemie ERP musi założyć budżet rezerwowy na poziomie 15%. Odp. 3 Tak jest niezbędne. Ponieważ SOA realizuje dane fazy zgodnie z ich projektem.
Zestaw 3 Zad. 1 W jakiej organizacji stosuje się SOA a w jakiej mikrousługi? Zad. 2 Zastosowanie cyklu kaskadowego, a przyrostowego (brak znajomości poprawnej treści pytania) Zad. 3 Do czego służy goverance w architekturze korporacyjnej? Odp. 1 Architektury SOA stosuje się w organizacjach gdzie została stworzona duża, monolityczna aplikacja. Jest możliwe wielokrotnie wykorzystywać oprogramowanie. Dwie lub większa liczba aplikacji użytkowych mogą jednocześnie korzystać z tych samych usług. Architektury SOA mają na celu ułatwienie utrzymania lub przepisania oprogramowania. Natomiast w mikrousługach jest nieco odwrotnie ponieważ mikrousługi są niewielkie. Firmy tj. Amazon, Netflix korzystają z mikrousług, które są podzielone na autonomiczne usługi. Usługi te mają zdolność współpracy ze sobą. Mikrousługi idealnie wpasowują się w ideę zespołów pracujących w duchu Agile, co obecnie jest na topie. Każda mikro-usługa koncentruje się na wsparciu określonego potencjału biznesowego organizacji i jest niezależna od innych mikro-usług (dlatego może być samodzielnie deployment’owana). Ponadto nie ma scentralizowanego zarządzania mikrousługami, co powoduje, że każda z nich może być przygotowana w innym języku programowania oraz może używać innej technologi przechowywania danych. Odp. 2 Cykl kaskadowy polega on na wykonywaniu podstawowych czynności jako odrębnych faz projektowych, w porządku jeden po drugim. Każda czynność to kolejny schodek (kaskada). Rzadkie używanie tego modelu jest spowodowane brakiem przejścia do następnej fazy przed zakończeniem poprzedniej, iteracje są bardzo kosztowne - powtarzamy wiele czyności Natomiast w cyklu przyrostowym występuje wiele zalet tj. częste kontakty z klientem (skrócenie przerw w porównaniu z modelem kaskadowym), wczesne wykorzystanie przez klienta fragmentów systemu (funkcjonalności) Odp. 3 Jest to ład korporacyjny inaczej to zasady oraz normy odnoszące się do szeroko rozumianego zarządzania organizacją. Ład korporacyjny można także rozumieć jako podjęte w ostatnim czasie inicjatywy, opracowania i wdrożenia reguł (zasad) dobrych praktyk w organizacjach.
BONUS: a) Model kaskadowy (wodospadowy) 1. Określanie, definicja wymagań 2. Analiza, specyfikacja wymagań 3. Projektowanie, modelowanie 4. Implementacja 5. Testowanie 6. Weryfikacja i walidacja (pętla, wracamy do pkt. 1) b) Model przyrostowy (iteracyjny) 1. Określanie wymagań 2. Ogólny projekt 3. Wybór podzbioru funkcji 4. Szczegółowy projekt, implementacja testy 5. Dostarczenie zrealizowanej części systemu (pętla, wracamy do pkt. 3) Architektura korporacyjna W ujęciu atrybutowym architektura korporacyjna jest to zbiór właściwości danej korporacji (włącznie ze strukturą), które stanowią o zdolności do realizacji jej misji (oznacza to, że każda korporacja posiada architekturę – przy czym może być ona uświadomiona bądź nie; może być także efektywna lub nie). W znaczeniu rzeczowym architektura korporacyjna to formalny opis struktury i funkcji komponentów korporacji, wzajemnych powiązań pomiędzy tymi komponentami oraz pryncypiów i wytycznych zarządzających ich tworzeniem i rozwojem w czasie. Przy czym komponent korporacji definiowany jest jako dowolny element korporacji, który służy do jej konstruowania; mogą to być ludzie, procesy, fizyczne struktury jak również systemy informatyczne. Wreszcie architektura korporacyjna może być rozumiana jako dyscyplina, praktyka albo działalność w obszarze definiowania, reprezentacji i zarządzania kluczowymi właściwościami korporacji. według wiki: Architektura korporacyjna (ang. Enterprise Architecture) – zbiór właściwości danej korporacji (włącznie ze strukturą), które stanowią o zdolności do realizacji jej misji. Przy tym na potrzeby architektury korporacyjnej – korporacja (ang. Enterprise) definiowana jest jako organizacja lub zbiór organizacji, posiadających wspólny zestaw celów lub wspólne główne właściwości. Pojęcie to oznacza także formalny opis struktury i funkcji komponentów korporacji, wzajemnych powiązań pomiędzy tymi komponentami oraz pryncypiów i wytycznych zarządzających ich tworzeniem i rozwojem w czasie. Przy czym komponent korporacji definiowany jest jako dowolny element korporacji, który służy do jej konstruowania; mogą to być ludzie, procesy, fizyczne struktury jak również systemy informatyczne. Architektura korporacyjna jest także utożsamiana z dyscypliną, praktyką albo działalnością w obszarze definiowania, reprezentacji i zarządzania kluczowymi właściwościami korporacji. W tym ujęciu tworzenie architektury korporacyjnej nie jest przedsięwzięciem informatycznym, ale złożonym zespołem działań z zakresu organizacji, zarządzania i informatyki.
Architekura korporacyjna składa się z czterech domen: - Architektury biznesowej, opisuje strategie biznesowa i sposoby zarzadzania organizacja, struktura organizacja oraz glowne procesy biznesowe, a takze realcje pomiedzy tymi elemntami - Architektura danych, opisuje główne typy i źródła danych niezbednych do funkcjonwania organizacji - Architektura aplikacji, opisuje poszczególne aplikace, ich rozlokowanie, wzajemne wspoladzalanie oraz relacje miedzy tymi aplikacjami a procesami biznesowymi organizacji - Architektura techniczna, opisuje infrastrukturę teleinformatyczną, która stanowi podstawę dla funkcjonowania aplikacji Korzyści wynikające z wdrożenia arch. korporacyjnej do organizacji - lepsze dopasowanie tworzonych rozwiązań informatycznych do potrzeb strategicznych organizacji - obniżanie kosztów informatyzacji poprzez wielokrotne wykorzystanie tych samych komponentów - zapewnienie interoperacyjnosci systemów informatycznych - gromadzenie wiedzy o tworzonych systemach po stronie zamawiającego (repozytorium wiedzy) a nie wykonawcy - ułatwianie zarządzania finansami przeznaczonymi na projekty IT - przyspieszanie prowadzenia działań zakupowych (prowadzenie przetargów) poprzez mozlowisc wykorzystania bazy standardów IT SOA - Architektura oparta na usługach (ang. Service-Oriented Architecture, SOA) – koncepcja tworzenia systemów informatycznych, w której główny nacisk stawia się na definiowanie usług, które spełnią wymagania użytkownika. Pojęcie SOA obejmuje zestaw metod organizacyjnych i technicznych mający na celu lepsze powiązanie biznesowej strony organizacji z jej zasobami informatycznymi. Mianem usługi określa się tu każdy element oprogramowania, mogący działać niezależnie od innych oraz posiadający zdefiniowany interfejs, za pomocą którego udostępnia realizowane funkcje. Sposób działania każdej usługi jest w całości zdefiniowany przez interfejs ukrywający szczegóły implementacyjne – niewidoczne i nieistotne z punktu widzenia klientów. Dodatkowo, istnieje wspólne, dostępne dla wszystkich usług medium komunikacyjne, umożliwiające swobodny przepływ danych pomiędzy elementami platformy. Architektura SOA podobna jest do obiektów rozproszonych, jednak opisuje rozwiązanie na wyższym poziomie abstrakcji. Interfejsy usług są zazwyczaj definiowane w sposób abstrakcyjny i niezależny od platformy programistycznej. Również same usługi są często implementowane na bazie różnych technologii i udostępniane za pomocą niezależnego protokołu komunikacyjnego. Ład korporacyjny lub władztwo korporacyjne lub kolektywne władanie lub nadzór właścicielski (ang. corporate governance) - pojęcie to należy rozpatrywać w trzech różnych, ale ściśle ze sobą powiązanych aspektach. 1. 2.
3.
W podstawowym sensie ład korporacyjny to zasady oraz normy odnoszące się do szeroko rozumianego zarządzania organizacją. Ład korporacyjny można także rozumieć jako podjęte w ostatnim czasie inicjatywy, opracowania i wdrożenia reguł (zasad) dobrych praktyk w organizacjach sektora prywatnego i publicznego, a w szczególności w spółkach publicznych. W innym sensie pojęcie ładu korporacyjnego odnosi się do konkretnej organizacji (spółki w szczególności) i obejmuje zindywidualizowane zasady zarządzania i nadzoru oraz relacje między fundatorami (w tym akcjonariuszami) w związku z uczestnictwem (udziałem) w danej organizacji (spółce).
Szyna ESB - komunikuje się między aplikacjami, które zostają ujednolicone. Nie muszą się one kontaktować między sobą bezpośrednio w różnych konfiguracjach, ponieważ do tego właśnie służy medium w postaci szyny danych. Szyna jest także świetnym sposobem na integracje danych między systemami stacjonarnymi i mobilnymi SZYNBA ESB łączy się z: 1. Usługi interakcji z użytkownikami - zapewniają współpracę pomiędzy ludźmi, procesami i informacją 2. Usługi Procesowe - strojenie i automatyzacja procesów biznesowych 3. Usługi Informacyjne - zarządzanie zróżnicowanymi danymi i treściami w jednolity sposób 4. Usługi Partnerów - łączność z partnerami handlowymi 5. Usługi Aplikacji Biznesowych - zbudowane na bazie bezpiecznego i skalowalnego środowiska usług 6. Usługi Dostępowe - ułatwianie interakcji przy użyciu istniejących informacji i zasobów aplikacyjnych Modelowanie procesów biznesowych (ang. business process modeling) – jest to zbiór czynności wykonywanych przez analityków procesów biznesowych w przedsiębiorstwie. Modelowanie procesów ma na celu ustalenie w jaki sposób działa dana organizacja (tak zwany stan AS-IS) i może służyć do określenia docelowego sposobu postępowania (procesy TO-BE). Modelowanie, jak sama nazwa wskazuje, służy przedstawieniu modelu procesu, czyli uporządkowanemu opisowi procesu (najczęściej graficznemu). Z modelu procesu można wywnioskować przebieg i kolejność wykonywania poszczególnych kroków w procesie. Modelowanie jest często utożsamiane z mapowaniem procesów. Pojęcia te nie są tożsame. Mapa pokazuje jedyne relacje pomiędzy procesami/obiektami w procesie, podczas gdy model pokazuje przebieg. Obecnie najpopularniejszą notacją do modelowania jest BPMN.
Pryncypia architektury korporacyjnej – zbiór podstawowych, trwałych zasad bazujących na strategii rozwoju organizacji i stanowiących reprezentację całościowych potrzeb organizacji w zakresie tworzenia jej rozwiązań informatycznych. Jak podejść do budowy architektury korporacyjnej? Ramy architektoniczne (ang. architecture framework) – narzędzie umożliwiające definiowanie architektury [korporacyjnej]. Powinny one: określać metodę opisu systemów na poziomie komponentów (bloków budowlanych) i ich interakcji, dostarczać spójnego aparatu pojęciowego do opisania wszystkich domen architektonicznych, zawierać listę rekomendowanych standardów wykorzystywnych na poziomie komponentów,definiować role i ich odpowiedzialności, wprowadzać mechanizmy zarządcze („governance”), mieć wsparcie ze strony narzędzi informatycznych, nie być „zamknięte” (sposób licencjonowania) – tak, aby można je dostosować do potrzeb konkretnej organizacji. Obecnie najbardziej popualne ramy architektoniczne zaliczyć można TOGAF
Skalowanie – czyli podział pracy nad Backlogiem na więcej niż jeden zespół Przed rozpoczęciem podziału pracy na kilka zespołów, należy się do tego odpowiednio przygotować. Zabierając się do skalowania należy pamiętać o przygotowaniu odpowiedniej infrastruktury. Dużo przygotowań zależy od specyfiki projektu, ale może to być np.:
mechanizm do częstej synchronizacji pracy pomiędzy różnymi zespołami, odpowiednie przygotowanie backlog-u i architektury, tak aby prace mogły być podzielone pomiędzy zespoły, przygotowanie narzędzi do współdzielenia kodu i synchronizacji build-ów
Programowanie zwinne (ang. Agile software development) – grupa metodyk wytwarzania oprogramowania opartego na programowaniu iteracyjno-przyrostowym, powstałe jako alternatywa do tradycyjnych metod typu waterfall. Najważniejszym założeniem metodyk zwinnych jest obserwacja, że wymagania odbiorcy (klienta) [1] często ewoluują podczas trwania projektu . Oprogramowanie wytwarzane jest przy współpracy samozarządzalnych zespołów, których celem jest przeprowadzanie procesów wytwarzania oprogramowania. Pojęcie zwinnego programowania zostało zaproponowane Generalnie metodyka oparta jest na zdyscyplinowanym zarządzaniu projektem, które zakłada częste inspekcje wymagań i rozwiązań wraz z procesami adaptacji (zarówno specyfikacji jak i oprogramowania). Metodyka ta najczęściej znajduje zastosowanie w małych zespołach programistycznych, w których nie występuje problem komunikacji, przez co nie trzeba tworzyć rozbudowanej dokumentacji kodu. Kolejne etapy wytwarzania oprogramowania zamknięte są w iteracjach, w których za każdym razem przeprowadza się testowanie wytworzonego kodu, zebranie wymagań, planowanie rozwiązań itd. Metoda nastawiona jest na szybkie wytwarzanie oprogramowania wysokiej jakości. Skład zespołów jest zazwyczaj wielofunkcyjny oraz samozarządzalny, bez zastosowania jakiejkolwiek hierarchii korporacyjnej. Członkowie zespołu biorą odpowiedzialność za zadania postawione w każdej iteracji. Sami decydują jak osiągnąć postawione cele. Metoda nastawiona jest na bezpośrednią komunikację pomiędzy członkami zespołu, minimalizując potrzebę tworzenia dokumentacji. Jeśli członkowie zespołu są w różnych lokalizacjach, to planuje się codzienne kontakty za pośrednictwem dostępnych kanałów komunikacji (wideokonferencja, e-mail itp.). Manifest Agile (ang. Agile Manifesto) – założenia:
osiągnięcie satysfakcji klienta poprzez szybkość wytwarzania oprogramowania, działające oprogramowanie jest dostarczane okresowo (raczej tygodniowo niż miesięcznie), podstawową miarą postępu jest działające oprogramowanie, późne zmiany w specyfikacji nie mają destrukcyjnego wpływu na proces wytwarzania oprogramowania, bliska, codzienna współpraca pomiędzy biznesem a deweloperem, bezpośredni kontakt jako najlepsza forma komunikacji w zespole i poza nim, ciągła uwaga nastawiona na aspekty techniczne oraz dobry projekt (design), prostota, samozarządzalność zespołów, regularna adaptacja do zmieniających się wymagań.
Scrum - iteracyjna i przyrostowa metodyka zarządzania procesami, zaliczana do metodyk zwinnych, zgodnych z manifestem Agile. W metodyce tej rozwój produktu podzielony jest na mniejsze, trwające maksymalnie jeden miesiąc kalendarzowy iteracje, zwane sprintami następującymi bezpośrednio po sobie. Po każdym sprincie zespół pracujący nad rozwojem produktu jest w stanie dostarczyć działającą wersję produktu. Scrum jest często stosowany podczas tworzenia i rozwijania oprogramowania, nie jest jednak ograniczony tylko do tej dziedziny.
Technika odwracania, inżynieria odwrotna, inżynieria wsteczna, programowanie zwrotne (ang. reverse engineering) – proces badania produktu (urządzenia, programu komputerowego) w celu ustalenia, jak on dokładnie działa, a także w jaki sposób i jakim kosztem został wykonany. Zazwyczaj prowadzony w celu zdobycia informacji niezbędnych do skonstruowania odpowiednika. Innym zastosowaniem jest porównanie lub zapewnienie współdziałania z własnymi produktami. Uwaga: inżynierii wstecznej nie należy mylić z business process reengineering czy z reengineeringiem oprogramowania, którego to inżynieria odwrotna jest tylko etapem wstępnym. Inżynieria wsteczna jest często wykorzystywana w celu osiągnięcia pewnej funkcjonalności, przy ominięciu konsekwencji wynikających z praw autorskich lub patentów. Jest także używana przez wojsko, w celu skopiowania technologii opracowanych przez inne państwa, często wspomagana działalnością wywiadowczą. Zjawisko to było powszechne podczas II wojny światowej i zimnej wojny. Inżynieria wsteczna oprogramowania i elementów komputera może być stosowana w celu zapewnienia obsługi nieudokumentowanym standardom zapisu, protokołom komunikacyjnym czy też urządzeniom peryferyjnym. Inną przyczyną dokonywania inżynierii wstecznej jest przeprowadzenie audytu bezpieczeństwa, usunięcie zabezpieczeń przed kopiowaniem (cracking) lub chęć odblokowania ukrytej funkcjonalności produktu.
Poziomy dojrzałości architektury korporacyjnej (zestaw 2 / zadanie 2 - odpowiedź ) Wg badań MIT CISR (http://cisr.mit.edu/), każde przedsiębiorstwo informatyzujące swoje procesy biznesowe i chcące coraz lepiej obsługiwać klientów oraz obniżać koszty IT, przechodzi przez cztery poziomy dojrzałości architektonicznej. Poziomy tej dojrzałości zostały zidentyfikowane na podstawie wzorców inwestycyjnych oraz praktyk zarządczych różnych na każdym z czterech poziomów. Wg ww. badań firmy osiągające wyższy poziom dojrzałości architektury korporacyjnej raportowały niższe koszty IT, krótsze czasy rozwoju systemów IT, wyższą dyscyplinę procesów biznesowych i więcej korzyści strategicznych osiąganych dzięki IT. Te cztery poziomy dojrzałości architektury korporacyjnej, to: 1. 2. 3. 4.
Architektura Silosów Biznesowych: firma dba o optymalizację zaspokojenia potrzeb poszczególnych jednostek biznesowych. Architektura Standaryzacji Technologii: zapewnia skuteczność IT poprzez standaryzację i centralizację zarządzania wykorzystywanymi technologiami. Architektura Optymalizacji Działalności Podstawowej: zapewnia dopasowaną do modelu operacyjnego standaryzację procesów i systemów w firmie. Architektura Modularności Biznesu: firma posiada i może na różne sposoby wykorzystywać luźno ze sobą powiązane komponenty procesów biznesowych, które istnieją dzięki IT. W ten sposób firma stosuje globalne standardy a jednocześnie może uwzględniać lokalne różnice.
Poziom 1: Architektura Silosów Biznesowych Na tym poziomie inwestycje w IT są realizowane w celu rozwiązywania problemów i wspieraniu działań definiowanych lokalnie. Nie są stosowane standardy technologiczne ani nie powstają systemy ogólnofirmowe. Architektura Silosów Biznesowych nie narzuca ani działalności gospodarczej, ani rozwojowi IT, żadnych ograniczeń, więc budowane na tym poziomie aplikacje są bardzo dobrze dopasowane do lokalnych potrzeb jednostek biznesowych. Na tym poziomie uzasadnieniem inwestycji w IT jest głównie redukcja kosztów operacyjnych przedsiębiorstwa, które są przewidywalne i łatwo mierzalne. Jednak takie „jedyne w swoim rodzaju„ aplikacje często powielają swoje funkcjonalności i nie potrafią ze sobą współpracować. A jeśli muszą - buduje się integracje punkt-punkt. Skutki takiego podejścia łatwo przewidzieć –
po pewnym czasie powstaje spaghetti integracyjne i wprowadzenie nawet najdrobniejszej zmiany staje się kosztowne i czasochłonne. Na tym poziomie dojrzałości architektury korporacyjnej redukcja kosztów jest ważniejsza niż frustracja powodowaną niekompatybilnością systemów i technologii. Jednak z czasem potrzeba zmniejszania kosztów i wydajności technologii IT zmusza firmę do przejścia na poziom Architektury Standaryzacji Technologii. Poziom 2: Architektura Standaryzacji Technologii Na tym poziomie firmy przyjmują standardy technologiczne, aby ograniczać liczbę platform, którymi dysponują. Ale mniej platform i konieczność zachowania standardów, to mniejsze pole manewru przy budowie rozwiązań informatycznych. Zmienia się podejście do realizacji wymagań: zamiast najpierw określać rozwiązanie a później szukać technologii, firma próbuje wypracować najlepsze rozwiązanie w ramach posiadanych platform technologicznych. Zatem standaryzacja technologii ogranicza elastyczność, ale prowadzi do redukcji ryzyka, poprawy obsługi użytkowników w zakresie wsparcia, konserwacji i zaopatrzenia, poprawia bezpieczeństwo i niezawodność technologii. To wszystko obniża nakłady na zakup i utrzymanie infrastruktury IT w przedsiębiorstwie. Standaryzacja technologii nie rozwiązuje jednak wywodzącego się z poziomu Architektury Silosów Biznesowych problemu niekompatybilności i rozproszenia danych osadzonych w różnych aplikacjach. Dalszy rozwój działalności gospodarczej wymusza na przedsiębiorstwach znajdujących się na tym poziomie ewolucję w kierunku poziomu Optymalizacji Działalności Podstawowej, na którym praktyki standaryzacji zaczynają obejmować również ogólnofirmowe dane i procesy biznesowe. Poziom 3: Optymalizacja Działalności Podstawowej Na tym poziomie firmy starają się integrować systemy tak, aby wspierały procesy end-2-end, wydobywają dane z systemów lokalnych i udostępniają je stosownym procesom, eliminują redundancję w danych i funkcjonalnościach, wdrażają systemy zintegrowane klasy ERP. Inwestycje w IT są więc czynione nie z myślą o lokalnych aplikacjach i współdzielonej infrastrukturze, lecz o ogólnofirmowych systemach i współdzielonych danych. Firmy na tym poziomie pracują nad komputeryzacją swoich podstawowych procesów biznesowych. Powoduje to, że zmiana tych procesów lub struktury danych sprawia więcej trudności, ale dzięki reużyciu danych i procesów opracowywanie nowych produktów i usług odbywa się szybciej. Optymalizacja podstawowych procesów, to ogromne wyzwanie zarówno pod względem technicznym ale również organizacyjnym. Firma musi określić swój model operacyjny na różnych poziomach organizacji i konsekwentnie go stosować, co ogranicza wpływ menadżerów lokalnych jednostek biznesowych na kształt realizowanych przez nich procesów a tym samym na kształt budowanych rozwiązań IT. Następny poziom dojrzałości architektury korporacyjnej, to architektura modułowa. Poziom 4: Architektura Modularności Biznesu Architektura Modularności Biznesu poprawia zwinność przedsiębiorstwa dzięki zindywidualizowanym ale jednocześnie wielokrotnie wykorzystywanym modułom. Na poziomie czwartym firma wprowadza modularność procesów, które na poziomie trzecim podlegały komputeryzacji. Cechą charakterystyczną wyłanianych modułów (biznesowych) są dobrze określone interfejsy (biznesowe). Natomiast wewnątrz tych modułów stosuje się rozwiązania, które najlepiej pasują do realizowanych wewnątrz funkcji biznesowych. Modularność nie osłabia potrzeby standaryzacji – wciąż znajdują zastosowanie zarówno standardy technologiczne jak i standardy danych i procesów. Pozwala jednak na ich lokalne modyfikacje ale z zachowaniem standardowych
interfejsów. Dzięki reużywalnym modułom biznesowym działalność staje się bardziej spójna, umożliwia osiąganie lepszej wydajności i jednocześnie nie przeszkadza w lokalnej indywidualizacji procesów. Porównanie czterech poziomów dojrzałości Poniższy diagram obrazuje strukturę nakładów na IT na poszczególnych poziomach dojrzałości architektury korporacyjnej. Wynika z niego m.in., że przechodzenie firmy na kolejne poziomy dojrzałości architektury korporacyjnej zmniejsza nakłady na IT ale tylko do poziomu 3. Zaskakuje jednak, że poziom 4 okazuje się kosztować o 20 drożej, niż poziom 1. Taki wzrost kosztów autorzy diagramu tłumaczą np. tym, że koszty ukryte poprzednio w działalności gospodarczej zostały przeniesione do IT. Ponad to niewiele jest obecnie przedsiębiorstw znajdujących się na poziomie 4, więc mogą one ponosić wyższe koszty z racji bycia pionierami. Ale za najważniejszy powód autorzy diagramu uważają fakt, że przy modularności biznesu firmy mogą inwestować i inwestują w awangardowe innowacje. Poniżej tabela porównuje przedstawione 4 poziomy dojrzałości. Widać, że wspinanie się po poszczególnych poziomach dojrzałości, to przechodzenie od optymalizacji w skali lokalnej do optymalizacji w skali globalnej. Zasady wspinania się na poszczególne stopnie dojrzałości architektonicznej Badacze z MIT CISR zidentyfikowali zasady, które umożliwiają skuteczne przechodzenie pomiędzy poszczególnymi poziomami dojrzałości architektury firmy. Oto najważniejsze z nich:
Rozwój architektury przedsiębiorstwa należy ukierunkowywać na procesy strategiczne - wszystkiego nie da się opisać - żadna firma nie pozbędzie się silosów biznesowych Należy przyjąć do wiadomości, że złożone organizacje na różnych swoich szczeblach mają osobną architekturę i mogą znajdować się na różnych poziomach dojrzałości Trzeba posuwać się na przód stopniowo - nauka dyscypliny wymaga czasu - więcej jest korzyści z drobnych usprawnień niż z ryzykownego, przedwczesnego przejścia na wyższy poziom (np. próba wdrożenia SAP’a w firmie na poziomie pierwszym) Budowa architektury, to wewnętrzna sprawa firmy - pomoc z zewnątrz może się przydać - ale dopasowanie IT do Biznesu wymaga wewnętrznego dialogu między IT i Biznesem - decyzji w tych kwestiach nie powinien podejmować nikt z zewnątrz Należy dążyć do modularności biznesu (z wyjątkiem modelu Dywersyfikacji) - z badań MIT CISR wynika, że im wyższy poziom dojrzałości, tym większe sukcesy w osiąganiu strategicznych celów à większe średnie ROI - elastyczność oferowana przez Modularność Biznesu przynosi pożytek
Piąty poziom dojrzałości architektonicznej: Dynamiczne Przedsięwzięcie Oprócz ww. 4. poziomów dojrzałości dotyczących danej firmy Badacze z MIT CISR zidentyfikowali również poziom piąty, który nazwali Dynamicznym Przedsięwzięcie i który dotyczy całych łańcuchów dostaw, w których bierze udział dane przedsiębiorstwo. Charakterystyka:
Moduły biznesowe różnych firm będą mogły łączyć się automatycznie w celu obsłużenia okazji rynkowe Aby było to możliwe, standaryzacji będą podlegać interfejsy biznesowe firm Efekty:(+) Poprawa elastyczności i zwinności budowy całego łańcucha dostaw