Regularnie czy­tam blog Andrzeja Sobczaka, pro­fe­so­ra SGH. Czasami bywa, że mam odmien­ne zda­nie niż tam pre­zen­to­wa­ne, i tym razem też tak jest. Ostatni wpis na tym blo­gu zawie­ra sied­mio­punk­to­wą pro­gno­zę na rok 2015. W zasa­dzie trud­no w tych pro­gno­zach odmó­wić racji auto­ro­wi jed­nak dwa punk­ty, moim zda­niem, war­te się komentarza.

2. W tym roku nie docze­ka­my się jesz­cze wdro­że­nia w pol­skim przed­się­bior­stwie peł­nej kon­cep­cji archi­tek­tu­ry korporacyjnej

Na pyta­nie ?ile orga­ni­za­cji w Polsce wdro­ży­ło? kom­plek­so­wo kon­cep­cję archi­tek­tu­ry kor­po­ra­cyj­nej [w tym w dome­nie archi­tek­tu­ry biz­ne­so­wej] ? cią­gle odpo­wia­dam: zero (jeże­li się mylę ? pro­szę o kon­takt; przy­ja­dę z butel­ką dobre­go wina i prze­pro­szę taką orga­ni­za­cję i jej Głównego Architekta). (Architektura kor­po­ra­cyj­na w roku 2015 ? pro­gno­za | Architektura Korporacyjna).

Bez defi­ni­cji owej peł­nej kon­cep­cji archi­tek­tu­ry kor­po­ra­cyj­nej” trud­no jest mi uznać te pro­gno­zę za wery­fi­ko­wal­ną. Tak więc moż­na (trze­ba) tu przy­jąć ogól­ną powszech­nie cyto­wa­na w lite­ra­tu­rze defi­ni­cję: Architektura kor­po­ra­cyj­na (ang. Enterprise Architecture) ? zbiór wła­ści­wo­ści danej kor­po­ra­cji (włącz­nie ze struk­tu­rą), któ­re sta­no­wią o zdol­no­ści do reali­za­cji jej misji. Obecnie przyj­mu­je się, że owa struk­tu­ra to czte­ry elementy:

Based on this bro­ade­ning of sco­pe, Enterprise Architecture now covers:

  1. Business Architecture
  2. Data Architecture
  3. Application Architecture
  4. Infrastructure Architecture

(źr. What is Enterprise Architecture? > Business Analyst Community & Resources | Modern Analyst).

Od sie­bie dodam, że punkt 2. to tak na praw­dę, w obec­nej posta­ci sys­te­mów zorien­to­wa­nych obiek­to­wo, obiek­ty biz­ne­so­we” rozu­mia­ne jako nośni­ki danych” (np. Faktura, Zamówienie, itp.). Pojęcie to, nośnik danych, zosta­ło już ugrun­to­wa­ne w nota­cjach od ponad dzie­się­ciu lat, a od cza­su poja­wie­nia się nota­cji [[BPMN]] sta­ło się stan­dar­dem. Używanie poję­cia archi­tek­tu­ra danych” może (z regu­ły już myl­nie) suge­ro­wać, że cho­dzi o model danych, rozu­mia­ny jako rela­cyj­ny model danych” zna­ny z metod struk­tu­ral­nych z lat 80-tych.

Tak więc dzi­siej­sza struk­tu­ra tego co nazy­wa­my tu Architekturą Korporacyjną to:

  1. Architektura Biznesowa (struk­tu­ral­ny model biznesowy)
  2. Architektura Informacyjna (obiek­ty biz­ne­so­we , model informacyjny)
  3. Architektura Aplikacyjna (struk­tu­ra kom­po­nen­tów opro­gra­mo­wa­nia IT)
  4. Architektura Infrastruktury (model wdrożeniowy)

Nie moż­na zapo­mnieć, że to co nazy­wa­my archi­tek­tu­rą biz­ne­so­wą, jest mode­lem moty­wa­cji biz­ne­so­wej sko­ja­rzo­nym z mode­lem pro­ce­sów biz­ne­so­wych. W jed­nym ze swo­ich arty­ku­łów na ten temat poda­łem definicję:

Architektura Korporacyjna to model i jego doku­men­ta­cja, zawie­ra­ją­cy całą i wystar­cza­ją­cą wie­dzę o tym, co ma wpływ na dostar­cza­nie (przez orga­ni­za­cję) pro­duk­tu (Architektura kor­po­ra­cyj­na z OMG​.org | Jarosław Żeliński IT-Consulting).

Definicja ta powsta­ła na uży­tek moich pro­jek­tów, gdyż klien­ci pyta­li – i słusz­nie – co im dostar­czę w ramach świad­czo­nej usłu­gi. Tak więc dostar­czam to swo­im klien­tom od kil­ku lat. Osobną kwe­stią jest to czy zawsze jest ten model dalej utrzy­my­wa­ny. Nie wiem, bo czę­sto tra­cę z nim kon­takt po zakoń­cze­niu pro­jek­tu, ale nie zawsze, bo u nie­któ­rych klien­tów zarzą­dzam zmia­ną w tym mode­lu (jego cyklem życia).

