Zkušenosti s ArchiMate

Máte vlastní otázku k ArchiMate? Pošlete nám ji a budeme se vám snažit pomoci. Témata, která jsou v tomto blogu, vyplývají z dotazů a problémů, které řešíme v projektech. Rádi pomůžeme s používáním ArchiMate, enterprise architekturou a analýzami obecně i vám.


Je ArchiMate reálně použitelný pro modelování procesů?

ArchiMate má elementy pro popis procesů včetně jejich kroků, ale na druhou stranu je nesporné, že jeho výraozvá jednoduchost složitější modelování omezuje nebo komplikuje. Některé zkušenosti s modelováním procesů v ArchiMate proto sbíráme v tomto příspěvku.

Je ArchiMate vhodný pro softwarovou firmu vyvíjející produkty?

ArchiMate je jazyk určený pro enterprise architekturu a má tak své jisté místo ve všech středních a větších organizacích, které chtějí mít pořádek v tom, jak fungují, co používají za software a k čemu jim je užitečný. Jak je na to v případě softwarové firmy.

Pomiňme případ použití ve smyslu enterprise architektury – popisu vlastních procesů atd. Zde své uplatnění jistě může mít také. Podstata otázky se ale týká vhodnosti ArchiMate jakožto modelovacího nástroje používaného při vývoji software. Je vhodný?

Kvalitní odpověď vyžaduje, abychom ujasnili, co má smysl, aby si vývojový tým vůbec modeloval. Jde v zásadě o 2 oblasti: vlastní vyvíjený systém – produkt a prostředí, do kterého je určen.

Analýza a dokumentace softwarového produktu

Architekturu systému tvoří komponenty, moduly, třídy, rozhraní, data. Používáme modely strukturální a behaviorální. ArchiMate poskytuje oba typy dat a pro modelování na obecnější úrovni (high-level) – komponenty a jejich určení, rozhraní, je ArchiMate vhodný. Poskytuje dobrý přehled a dobře se s ním pracuje. Naopak, pro modely na úrovni tříd a jejich metod je samozřejmě zcela nevhodný, k tomu se jistě hodí UML lépe. Mnoho týmů ale postrádá především zmiňovanou high-level architekturu a jednotný model obecně.

Požadavky na produkt – obchodní zaměření

Druhou důležitou oblastí je popis uživatelských funkcí a schopností produktu vyplývající z business strategie. Ať už jde o "storky" agilního popisu, nebo UseCase při modelování postaveném na principu UML nebo prostě požadavky, je vhodné je umět v něčem modelovat. Je možné využít UML, ale jeho vyjadřovací aparát je v podstatě omezen na UseCase diagram a element, což je pro složitější případy zcela nedostatečné. ArchiMate má pro popis business potřeb celou vrstvu s řadou elementů, takže je celý popis výrazně přehlednější.

Popis prostředí, pro který je produktu vyvíjen

I když je vyvíjen produkt, který je dodáván jako hotové krabicové řešení, je nebytné, aby tvůrci měli jasnou představu, jak vypadá svět zákazníka, do které produkt bude zasazen. Jaké má jiné aplikace? Jak pracuje – jaké má procesy? Co dělá – jaké má produkty? Jaké jsou jeho potřeby, schopnosti, zákazníci? To vše je třeba pochopit a je dobré umět to i zaznamenat s informacemi pracovat. ArchiMate není pro takovou analýzu primárně určen, na druhou stranu je ale jediným z používaných modelovacích nástrojů, které na oblast cílů a zájmů řeší v rámci do standardu zahrnutého rozšíření.

Týmy často narážejí na jiný problém a tím je oddělení popisu potřeb klienta a popisu produktu samotného. Více se to pochopitelně týká týmů, které produkt u klienta přímo nasazují (typicky podnikové aplikace typu ERP, CRM apod.) Takové oddělení je nezbytné jak z důvodu ochrany know-how klienta, tak proto, aby produkt zůstal produktem a nestal se zákaznickým řešením. ArchiMate sám o sobě v tomto žádnou podporu neskýtá, je třeba, aby byla dobře nastavena metodika analýzy a dokumentace. Nejde ale o slabinu jazyka, protože jazyk sám je v principu nositelem informace, nikoli jeho organizátorem.


Je klient v modelu ArchiMate aktér, role nebo entita?

Předložená otázka se zdá být banální. Proč by klient měl být business entita, když je přeci zřejmé, že jde o subjekt? To je nepochybně pravda, ale většina informačních systémů o tomto subjektu udržuje více či méně podrobné informace, a ty jsou naopak popsány entitami. Potřebujeme tedy zřejmě obojí. I když předchozí tvrzení zní logicky, je v něm skrytý problém: Vychází z předpokladu, že se model je přípravou návrhu informačního systému. Business model by ale měl sloužit k popisu fungování businessu, ne k popisu návrhu informačního systému! V praxi dnes již nelze oddělit uvažování (modelování) o businessu bez modelu informací, kterými business disponuje. Informace jsou pro většinu odvětví klíčové a tak je pochopitelné, že se s nimi počítá i na úrovni samotného modelu.

Klient je subjekt, ale on byl subjektem ještě předtím, než se stal klientem. A jeden a ten samý subjekt může být jednou klientem produktu A, podruhé produktu B. A pokud chceme dobře modelovat vztahy s klienty, často potřebujeme i rozlišit, o jakého klienta se jedná. Pohled na klienta jakožto roli tak dostává smysl ve chvíli, kdy složitější produktová struktura a segmentace klientské základny je součástí analýzy. Analytici musí zvážit, zda je tato analýza potřebnou součástí jejich modelu nebo jde o informace, které jsou důležité pouze pro obchodní a marketingové oddělení.

