Vývoj moderních IS

Velká firma. Administrativní ředitelka má na starosti velkou spoustu činností. Nemá k tomu úplně ideální personál. IT je pod generálním ředitelem, takže mají své zájmy. Což není úplně podstatné - jen celkový obrázek. Svého času potřebovala řešit jakousi partikulární agendu, řekněme BOZP nebo jinou primárně legislativní povinnost. Protože dobře znala firemní informační systém (logicky - jsou jeho hlavními uživateli), rozhodla se, že si od jeho dodavatele objedná potřebné rozšíření (které ani náhodou nepatří mezi standardní funkčnost).

Je potřeba najít a vyhodnotit dostupné / reálné alternativy.

Příběh pokračuje. Vynaložením dvou roků času, mnoha člověkoroků práce a desítek miliónů vzniklo pro jejich IS potřebné rozšíření.

• Neexistuje zadání. Ani analýza potřeb. Ani specifikace. Ani akceptační testy a jejich data. Źádné integrační možnosti (API). Žádná vazba na jiné systémy či agendy. 
• Bez účasti IT (žádná byznys ani aplikační architektura, nic... "...stejně by u toho jenom překáželi a vymýšleli zbytečnosti...").
• Metodou pokus-omyl (protože "...je přece úplně jasné, co je potřeba..."). Zcela v režii dodavatele. Jehož zájmem bylo vyfakturovat co nejvíce peněz.
• Získaná funkčnost odpovídá informačním systémům z 50.-80. let minulého století - co si tam (poměrně obtížně) naťukáte, to tam máte. Takže lidé, kteří se dané agendě věnují, vymýšlejí naprosto zoufalé pomůcky (Excel), aby si práci alespoň trošku usnadnili a potom to navíc musí zadávat do systému (který umí poskytout jen ty výstupy, které se při jeho vzniku podařilo vypotit).
• Nedejbože aby se cokoli v dané legislativě změnilo. Interní organizace práce je naprosto zabetonová, tu bude možno změnit až s novým podnikovým IS.

Paní ředitelka si myslí, že dokáže získat (zadat, nechat vyvinout) jakékoli řešení.

Prý vědí, co potřebují (aktuálně potřebují správu požadavků), "...snadno a rychle..." zvládnou analýzu (poté, co se druhým měsícem snažíme získat z výkonných lidí informace o tom, co reálně dělají podle jakých pravidel... výsledek je standard - naprostý chaos). Takovýchto příběhů je hodně. O většině se nedozvíme. 

• Neměli byste si o sobě myslet, že zvládáte zadat či řídít vývoj informačního systému, pokud za sebou už nemáte pár úspěchů tohoto typu. Nejde to bez hodně komplexních znalostí v několika oblastech. Navíc potřebujete být schopni rozkrývat podstatu reality, aby nevznikala řešení, která "mechanizují" nežádoucí stav a postupy.
• Musíte znát aktuální možnosti technologií a trendy.
• Je potřeba přistoupit na iterativní vývoj - postupovat po nejmenších možných krocích. Vynaložit maximální úsilí k tomu, aby systém zůstával stále otevřený - protože technologie, prostředí i požadavky se budou stále měnit.

Vypadá to jako samozřejmost. Podívejte se kolem sebe a zvažte, jak budete postupovat při dalším požadavku na nezbytnou funkčnost. Diskutovat lze u příspěvku na LI. 

Monolitická řešení

Dříve vznikaly informační systémy, u kterých se nepočítalo s tím, že by měly spolupracovat s nějakými jinými aplikacemi. Měly umět všechno. Bylo to "nesporné" - pro jakoukoli další agendu budou potřeba data, která jsou primárně v tomto základním podnikovém systému, takže funkčnost musí být také v něm. Má to velmi zřetelné výhody i pro producenty takovýchto systémů. Méně již pro uživatele. Důsledky vidíme všude kolem.

To, že se začalo mluvit o "modulární" architektuře v podstatě nic nezměnilo. Pořád byla jediná nepřístupná databáze "uvnitř" systému. Vývojář byl - za příslušný obolus - ochoten doplnit "modul", který jsme potřebovali. Udělal to, co jsme po něm chtěli. Čím větší nesmysl a čím hůře zadaný, tím lépe pro něj. Problém závislosti na dodavateli není potřeba rozebírat.

Procesní analýza

Pokud chcete ovlivnit - třeba podpořit IT - pracovní postupy, musíte důkladně znát (pochopit, rozpitvat) současný stav. Často se objevuje myšlenka "...rovnou to udělejme 'správně'..." (proč se zabývat tím chaosem, ve kterém se není možno vyznat). Výjimečně se to může podařit, obvykle to dopadne stejné, jako opilec v minovém poli (jehož anděl strážný právě stávkuje).

Procesní model je nutnou podmínkou specifikace funkčnosti.

