Modelujmy tylko to, co możemy zmienić

Gdy tworzymy dowolny model w obojętnie jakim języku (czy to jest Archimate, UML, czy BPMN) powinna nam przyświecać jedna generalna zasada:

Modelujemy tylko to, co możemy zmienić.

A teraz wypadałoby wyjaśnić, jak należy rozumieć tę zasadę.

Chodzi o to, że modelowaniu powinny podlegać tylko obiekty, na które mamy jakikolwiek wpływ. Żeby to lepiej wyjaśnić, skupmy się na przykładach.

Przykład 1.

Realizujemy projekt, w którego zakresie jest zbudowanie aplikacji webowej opartej na CMS (Content Management System), który jest dostępny na rynku.
Model takiej aplikacji może obejmować:

• Model wymagań - opisujący funkcjonalność budowanego rozwiązania oraz ograniczenia (na przykład w formie wymagań niefunkcjonalnych).
• Model użycia - zawierający definicję aktorów oraz przypadki użycia opisujące zachowanie budowanego rozwiązania. Przypadki użycia powinny pokazywać sposób, w jaki są realizowane wymagania funkcjonalne.
• Model interfejsu użytkownika - zawierający na przykład mapę interakcji (przejścia pomiędzy ekranami), prototypy ekranów i ich zakres informacyjny.
• Model komponentów - specyfikujący z jakich "klocków" budujemy rozwiązanie.
• Model wdrożeniowy (deployment) - pokazujący w jaki sposób te komponenty zostaną zaimplementowane.

A model danych? Jeśli w ramach projektu nie planujemy zmiany struktur danych w wykorzystywanym CMS, wówczas nie ma potrzeby budowania logicznego modelu danych. 

Gdy zastosowany CMS potraktujemy jako COTS (Commercial off-the-shelf) wówczas nie mamy wpływu na to, jakie struktury danych ten produkt wykorzystuje. Nie ma potrzeby powielać informacji, które są zawarte w dokumentacji technicznej produktu. 

Przykład 2.

Tworzymy architekturę korporacyjną organizacji. Nasza organizacja korzysta w pewnym zakresie z usług przetwarzania w chmurze. Usługi te są realizowane przez zewnętrzną firmę.

Modele architektoniczne mogą obejmować:

• Architekturę biznesową - opisującą świadczone usługi biznesowe, procesy biznesowe, jednostki organizacyjne, role biznesowe itd.
• Architekturę systemów informatycznych - opisującą aplikacje służące do realizacji procesów biznesowych.
• Architekturę danych - na przykład w formie Archimate Data Object, pokazującą w jakich systemach są przetwarzane encje danych oraz w jakie związki wchodzą ze sobą.
• Architekturę techniczną - pokazującą w jaki sposób systemy IT są wspierane przez infrastrukturę.

Ale w przypadku, gdy dany system informatyczny jest przetwarzany w chmurze, której zarządzanie powierzyliśmy zewnętrznemu podmiotowi, wówczas nie ma potrzeby modelowania tego, w jaki sposób ta chmura jest zbudowana. Chmurę należałoby potraktować jako czarną skrzynkę. W takim przypadku w architekturze technicznej wystarczy umieścić jedynie Archimate Infrastracture Service wskazujący na tę chmurę.