O potrzebie łączenia podejść metodycznych

Kategoria II

Pomimo, że architektura korporacyjna kładzie szczególny nacisk na całościowe (holistyczne) ujęcie należy mieć świadomość, że koncepcja ta musi harmonijnie współistnieć z innymi obszarami funkcjonowania każdej organizacji.

W szczególności należy wskazać tutaj relacje występujące na linii:

  • architektury korporacyjnej i planowania strategicznego,
  • architektury korporacyjnej i prowadzenia projektów i programów,
  • architektury korporacyjnej i wytwarzania oprogramowania,
  • architektury korporacyjnej i utrzymania systemów IT.

Do mniej rozpoznawalnych (co nie oznacza jednak, że mniej istotnych) związków zaliczyć można relacje na styku:

  • architektury korporacyjnej i ciągłości działania,
  • architektury korporacyjnej i zarządzania ryzykiem,
  • architektury korporacyjnej i ładu IT,
  • architektury korporacyjnej i działań zakupowych.

Relacje architektury korporacyjnej z jej otoczeniem można rozpatrywać na dwóch poziomach: ujęcia metodycznego oraz podejścia koncepcyjnego.

W pierwszym przypadku można podejść do integracji następujących podejść metodycznych (skoncentrowałem się na TOGAF, jako standardzie de-facto w zakresie ram architektonicznych):

  • TOGAF a strategiczna karta wyników (Balance Scorecard),
  • TOGAF a PRINCE2/PMI/MSP,
  • TOGAF a RUP/metodyki zwinne np. SCRUM,
  • TOGAF a ITIL,
  • TOGAF a COBIT,
  • TOGAF a MoR.

Zanim zejdzie się na poziom integracji podejść metodycznych o wiele ważniejsze wydaje się określenie relacji koncepcyjnych pomiędzy tymi obszarami. Poniższe rozważania będą rozważane z punktu widzenia podejścia architekturocentrycznego – tj. takiego, w którym architektura jest w centrum działań. Jest to jedno z możliwych podejść. Podejściami alternatywnymi są: usługocentryczność (czyli zarządzanie usługami jest w centrum działań) oraz zarządzanie przez portfel inicjatyw.

Z przeprowadzonych przeze mnie analiz wynika, że:

  • Efekty planowania strategicznego powinny być wsadem do tworzenia architektury korporacyjnej, ale jednocześnie architektura korporacyjna powinna stanowić weryfikator realizowalności tworzonej strategii organizacji.
  • Konkretne projekty i programy powinny być zarządzane przez Biuro Projektów i Programów, ale powinny się one wyłaniać z modeli architektury korporacyjnej (czyli de-facto najpierw powinien powstać model docelowy organizacji, którego realizacja zostanie następnie „rozpisana” na poszczególne projekty i programy).
  • Architektura korporacyjna nadaje „ton” pracom programistycznym – tj. poprzez nią można określić wymagane standardy (np. integracyjne, w obszarze bezpieczeństwa itp.), sposób dokumentowania, zasady reużywalności. Z drugiej strony to konkretne prace programistyczne są najlepszym weryfikatorem stworzonych modeli architektonicznych (zwłaszcza w ramach architektury IT)  – na ile modele te uwzględniają rzeczywistość technologiczną.
  • Aby rozwiązać określony problem zidentyfikowany na poziomie usług IT bardzo często trzeba wprowadzić modyfikację na poziomie architektonicznym; z drugiej strony każda zmiana przewidywana do realizacji powinna być oceniona, czy i w jakim zakresie ma wpływ na architekturę korporacyjną.
  • Architektura korporacyjna (w szczególności usystematyzowana wiedza zawarta w repozytorium architektonicznymi i możliwość prowadzenia analiz wpływu typu „what-if”) jest bardzo pomocna przy planowaniu ciągłości działania organizacji i zarządzania ryzykiem – z tego względu podejście architektoniczne powinno być zintegrowane z korporacyjnym zarządzaniem ryzykiem (Enterprise Risk Management).
  • Architektura korporacyjna jest bardzo dobrym narzędziem do definiowania przedmiotów zamówienia – pozwala bowiem na uzyskanie spójnej i kompletnej listy odpowiedzi na pytanie „co ma być zrobione” bez odpowiadania na pytanie „jak to ma być zrobione”. Na pierwsze pytanie odpowiada zgodnie ze sztuką architekt, na drugie – wyłoniony w drodze postępowania dostawca.