Je také diskutabilní, jakým způsobem má model vzniknout (viz článek Jak zmapovat procesy). Pokud není váš byznys triviálně jednoduchý, tak nejpozději od 100 spolupracovníků je potřeba, aby některý z vrcholových řídících pracovníků měl přiměřené znalosti procesního přístupu. Takové, aby minimálně dokázal trvale rozvíjet spolupráci s vybraným (což - výběr - taky "musí zvládnout") externím expertem (přičemž musí systém budovat tak, aby dotyčného partnera bylo možno nahradit, popř. uplatní princip dvou dodavatelů... což je v této oblasti obtížně, nikoli nemožné, analogie pro vývoj informačních systémů). Protože rozhodně platí, že model procesů oblasti musí vytvářet a rozvíjet vlastník procesní oblasti (vedoucí - interní řídící pracovník).

Jak to dělat dnes

Především - pokud existuje (použitelné) standardní řešení (daných potřeb), použijme jej (viz dále). Většinou bude rozumné se bránit (důsledně trvat na ověření efektivnosti případných úprav) rozšiřování stávajícího IS (viz jinde/později). Pokud to vypadá, že je potřeba vytvářet cosi unikátního, důkladně to prověřit (viz článek Jak získat potřebné IT). Nepořizovat nic, o čem je od začátku jasné, že se musí "rozšířit". Můžeme naříkat na zmatky a nekoncepčnost. Stýskat si nad tím, že není reálné definovat závaznou jasnou koncovou podobu řešení (což je fakt). Nadávat na neserióznost vývojářů.

Má to několik "ale".

• Vývojáři (dodavatelé IT) jsou stejně "seriózní", jak seriózně k záměru přistupujeme my (a pokud ne, je naše chyba, že s takovými spolupracujeme... případná diskuse nad tím, jak fungovat v takovéto spolupráci seriózně, dle vašeho zájmu).
• I když metodiky (TOGAF) tvrdí, že je možné definovat "cílovou funkčnost", je potřeba to chápat v kontextu - pokud se rozhodneme nasadit technologii, musíme mít výše zmíněné nezbytnosti - analýzu, specifikaci, akceptační testy. Pořizujme jen to, co jsme schopni převzít.
• Akceptační kritéria musí mít podobu, které obě strany jednoznačně rozumí a jsou schopny v průběhu realizace projednat (odůvodnit & pochopit) nezbytné změny a kritéria upravit. Při převzetí provést testy, které dokládají nikoli technikálie, které si vymyslel dodavatel, ale krytí provozních potřeb zadavatele.

Nesjednávejte, čemu nerozumíte.

Inteligentní aplikace

Najdete spoustu textů (např. Architektura IT pro následující roky), ve kterých jsou pojmy, kvůli kterým většina lidí přestane číst u druhého odstavce. Je fakt, že svět se mění a IT obzvlášť rychle. Integrace aplikací pomocí SOA (architektury/podoby systému umožňující spolupráci systémů přes API - tedy bez účasti člověka) je nesporně rozumný a nesporně správný přístup, ale do nedávné doby nepřinášel takový užitek, který jsme si od něj slibovali.

Nástup platforem, pomocí kterých lze vytvářet jednoduchá řešení (s využitím standardních funkcí či aplikací dostupných právě přes API) - označují se jako "low-code" / "no-code" - poměrně výrazně mění situaci. 

• Se systémy, které mají rozumné API, lze sdílet data a spolupracovat - tedy případné nové řešení nemusí (pokud možno by nemělo) vytvářet vlastní datovou základnu. Nebo je relativně jednoduché zajistit synchronizaci dat (pokud primární data nelze použít přímo - jsou potřeba transformace). 
• To nabízí velmi zajímavou možnost postupného vytváření nezávislé "vlastní" databáze. Flexibilní. Průběžně rozšiřované a udržované tak, aby co nejlépe odpovídala realitě a potřebám funkčnosti. Snižování závislosti na původně primárních informačních systémech (viz jinde/později).
• Jednoduchou funkčnost lze opravdu vytvořit v řádu hodin.

To neznamená, že by takovéto prostředky měl používat běžný uživatel kancelářských aplikací a snažit se v nich vytvářet hračky stejně jako to doteď dělal v Excelu. Dle možností budeme publikovat zkušenosti s aktuální snahy využít princip metamodelu při řešení zmíněné správy požadavků včetně technicko-organizačních aspektů při analýze, vývoji, ověřování a nasazení takovéhoto řešení. Prozatím příspěvky na LI Automatizace a Power Platform (je tam spousta odkazů na další zdroje) a Zásady správy/vývoje (low-code) aplikací (tam je zase potenciálně zajímavá, bohužel nedokončená diskuse).

Standardní řešení

Bude doplněno... prozatím příspěvek na téma Standard - zakázka - integrace na LinkedIn.