Mapowania wychodzące poza architekturę korporacyjną

Dwa tygodnie temu w poście poście Moje ulubione perspektywy w architekturze korporacyjnej przedstawiłem kilka diagramów opisujących architekturę korporacyjną z różnych perspektyw. Opisane perspektywy obejmowały architekturę biznesową, architekturę systemów informatycznych oraz architekturę technologiczną. Oprócz tego zaprezentowałem kilka diagramów prezentujących mapowania pomiędzy powyżej wymienionymi architekturami.

W dzisiejszym wpisie postaram się zaprezentować mapowania artefaktów architektury korporacyjnej na wymagania architektoniczne, model procesów biznesowych oraz modele systemów informatycznych. Zaprezentowane mapowania są najczęściej stosowanymi przeze mnie mapowaniami. Oczywiście nie zamykają one katalogu możliwych relacji. Nie twierdzę też, że są one zgodne z jakimkolwiek standardem lub notacją, gdyż łączyć będę elementy BPMN, ArchiMate i UML.

Wymagania architektury

Na każdym poziomów architektury można zdefiniować wymagania architektoniczne. Są to wymagania, które na dość wysokim poziomie abstrakcji uzupełniają opis artefaktów architektury korporacyjnej.

Z moich doświadczeń wynika, że przeważająca część wymagań dotyczy usług aplikacyjnych. Osobiście staram się mapować wymagania architektury systemów informatycznych na usługi aplikacyjne. Używam do tego  relacji realizacji.

Dość często definiowane są także wymagania dotyczące biznesu. W warstwie architektury biznesowej także używam relacji realizacji. Podobnie jak przedstawiłem to powyżej można zdefiniować wymagania dla architektury technologicznej.

Należy pamiętać, że to biznes definiuje proces biznesowy i jego ramy – wymagania. Systemy informatyczne są tworzone po to by wspomóc proces biznesowy. Zaprezentowane powyżej mapowanie artefaktów na wymagania ma większy sens, gdy wymagania architektury systemów informatycznych realizują wymagania architektury biznesowej.

Mapowanie elementów architektury korporacyjnej na inne modele

Zdefiniowanie, na poziomie architektury, wymagań i innych artefaktów to dopiero połowa mojej drogi. Osobiście lubię mieć artefakty architektury korporacyjnej zmapowane na inne modele utrzymywane w organizacji. Zazwyczaj mapowania te dotyczą modeli procesów biznesowych oraz przypadków użycia.

Mapowanie architektury biznesowej na procesy BPMN

Mapowanie architektury systemów informatycznych na model systemów informatycznych   

Mapowanie wymagań architektonicznych na system

Zaprezentowane powyżej mapowania bazują na relacji trace. Używam jej, gdyż przeznaczeniem tej relacji jest wskazanie na śledzenia zależności pomiędzy elementami. W podobny sposób można połączyć komponenty lub inne artefakty.

Warto zauważyć, że na powyższych diagramach zostały połączone elementy opisujące architekturę korporacyjną z uszczegóławiającymi ją elementami. Elementy uszczegóławiające takie jak przypadki użycia lub procesy biznesowe wyrażone w BPMN są na niższym poziomie abstrakcji. Z tego też powodu zazwyczaj jednemu elementowi z architektury odpowiada jeden do wielu elementów uszczegóławiających (jedna usługa aplikacyjna jest realizowana przez jeden do wielu przypadków użycia).

Na koniec pragnę zauważyć, że przedstawione w dzisiejszym jak i poprzednim wpisie (Moje ulubione perspektywy w architekturze korporacyjnej) diagramy są tylko wycinkiem możliwości, jakie daje nam zastosowanie narzędzi CASE oraz notacje takie jak: ArchiMate, BPMN czy UML. Architektura korporacyjna zamodelowana w Archimate to połączenie 3 widoków, które mogą być uszczegóławiane w innych notacjach. Co więcej opisując architekturę korporacyjną może przedstawiać jeszcze diagramy motywacji, implementacji i migracji.  Można też budować opisy łańcuchów wartości.  Możliwości opisu (modelowania) jest bardzo dużo. Dlatego też zalecam aby przed wejściem w jakiekolwiek diagramy spisać zasady modelowania lub zbudować metodykę tworzenia i  utrzymywania czy to architektury korporacyjnej czy to procesów biznesowych. Zbudowanie standardów pracy nie będzie czasem straconym.

Reklama