Analityk czy architekt biznesowy?

W moich dyskusjach z analitykami, którzy są świadomi istnienia czegoś takiego jak architektura korporacyjna pojawiają się czasami następujące pytania:

Kim jest architekt biznesowy?

Czy architekt biznesowy to inna rola niż analityk biznesowy?

Weryfikacja reguł projektowych w EA

Jedną z zalet tworzenia dokumentacji projektowej w narzędziu takim, jak Sparx Enterprise Architect jest konieczność stosowania się do reguł narzuconych przez notację, w jakiej jest tworzony model. W przypadku dokumentacji tworzonej w oparciu o dokumenty MS Office - nie mamy takiej możliwości. Dopiero kolejne etapy w cyklu życia projektu weryfikują poprawność założeń.

Sparx EA posiada wbudowany moduł służący do weryfikacji zgodności z regułami. Wraz z programem dostarczany jest również zestaw podstawowych reguł. Można je znaleźć wybierając z menu: Project -> Model Validation -> Configure. Wyświetlone zostaje wówczas okno z kategoriami reguł.

Więcej na ten temat można znaleźć w EA User Guide.

Modelowanie perspektyw systemu

Moment rozpoczęcia modelowania systemu można porównać do położenia na biurku czystej kartki papieru. A zatem mamy przed sobą zadanie: zamodelować system oraz puste miejsce, w którym ten model ma powstać. Jak się do tego zabrać?

W pierwszej kolejności warto zastanowić się nad odpowiednim rozplanowaniem elementów składowych modelu. Z pomocą mogą przyjść różnego rodzaju metodyki i ramy (framework). Jednym z nich jest MDA (Model-driven architecture).

Koncepcja MDA bazuje na trzech podstawowych perspektywach systemu:

1. Computation Independent Viewpoint
2. Platform Independent Viewpoint
3. Platform Specific Viewpoint

Po co architektura korporacyjna?

W ostatnich latach coraz częściej pisze się o architekturze korporacyjnej. Może to świadczyć o tym, że organizacje zaczynają powoli dostrzegać istnienie takiego zjawiska. Zastanawiam się jednak, czy firmy potrafią odpowiednio ocenić znaczenie i wagę architektury korporacyjnej.

Czasem odnoszę wrażenie, że organizacje powołują biura architektoniczne, ale w skład takiego biura wchodzą osoby na takich stanowiskach, które nie mają realnego wpływu na wyznaczanie kierunków rozwoju, czy też sposobów rozwiązywania problemów organizacji. W takiej sytuacji kierownictwo może być przeświadczone o tym, że wykorzystuje najlepsze narzędzia oraz, że zrobiło wszystko, co jest niezbędne do tego, żeby panować nad architekturą.

A jak to wygląda w praktyce? 

Zdarza się, że osoby, które wcześniej pełniły rolę architekta rozwiązań, czy wiodącego konsultanta zmieniają stanowisko na: architekta korporacyjnego jednocześnie pełniąc dotychczasowe obowiązki. Na przykład biorą nadal czynny udział w realizacji projektów informatycznych. Gdy takie osoby pytają, na czym mają polegać ich obowiązki jako architekta korporacyjnego - słyszą, że dodatkowo powinny tworzyć modele architektoniczne. Oznacza to dla nich, że zmiana stanowiska zamiast awansu w strukturze organizacyjnej polega na dołożeniu im dodatkowych obowiązków.
W rezultacie zadania polegające na tworzeniu i pielęgnacji architektury korporacyjnej są realizowane z niskim priorytetem, bo najważniejsza jest bieżąca praca przy realizacji projektów. Tradycyjnie projekty są postrzegane jako najważniejsze, gdyż to one zwiększają konkurencyjność na rynku i przekładają się na realne dochody.
Jeśli jednak architekt nie ma czasu i możliwości spojrzeć na organizację "z lotu ptaka", to może nie zobaczyć, wad, którymi takie projekty mogą być obarczone.

Może zatem warto przypominać o korzyściach płynących z architektury korporacyjnej?
+Andrzej Sobczak pisze w następujący sposób o roli architektów:

Zastanawiam się, czy architektów korporacyjnych nie można porównywać do lekarzy organizacji, a narzędzia którymi oni (tj. architekci) posługują się (tj. modele, symulacje, analizy…) do przyrządów medycznych (dzięki nim można wykazać/udowodnić “chorobę” organizacji i doradzić odpowiednie “leczenie”). Taki architekt / lekarz organizacji prowadziłby diagnostykę problemów organizacji, a następnie zalecał odpowiednią kurację :).

Myślę, że świetną ilustracją do tego jest również poniższy filmik pokazujący w humorystyczny sposób po co jest potrzebny architekt.

