COSA Patterns

Co jsou to COSA Patterny

  • Základní typizované stavební prvky EA modelu a architektonických výstupů podle COSA.
  • Znovupoužitelné struktury s jasným účelem, způsobem vzniku a podobou prezentovaných informací.
  • Vycházejí z TOGAF a Archimate standardů a přinášejí zásadní zjednodušení a formalizaci v rámci celého projektu.
  • Cílem je vysoká efektivita práce architektů a jejich intenzivní a trvalé zapojení do dodávky projektu.
  • Základ tvoří centrální sdílený architektonický model (Sparx EA repository) doplněný o automatizované a kolaborativní nástroje COSA.
  • Vycházejí z konsolidovaného know-how nasbíraného za více než 20 let praxe na mnoha projektech

Struktura COSA Patternu

 

Část

Popis

Forma

Účel

základní popis účelu, cílové skupiny, uvažovaných přínosů a známých omezení

Textový popis (Dokument)

Metamodel

pouze elementy a jejich vazby uvedené (= zobrazené) v metamodelu jsou součástí importních a exportních postupů

Sparx EA diagram

Dokumentace

jednotný výstup v podobě dokumentu obsahující diagram(y) a popisy uvedených elementů a vazeb

Sparx EA custom document template (master document)

Tabulkový výstup

základní informace pokryté daným patternem v tabulkové podobě

Excel/CSV

SQL script

definuje tabulkovou podobu výstupu

SQL script

Hlavní COSA Patterny

Hlavní COSA Patterny základním nabízeným službám. Ne každá služba má ale vlastní pattern a naopak, pro úspěšné poskytování některých služeb je vhodné patterny kombinovat.

Pro specifické případy vznikají podle stejných postupů a pravidel patterny nové.

Základního postupu je doprovázen těmito průběžnými aktivitami:

  • centralizace informací ve sdílené EA Repository ve struktuře jazyka ArchiMate
    publikace informací
  • rozšíření získaných vstupů o doplňkové klasifikační atributy podle COSA
  • průběžná kontrola kvality a konzistence modelu

Digitalizace a Transformace ICT

  1. Zjistíme a zpracujeme základní cíle, ale i omezení projektu. Odpovíme na otázku PROČ.
  2. Popíšeme, jak prostředí na začátku vypadá a kdo jsou hlavní zákazníci. ODKUD
  3. Navrhneme, jak by prostředí pro zákazníky mělo vypadat. Zatím bez ohledu technické otázky. KAM
  4. Zanalyzujeme detaily a přidáme návrh toho, jaké aplikace a jak budou tvořit řešení. JAK
  5. Poznáme tak rozsah projektu, který případně smysluplně rozdělíme na části a navrhneme řešitele. KDO

Rozdělení a sloučení společnosti

  1. Zjistíme a zpracujeme základní požadavky na cílové řešení, stanovíme jeho omezení. Odpovíme na otázku PROČ
  2. Popíšeme, jak prostředí na začátku vypadá – ať už jsou na začátku dvě společnosti, nebo jen jeda. ODKUD
  3. Navrhneme, jak by nakonec mělo prostředí pro zákazníky vypadat a jaké služby by se měly kde nabízet. KAM
  4. Zanalyzujeme detaily a přidáme návrh toho, jaké aplikace a jak budou tvořit řešení. Ať už bude na konci jedno, nebo dvě prostředí. JAK
  5. Poznáme tak rozsah projektu, který případně smysluplně rozdělíme na části a navrhneme řešitele. KDO

Výměna nebo náhrada klíčových systémů

  1. Zjistíme a zpracujeme základní cíle, požadavky a omezení. PROČ
  2. Popíšeme, jak prostředí na začátku vypadá a komu a jaké služby poskytuje. ODKUD
  3. Identifikujeme, které služby bude třeba nahradit. Obchodně i technicky. KAM
  4. Detailně zanalyzujeme dopady a navrhneme, jaké systémy a v jakém pořadí je možné nahradit. JAK
  5. Určíme nutný rozsah projektu, který dále rozdělíme na logické části a navrhneme jejich řešitele. KDO a CO

Restart nepříznivě se vyvíjejícího projektu

  1. Provedeme posouzení stávajícího stavu. 
  2. Identifikujeme neúplné nebo chybějící podklady. 
  3. Určíme následný postup podle povahy projektu a zvolíme odpovídající pattern. 
  4. Doplníme podklady a pomůžeme projekt znovu nastartovat. 

Redukce aplikačního portfolia

  1. Zjistíme a zpracujeme základní cíle, požadavky a omezení. PROČ
  2. Popíšeme, jak prostředí vypadá a komu a jaké služby poskytuje. Obchodně i technicky. ODKUD
  3. Identifikujeme, které služby je možné nahradit nebo sloučit.  KAM
  4. Detailně zanalyzujeme dopady a navrhneme, jak systémy redukovat. JAK
  5. Projekt rozdělíme na logické části a navrhneme jejich řešitele. KDO a CO

Podpora implementace DORA

NIS2 a Kybernetická bezpečnost

Nedostatky v GDPR

Přechod do cloud prostředí

Předpokladem je, že se v rámci přechodu do cloudového prostředí nemění business model a služby nabízené klientům. Jde tak pouze o technický úkol.