Proč vlastně IT se svou metodologií (či spíše architekturou) SOA tak touží po spojení s BPM, čili s čistě manažerskou disciplínou? Za prvé - aby vůbec mohla navrhnout smysluplné služby. Dokonce aby mohli vývojáři stanovit správnou granularitu služeb. Protože pokud udělají služby jemné, je sice větší šance na jejich znovupoužití někde jinde, ale jednak zvýší složitost jejich zapojení do byznys procesu, jednak mohou při jejich návrhu pominout nějakou podstatnou byznys logiku, kterou už v orchestraci služeb nedoženou. A je po integraci.
Je-li první důvod technický, je ten druhý politický. Máloco je dnes tak pozorně top manažery sledováno jako ROI informatických projektů. Už nelze šetřílky přesvědčit měkkými přínosy či nutností jednotné IS/IT architektury či bezpečností. Nalepením IS projektu na konkrétní byznys problém (či lépe výzvu) tato zdůvodňování padají na hlavu liniového managementu.
Z druhé strany je politická motivace také jasná - změny procesů bez možnosti jejich promítnutí do IS jsou nejen bezzubé a demotivující, ale často předem mrtvé. Přes lidi a jejich řízení se dá dokázat mnoho, ale ne natrvalo.
A ta technická motivace je taky jasná - malovat modely, které už v okamžiku jejich vzniku mohou být nepravdivé, je frustrující.
K vzájemnému propojení obou světů dochází v konceptuální technické vrstvě, kdy se napojují jednotlivé služby na reálné činnosti (byznys funkce). A jsme zpátky u granularity služeb, která musí být výsledkem shody byznys a IS pohledu. Z hlediska přínosu byznys analytika je výsledek součinem dvou jeho kompetencí - analytické schopnosti udržet správnou podrobnost a věcné znalosti podstaty konkrétního byznysu. Čili z hlediska požadavků na analytiky nic nového, tohle se už po nás chce přece dávno. Jenže pokud dřív naše modely snesly (skoro) všechno, teď to na nás praskne.
Příspěvek byl poprvé publikován před dvěma roky.