Persona w architekturze korporacyjnej
W TOGAF 9 wprowadzono w bardzo szerokim stopniu zarządzanie interesariuszami architektury korporacyjnej (w TOGAF 8 zagadnienie to było traktowane po macoszemu). W szczególności chodzi o właściwe zidentyfikowanie odbiorców produktów i usług praktyki architektonicznej.
Zgodnie ze specyfikacją standardu, działania w tym obszarze powinno wykonywać się podczas fazy A cyklu ADM (czyli fazy tworzenia Wizji Architektury) – wynika to z faktu, że dla każdego cyklu ADM występować może różne grono interesariuszy (jest to pochodna sytuacji, że poszczególne cykle ADM mogą różnić się celem i zakresem). Oczywiście nie oznacza to, że w kolejnych fazach nie można rozszerzyć grona interesariuszy – wręcz jest to wskazane, jeżeli zajdzie taka potrzeba (zwykle dochodzi do tego podczas prac związanych z planowaniem migracji – czyli w fazach E i F cyklu ADM).
Za właściwą identyfikację interesariuszy architektury korporacyjnej (a następnie dobranie dla nich odpowiednich punktów widzenia czy też artefaktów) odpowiada Główny Architekt. TOGAF podpowiada kilka narzędzi, które może on wykorzystać (m.in. siatkę siły interesariuszy).
Ja jednak chciałbym przedstawić dodatkowe, bardzo proste narzędzie, bazujące na podejściu stosowanym w obszarze web usability, które pozwoli na lepsze dopasowanie usług/produktów zespołu architektonicznego do potrzeb potencjalnych odbiorców (cały czas stoję bowiem na stanowisku, że architekci pełnią rolę usługową na rzecz organizacji i mogą być postrzegani poprzez pryzmat portfela usług i produktów, które dostarczają – taką usługą może być np. ocena zgodności projektowanego przez biznes rozwiązania ze standardami i pryncypiami architektonicznymi, zaś produktem katalog standardów architektonicznych).
Narzędziem tym jest projektowanie person. Przy czym sama persona rozumiana jako opis (charakterystyka) konkretnej osoby (reprezentującej określoną grupę użytkowników), która będzie odbiorcą usług/produktów architektonicznych. Wprowadzenie person opiera się na stworzeniu maksymalnie sugestywnej wizji typowych grup odbiorców usług/produktów architektonicznych przez przedstawienie ich przykładowych reprezentantów. Dzięki zwięzłemu opisaniu ich charakterystycznych cech oraz scenariuszy stosowania przez nie produktów architektonicznych, persony tworzą skrócony obraz tego, jak grupa docelowa będzie korzystać z efektów pracy zespołu architektonicznego.
Persony możemy podzielić na kilka typów:
- Persona główna – czyli typowy odbiorca, ten który MUSI być zadowolony z usług/produktów architektonicznych (w różnych organizacjach może to być różnie – ale można sobie wyobrazić, że są to np. architekci rozwiązań lub kierownicy projektów);
- Persony poboczne – inni użytkownicy, którzy będą sporadycznie korzystać z usług/produktów architektonicznych;
- Persona skrajna- czyli koszmar architektów;
- Persona negatywna (występująca rzadko) – czyli dla kogo zespół architektoniczny NIE tworzy swoich usług/produktów.
Poniżej występują zestaw atrybutów, które powinniśmy wykorzystać tworząc persony:
- Imię i nazwisko, wiek;
- Wykształcenie;
- Motto życiowe (kluczowa charakterystyka osoby);
- Zdjęcie;
- Cele, które ma do zrealizowania;
- Główne troski (concerns) persony;
- Postawy i doświadczenia wobec architektury korporacyjnej;
- Sposób wykorzystania przez personę produktów/usług architektonicznych.
Ktoś może zadać pytanie – po co zdjęcie przy opisie persony? Jest to dodatkowa rzecz, z której można zrezygnować, jednak ponieważ jesteśmy biologicznie i kulturowo uwarunkowani na rozpoznawanie twarzy, dlatego pozostawienie tego elementu pozwoli na większe “związanie się” z troskami/potrzebami naszych person.
Ktoś może powiedzieć, że zastosowanie person stanowi zbędny balast dla architekta, że powinien wziąć się za modelowanie, a nie tracić czas na przygotowywanie jakichś opisów. Ale praktyka bardzo brutalnie weryfikuje to podejście… czyli powstają świetne (?) modele/produkty architektoniczne, ale nie ma ich odbiorców. Zawiodła analiza interesariuszy. Może więc warto, poświęcić chwilę czasu i przybliżyć zespołowi architektonicznemu komu będą oni dostarczać swoje produkty i usługi.
Komentarze do wpisu
Podejście bardzo podobne do wykorzystania person w user-centered design w projektowaniu interfejsów użytkownika.
Witaj Michale,
Jest dokładnie tak, jak piszesz. Zresztą wspominam o tym w treści wpisu, że inspirowałem się podejściem stosowanym w web usability.
Pozdrawiam,
Andrzej
cześć,
ja w swojej korporacji spotkałem się z goła innym problemem podczas prac nad opracowaniem komunikacji z interesariuszami. Mianowicie samą klasyfikacją interesariuszy. Dla wielu AK w mojej firmie interesariusz to "persona" która jest "decyzyjna". Innymi słowy, architekci pracujący na poziomie architektury potencjału (architekci rozwiązań) - to już nie interesariusze ...
Pozdrawiam
Witaj,
Absolutnie się nie zgodzę z tym, że architekci rozwiązań nie są interesariuszami architektury korporacyjnej. Wykonując projekt dla jednego z banków bardzo dużo czasu poświęciliśmy na zaadresowanie trosk architekta SOA odpowiedzialnego za ESB. W tym konkretnym przypadku chodziło o odpowiednie odwzorowanie jego potrzeb na metamodel ArchiMate (a dokładnie kastomizację standardowego metamodelu ArchiMate, tak aby móc zapanować nad integracją).
Pozdrawiam,
Andrzej
Dodaj komentarz