Jak v ArchiMate provazovat související business entity a subjekty

Je skutečně potřebné, abychom v business modelu dokázali pracovat s klientem (nebo jakýmkoli jiným subjektem, např. business partnerem, dodavatelem) jako se subjektem i entitou. U subjektu nás zajímají uzavřené smlouvy, jeho dostupnost apod., subjekt je aktivní element, který iniciuje a vykonává činnosti. Naproti tomu business objekt je nositelem informace, kterou máme v systémech a pracujeme s ní v informačních systémech. Business objekt je pasivní, nic nevykovává. Jde tedy o dva principiálně odlišné objekty i v reálném světě a to musí respektovat i model.

Jedinou správnou vazbou mezi business objektem a aktérem je asociace. Jednak ArchiMate v podstatě nedává na výběr (jedinou typovou vazbou na business objekt je Access, přístup), jednak Business objekt není realizací subjektu ani naopak. Použití povolené vazby přístupu by vyjadřovalo, že subjekt klient pracuje s business entitou o sobě samém, což nebývá pravda a i kdy ano, vyjadřuje to jiný vztah, než ten který chceme vyjádřit.

Model ArchiMate zobrazující strukutu zákazníků a vazbu na busienss entitu


Je ArchiMate jazyk postačující nástroj pro enterprise architekturu?

Zda je jakýkoli nástroj včetně jazyka postačující samozřejmě závisí na tom, k čemu jej používáme a jaké jsou naše ambice. Pokud si na stavu dřevěné stavby přinesu pouze hřebíky, může být kladivo postačující nástroj, Pokud přijdu se šrouby, pak asi ne.

ArchiMate nemá ambici (a ani schopnost) být univerzálním analytickým jazykem, vhodným pro veškerou analýzu organizace, procesů, činností, systémů atd. Např. vyjadřovací síla BPMN pro popis procesů je výrazně vyšší, stejně tak UML pro model objektově navržené aplikace poskytne kvalitnější notaci.

Otázku je proto dobré upřesnit: Je ArchiMate postačující pro logické modelování businessu a dalších vrstev, tj. k tomu, na co byl vytvořen? Podobně, jsou postačující rozšíření pro modelování postupu prací a motivace, tj. popisu smyslu a záměru? Ani vtomto případě nebude odpověď úplně snadná.
Odpověď hodně napoví historie vzniku jazyka ArchiMate. U jeho zrodu stály finanční a telekomunikační organizace a univerzita. Jejich cílem bylo popsat vnitřní architekturu a její vztahy. Jde o organizace, které nic hmotného nevyrábí, nestěhují. Navíc jejich cílem bylo (řečeno jejich vlastními slovy): Vytvořit zastřešující jazyk, který umožní provázat specifické modely do jednoho kompletního. Pokud budeme ArchiMate hodnotit prismatem TOGAF, jde o jazyk pokrývající jeho potřeby, takže se jeví jako dostatečný pro modelování enterprise architektury.
Z hlediska potřeb návrhu a správy informačních systémů, což bylo i primární východisko při vzniku TOGAF, Zachman Framework a dalších modelu, je ArchiMate téměř postačující a chybí pouze pokrytí okrajových oblastí (např. kompetence a z nich vyplývající práva). Z hlediska potřeby komplexního modelu organizace ale vyvstane celá řada oblastí, které TOGAF, ArchiMate ani další nástroje podobného typu nepokrývají:

  • Modely materiálu a jeho zpracování (výroba: přetváření surovin na produkty; kancelář: pohyb písemného dokumentu)
  • Modely finančních toků
  • Modely řízení práce na výrobku s postupným předáváním odpovědnosti (výroba: postup výroby komplexního výrobku; kancelář: předávání zpracování agendy)
  • (Již zmiňované) modely odpovědností, kompetencí, schopností
  • Modely rizik, jejich dopadů, preventivních a nápravných opatření

Řada výše uvedených modelů jde při větší či menší míře abstrakce modelovat (např. schopnosti a kompetence modelovat jako business funkce, rizika jako drivery), ale jde o modely, které postrádají názornost, jako mají skutečně ArchiMate modely vztahů procesů, produktů a služeb, na které bylo pamatováno.

Nepochybně může nastat otázka, proč by uvedené modely měly být potřeba a proč, pokud by byly potřeba, nejsou uvažovány např. v TOGAF. TOGAF se pasuje do role nástroje pro vytváření enterprise architektury. O Enterprise architekturu přitom sám TOGAF říká, že jejím smyslem je sjednotit část roztroušené popisy procesů a tak umožnit lépe rozvíjet business strategii. Hned v další větě ale doplňuje, že jde o pohled ze strany IT, tj. jak optimalizovat využitím informačních technologií. A zde je zakódováno principiální systémové omezení pohledu TOGAF i ArchiMate. Jde o modely vytvářené z pohledu IT lidí, kteří se zaměřují na informace a jejich zpracování a to ostatní je jim vzdálené.

Pokud je naším cílem příprava analýzy pro návrh informačního systému nebo popis enterprise architektury po potřeby správy IT technologií, bude ArchiMate resp. TOGAF dostatečně obsažným jazykem a frameworkem. Pokud ale chceme být partnerem businessu pro oblast optimalizace, návrhu fungování businessu jako celku nebo je naším cílem model podporující systémy jakosti typu Six Sigma, budeme potřebovat víc, než co ArchiMate může nabídnout. Zejména v případě, že jde o firmy a organizace, jejichž pracovní náplň je skutečně hmotná.