Komentarze do TOGAF - metamodel zawartości (cz. II)
W grudniu rozpocząłem cykl wpisów stanowiących mój autorski komentarz do TOGAFa. W pierwszym materiale podjąłem dyskusję nt. logicznych i fizycznych komponentów danych, aplikacji i technicznych. Teraz czas na architekturę biznesową. W szczegółach odniosę się do 3 obiektów metamodelu zawartości – tj. funkcji biznesowych, usług biznesowych i procesów biznesowych oraz konceptów z nimi związanych (takich jak: kontrakt, kontrola, produkt).
TOGAF definiuje funkcję biznesową (wydaje się, że możliwe byłoby również przetłumaczenie terminu „business function” jako „obszar funkcjonalny”) jako obszar dostarczający potencjał biznesowy (rozumiany jako zdolność do realizacji określonych działań), który jest blisko związany z organizacją, ale niekoniecznie bezpośrednio nadzorowany przez tą organizację. Przykładem funkcji biznesowych w przedsiębiorstwie produkcyjnym mogą być: marketing, sprzedaż, produkcja, kadry, IT. Należy zwrócić uwagę na jedną rzecz: funkcja biznesowa nie powinna być utożsamiana z komórką/jednostką organizacyjną – bo np. jedna funkcja IT może być realizowana przez dwa departamenty: rozwoju IT oraz utrzymania IT.
Dzięki ujęciu w definicji stwierdzenia „niekoniecznie bezpośrednio nadzorowana” wprowadzono elastyczność w zakresie sposobu realizacji funkcji – tj. dzięki temu można wyrazić, że część funkcji jest oddana w outsourcing (np. może to dotyczyć funkcji IT, ale równie dobrze funkcji sprzedaży, która może być realizowana przez sieć salonów partnerskich). Zgodnie z TOGAF funkcja biznesowa może być rozpatrywana na różnych poziomach granulacji – od najbardziej ogólnego jakim jest łańcuch wartości (dzieje się tak podczas fazy „Wizja architektury” w ramach cyklu ADM), aż po bardzo szczegółowy (na poziomie n-tego poziomu dekompozycji funkcji biznesowych – ma to miejsce podczas fazy „B” – tj. architektury biznesowej cyklu ADM). W specyfikacji TOGAF’a można również znaleźć informację, że ponieważ funkcja przedstawia potencjał biznesowy organizacji, więc diagram funkcji biznesowych może być traktowany jako mapa potencjału, którą można przygotować na różnym poziomie szczegółowości.
Elementem, na który organizacja ma wpływ przez bezpośrednio zdefiniowany interfejs biznesowy (może to być np. call center, punkt obsługi klienta jak i strona WWW) i który jest przez nią jawnie nadzorowany (poprzez wcześniej zdefiniowane parametry jakościowe – wyrażone w metamodelu zawartości TOGAF w formie dwóch elementów „kontrakt” i „miara”) jest usługa biznesowa. Wspiera ona realizację zadań organizacji i może być dekomponowana w zależności od celów modelowania. Na najwyższym poziomie ogólności usługa biznesowa ustanawia granicę dla jednej lub więcej funkcji biznesowych (innymi słowami to wyrażając: funkcja biznesowa jest postrzegana przez aktorów zewnętrznych przez usługę biznesową wyrażoną na najwyższym poziomie ogólności – czyli: funkcja biznesowa to: sprzedaż, zaś usługa biznesowa na najwyższym poziomie ogólności, która jest widoczna poza organizacją – to realizacja sprzedaży). Usługa biznesowa jest realizowana przez aktywności biznesowe, które mogą, ale nie muszą być wspierane przez IT (wyrażone w metamodelu w formie usług systemu informatycznego). TOGAF wskazuje, że usługa w rozumieniu SOA powinna być rozpatrywana nie jako usługa biznesowa a usługa systemu informatycznego (zawarta w metamodelu zawartości na poziomie architektury aplikacji).
Dopełnieniem tych elementów jest proces, który opisuje przepływ kontroli pomiędzy funkcjami i usługami (lub wewnątrz tych funkcji i usług – wszystko zależy od przyjętego przez nas poziomu granularności). TOGAF wskazuje, że niewłaściwe podczas modelowania jest bezpośrednie wiązanie procesu z aplikacją go wspierającą – elementem pośrednim powinna być funkcja – czyli: aplikacja wspiera realizację funkcji, a funkcja obejmuje cały proces lub jego fragment (w zależności od poziomu dekompozycji funkcji biznesowej). Efektem realizacji procesu jest określony rezultat – nazwany na poziomie metamodelu produktem biznesowym. Proces może być dekomponowany na podprocesy. Natomiast według TOGAF’a podczas modelowania architektury korporacyjnej na ogół nie schodzi się na poziom działań składowych procesu. Jeżeli istnieje jednak taka konieczność (np. ze względu na wymogi regulatora) możliwe jest uwzględnienie w ramach metamodelu zawartości rozszerzenia „modelowanie procesów”, które wprowadza dodatkowe elementy – takie jak zdarzenie (czynnik zewnętrzny lub wewnętrzny, którego zaistnienie powoduje uruchomienie lub zatrzymanie realizacji procesu), produkt (wynik realizacji procesu) i kontrola (punkt decyzyjny, który jest używany podczas realizacji procesu biznesowego, w celu weryfikacji czy proces ten jest realizowany zgodnie z ustaloną wcześniej logiką).
Komentarze do wpisu
Witam,
chciałem się odnieść do zdania :
"TOGAF wskazuje, że niewłaściwe podczas modelowania jest bezpośrednie wiązanie procesu z aplikacją go wspierającą – elementem pośrednim powinna być funkcja – czyli: aplikacja wspiera realizację funkcji"
Czy nie mamy tutaj małej niekompatybilności z Archimate ..?
Wydaje mi się że wg. Archimate to nie aplikacja wspiera realizację funkcji biznesowej/ procesu biznesowego, a serwis aplikacyjny. Ale może się mylę :)
Pozdrawiam
Witaj,
Wcale się nie mylisz. W ArchiMate 2.0 (tak samo było z resztą w przypadku 1.0). usługa aplikacyjna jest używana przez (used by) proces biznesowy - nie ma bezpośredniego połączenia aplikacji (komponentu aplikacyjnego) z procesem.
O łączeniu ArchiMate z TOGAF'em postaram się przygotować w najbliższym czasie oddzielny wpis.
Pozdrawiam,
Andrzej
Dodaj komentarz