Walidacja czy weryfikacja?

W inżynierii oprogramowania w różnych kontekstach pojawiają się pojęcia walidacji i weryfikacji. Często te pojęcia wymieniane są razem, a przez to znaczenie każdego z tych słów bywa niejasne i różnie interpretowane. W języku angielskim istnieje nawet odpowiedni akronim dla nich: V&V (verification and validation).

Czy zastanawialiście się na przykład nad tym:

• Czy czynność polegająca na sprawdzeniu, czy wymagania funkcjonalne sformułowane przez analityka są zgodne z założonymi celami przedsięwzięcia, to - walidacja czy weryfikacja wymagań?
• Czy sprawdzenie zgodności kodu oprogramowania z przyjętymi standardami (np. konwencja nazewnictwa klas Javy), to - walidacja, czy weryfikacja kodu?
• Czy sprawdzenie zgodności komunikatu XML z XSD, to - walidacja, czy weryfikacja?
• Czy testy funkcjonalne lub niefunkcjonalne wykonywane przez testera, to - walidacja, czy weryfikacja oprogramowania?

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.

Enterprise Architect w Gartner Magic Quadrant

Firma Gartner raz do roku publikuje tzw. Magic Quadrant - obrazujący pozycję różnych narzędzi mogących służyć jako repozytorium architektoniczne w kontekście architektury korporacyjnej. Analiza ta jest przydatna dla organizacji, które stają przed wyborem narzędzia.

Enterprise Architecture Tools Magic Quadrant 2013

W bieżącym roku Gartner klasyfikuje narzędzia do architektury korporacyjnej w następujący sposób.

Widać, że Sparx Systems - jako producent Enterprise Architect jest klasyfikowany jako niszowy gracz.
Ale trzeba mieć na uwadze, że podstawowym przeznaczeniem EA jest modelowanie bazujące na języku UML. I w tej dziedzinie można uznać Sparx Systems za lidera.

Aby lepiej zrozumieć, w jaki sposób Gartner ocenia przydatność narzędzi warto zapoznać się z kryteriami oceny. Są to:

• A repository that supports, at a minimum, the business, information, technology and solution viewpoints and their relationships. The repository must also support business direction, vision and strategy, as well as business disruptions.
• Modeling capabilities that support the minimum viewpoints of business, information, technology and solutions.
• Decision analysis capabilities, such as gap analysis, impact analysis, scenario planning and system thinking.
• Presentation capabilities that are visual or interactive to meet the demands of a myriad of stakeholders.
• Administration capabilities that enable security, user management and other tasks.
• Configurability capabilities that are extensive, simple and straightforward to accomplish, while supporting multiple environments.
• Support for frameworks and standards, often used while providing the flexibility to modify the framework.
• Usability, including intuitive, flexible and easy-to-learn UIs.

W mojej ocenie EA wspiera wszystkie wymienione funkcjonalności oraz posiada ogromne możliwości w zakresie konfiguracji, czy wsparcia dla ram architektonicznych i standardów. 

Jednakże kluczowym czynnikiem, który świadczy o ułomności tego narzędzia w zastosowaniu jako repozytorium architektoniczne są:

• Nie intuicyjny i trudny do nauczenia interfejs użytkownika.
• Zmiany konfiguracji i rozszerzenia nie są łatwe do implementacji i stosowania, gdyż nierzadko konieczne jest kodowanie w formie skryptów (np. VBasic, JScript), pluginów w .NET, poznanie języka skryptowego ShapeScript, czy MDG Technology.

Przy podejmowaniu decyzji o ewentualnym wyborze Sparx EA dla celów architektury korporacyjnej warto jednak mieć na uwadze również inne kryteria, których Gartner nie bierze pod uwagę:

• Stosunek ceny do możliwości. W tym wypadku Sparx Systems byłby zdecydowanym liderem. Trudno znaleźć jakiekolwiek narzędzie, które oferowałoby tak dużą gamę funkcjonalności za tak niską cenę.
• Popularność narzędzia Enterprise Architect w Polsce. Dzięki temu możliwe jest zatrudnienie specjalistów w swojej dziedzinie, którzy doskonale znają to narzędzie. Ta cecha niweluje w pewnym stopniu wadę EA, jaką jest nie intuicyjny i trudny do nauczenia interfejs użytkownika.

Jeszcze dla porównania prezentuję poniżej poprzednie wyniki analizy Magic Quadrant z roku 2012.

Źródło

Więcej informacji na ten temat można znaleźć pod adresem: http://www.mikethearchitect.com/2013/10/gartners-2013-enterprise-architecture-tools-magic-quadrant.html