Podsumowując, należy zadać sobie jedno pytanie – skoro jest tak wiele potencjalnych obszarów synergii i współdziałania, dlaczego tak trudno jest to przełożyć na codzienną praktykę organizacyjną. Wydaje się, że odpowiedź powinna być udzielona wielopłaszczyznowo.

Po pierwsze – występują trudności (lub wręcz niespójności) terminologiczne. Każdy z tych obszarów (a przynajmniej każda z wiodących metodyk/ram w danym obszarze) wypracował się własnego słownika. W praktyce oznacza to, że zanim porozumieją się  TOGAF’owiec z ITIL’owcem w sprawie rozumienia np. terminu „usługa” czy też „aplikacja” muszą spędzić bardzo dużo czasu na wspólnym rozumieniu poszczególnych pojęć.

Po drugie integracja poszczególnych podejść metodycznych powoduje, że pojawia się stosunkowo złożony system zarządczy, wymagający sporej konsekwencji i dyscypliny. Nie każda organizacja jest w stanie w takich „karbach” działać.

Ostatnim czynnikiem (ale zgodnie z zasadą „last but not least” nie najmniej istotnym) są kwestie związane z formalną i nieformalną władzą w organizacji. Może się okazać, że część struktur organizacyjnych mających bardzo silną nieformalną władzę, musi ustąpić przed nowym porządkiem (proszę zwrócić np. uwagę jak zmienia się pozycja Biura Projektów i Programów w momencie kiedy wychodzimy od zarządzania portfelem inicjatyw/projektów, a kiedy wychodzimy od architektury korporacyjnej, a portfel projektów jest tylko pochodną architektury). Nie każdemu nowa rola i związana z tym pozycja w organizacji może odpowiadać.

Pojawia się pytanie, co można zrobić w takiej sytuacji? Z jednej strony architektura korporacyjna nie może być rozpatrywana jako samotna wyspa w organizacji. Jednocześnie wydaje się, że dochodzimy do miejsca, w którym poszczególne metodyki zaczynają zawłaszczać coraz większe fragmenty organizacji (proszę np. zwrócić uwagę na kierunek rozwoju ITIL – od zarządzania usługami IT do próby całościowego zarządzania usługami, w tym biznesowymi). Wydaje się, że nie jest to najwłaściwsza droga. Niezbędne jest raczej stworzenie „metodycznej platformy integracyjnej” łączącej poszczególne światy. Oczywiście nie mam tutaj na myśli konkretnego narzędzia informatycznego. Raczej chodzi o zidentyfikowanie punktów styku pomiędzy zasygnalizowanymi wcześniej podejściami metodycznymi i zaproponowanie mechanizmów harmonijnego ich współistnienia, aby zgodnie z zasadą „best of bread”, organizacja mogła stosować najlepsze/ulubione metodyki/ramy, a przy tym zapewniony byłby efekt synergii pomiędzy nimi.

Obecnie w ramach moich prac badawczych w Katedrze Informatyki Gospodarczej rozpocząłem prace nad projektem mającym na celu wypracowanie wzorców łączenia poszczególnych podejść metodycznych, co prowadzić ma do ładu metodycznego w organizacji. Zakładam, że punktem łączącym różne metodyczne światy będzie architektura korporacyjna i TOGAF. Tak więc w polu projektu będą takie połączenia jak np. TOGAF i ITIL czy też TOGAF a P30, ale i TOGAF a strategiczna karta wyników. W miarę możliwości będę starał się na serwisie ArchitekuraKorporacyjna.pl przedstawiać postępy realizowanych prac.