Tak więc na pyta­nie czy na pew­no nie docze­ka­my się jesz­cze wdro­że­nia w pol­skim przed­się­bior­stwie peł­nej kon­cep­cji archi­tek­tu­ry kor­po­ra­cyj­nej” odpo­wia­dam: to zale­ży co rozu­mie­my pod poję­ciem peł­na koncepcja”.

Kolejny punkt pro­gno­zy, któ­ry sko­men­tu­ję to:

4. Architektura kor­po­ra­cyj­na nie będzie jesz­cze umia­ła odna­leźć się w świe­cie chmu­ry i wirtualizacji

Brutalna praw­da jest taka, że obec­ne języ­ki mode­lo­wa­nia archi­tek­tu­ry kor­po­ra­cyj­nej (typy ArchiMate, UML) nakie­ro­wa­ne są na opis sta­tycz­ny (nawet, jak mówi­my o trans­i­tion ? to zawsze są okre­ślo­ne momen­ty w cza­sie). (Architektura kor­po­ra­cyj­na w roku 2015 ? pro­gno­za | Architektura Korporacyjna).

Tu zupeł­nie się nie zga­dzam. Chmura to wyłącz­nie meto­da imple­men­ta­cji i udo­stęp­nie­nia dwóch ostat­nich warstw, przy­po­mnę są to: Architektura apli­ka­cyj­na (struk­tu­ra kom­po­nen­tów opro­gra­mo­wa­nia IT) i Architektura Infrastruktury (model wdro­że­nio­wy). Wobec tego nie musi powstać w żad­na nowa nota­cja dla chmu­ry (tu i nie tyl­ko tu, kła­nia się [[brzy­twa Ockhama]]). Po dru­gie [[UML]] zawie­ra dość boga­ty zestaw narzę­dzi do mode­lo­wa­nia dyna­mi­ki sys­te­mu, ot choć­by dia­gram sekwen­cji czy komu­ni­ka­cji. Mamy też od nie­daw­na nota­cje (pro­fil UML) [[SoaML]] (podob­nie jak [[SysML]]).

ChaosMonkeyAutor w swo­im arty­ku­le powo­łu­je się na nie­moż­ność opra­co­wa­nia mode­lu” cze­goś co nazwa­no Chaos Monkey:

Chaos Monkey is a servi­ce which iden­ti­fies gro­ups of sys­tems and ran­dom­ly ter­mi­na­tes one of the sys­tems in a group.

Albo ja cze­goś nie rozu­miem, albo mówi­my o usłu­gach ad-hoc lub wywo­ły­wa­nych wg okre­ślo­nych reguł (tych może być wie­le), a opra­co­wa­nie mode­lu takie­go sys­te­mu nie sta­no­wi żad­ne­go pro­ble­mu, jed­nak tu zazna­czam, że moż­li­we jest moje nie­zro­zu­mie­nie. Zwrócę tu tak­że uwa­gę, że regu­ły mogą być opar­te na losowaniu.

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 2 komentarzy

  1. Andrej Sobczak

    Dziękuję za przy­go­to­wa­nie komen­ta­rza do moje­go wpi­su. Dla mnie archi­tek­tu­ra = mode­le + ich zasto­so­wa­nie pod­czas podej­mo­wa­nia decy­zji (czy­li idą za tym okre­ślo­ne struk­tu­ry i pro­ce­sy orga­ni­za­cyj­ne). Dlatego napi­sa­łem, że nie docze­ka­my się jesz­cze wdro­że­nia w pol­skim przed­się­bior­stwie peł­nej kon­cep­cji archi­tek­tu­ry kor­po­ra­cyj­nej?. Ale oczy­wi­ście jest to tyl­ko jed­no z moż­li­wych spoj­rzeń na EA.
    Jeżeli cho­dzi o mode­lo­wa­nie dyna­mi­ki sys­te­mów – to oczy­wi­ście moż­na wyko­rzy­stać tutaj UML’a i wska­za­ne przez Ciebie dia­gra­my. Przy czym nie jestem do koń­ca prze­ko­na­ny, że jest to nota­cja dla archi­tek­ta kor­po­ra­cyj­ne­go (choć bar­dzo popu­lar­na, otwar­ta, wszechstronna,…).
    W żad­nym pro­jek­cie nie spo­tka­łem SoaML – ale może czas to zmienić :).

    1. Jaroslaw Zelinski

      Co do zasto­so­wań moich pro­duk­tów w 100% są uży­wa­ne do opra­co­wa­nia decy­zji co to ma zostać zmienione/kupione” więc jest 🙂
      Co do mode­lo­wa­nia dyna­mi­ki to dia­gram sekwen­cji jako model komu­ni­ka­cji” (pomi­jam for­me gra­fi­czą) jest od dośc daw­na w uży­ciu (np. w takiej mało UML’owej for­mie: http://​www​.code​pro​ject​.com/​K​B​/​d​o​t​n​e​t​/​E​m​a​i​l​F​r​a​m​e​w​o​r​k​/​S​e​q​u​e​n​c​e​.​png)
      SoaML to kolej­ny pro­fil UML, bar­dzo mło­da nota­cja. Ale moim zda­niem sko­ro clo­ud to jakaś for­ma zaso­bów IT to zanie­dbu­jąc odle­głość do infra­struk­tu­ry” w mode­lu AK nie­spe­cjal­nie się chy­ba wyróżnia…

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.