Strona poświęcona mojej pracy naukowej i usługom jakie świadczę polskim podmiotom. Zapraszam tych którzy szukają wiedzy i tych którzy szukają wsparcia w swoich projektach informatyzacji.
Analizy Biznesowe i Systemowe Przedsiębiorstw - Projektowanie Systemów Informatycznych
Temat tego czy i na ile nietechniczne kadry zarządcze, czyli tak zwany biznes, rozumieją nowe technologie przewija się regularnie przez zarówno prasę jak i blogi. Po pierwsze jest w tym wiele prawdy a po drugie niby dlaczego miało by być inaczej? Jeżeli jakaś treść jest napisana tak zwanym technicznym językiem, to odbiorca, kim jest, sam się ujawni, podobnie jak w przypadku gdy np. w samolocie niemieckich linii lotniczych stewardesa zawoła do kogoś po polsku podniosą się wyłącznie Polacy.
Z architekturą korporacyjną jest podobnie co potwierdza niżej mój kolega dr. hab. Andrzej Sobczak:
Po pierwsze TOGAF jest napisany w bardzo nieprzystępny sposób ? nawet dla osób dobrze znających angielski (występuje bardzo dużo pojęć, które nie są intuicyjne). Co więcej ?czuć?, że TOGAF został napisany przez informatyków dla informatyków (należy pamiętać, że TOGAF wywodzi się z TAFIM ? tj. Technical Architecture Framework for Information Management, a do wersji 7.0 włącznie w TOGAF?ie mówiono wyłącznie o architekturze IT, dopiero od wersji 8.0 wprowadzono koncepcję architektury korporacyjnej). Po drugie jest niezwykle obszerny (specyfikacja standardu liczy około 700 stron) i nie zawsze jest podzielona w logiczny sposób. Po trzecie wreszcie specyfikacja TOGAF jest miejscami niespójna (co do koncepcji i terminologii) i w niektórych obszarach mocno przestarzała (wynika to z historii rozwoju TOGAF?a jako standardu ? pierwsza jego wersja pojawiła się już w 1996 roku ? bez mała 20 lat temu).
To są minusy tego standardu. Jednak z roku na rok zyskuje on coraz większą popularność. Jeszcze 10 lat temu miał on 7% ?rynku ram archtektonicznych? na świecie?, obecnie jego udział zwiększył się do blisko 60%. Nie można go więc ignorować. Niezbędne jest odpowiednie ?sprzedanie? tego podejścia biznesowej części organizacji. (Jak rozmawiać z biznesem nt. TOGAF?a? | Architektura Korporacyjna).
Niezrozumiałość to chyba faktycznie efekt tego, że autorami są informatycy. Jest to akurat uzasadnione bo rodowód TOGAF to „konkurencja” dla ITIL.
Obszerność. Hm, tu akurat nie uważam by był to zarzut, specyfikacja notacji BPMN ma podobną objętość, a UML przekroczył 1000 stron. Ramy architektoniczne to także przestrzeń pojęciowa, potężny zestaw terminów mających definicje i cel istnienia czyli opisanie czegoś w spójny sposób. Tu płynnie przechodzimy do trzeciej wady: niespójność. To niestety w moich oczach praktycznie dyskwalifikuje każdy system jeżeli jest niespójny.
Niespójność oznacza powstanie potencjalnej niejednoznaczności w każdym dokumencie (modelu), w którym zostanie użyta niespójna przestrzeń pojęciowa (przypomnę, że poprawna przestrzeń pojęciowa to zestaw pojęć, które cechują: kompletność, niesprzeczność, wzajemna wykluczalność). A TOGAF i jego słownik terminów to nic innego jak pewna przestrzeń pojęć.
Czy koniecznie musi to być TOGAF?
Ile razy szukam w sieci i książkach definicji pojęcia „architektura korporacyjna” tyle razy przekonuję się, że jej nie ma bo w zasadzie każda znaleziona jest „nieco inna”. Można jednak, studiując literaturę na ten temat, dojść do przekonania, że chodzi po protu o tak zwane całościowe (jak ktoś woli to holistyczne) systemowe podejście do patrzenia na organizację (analiza systemowa).
Popatrzmy na definicje angielskie (w tym języku powstały pierwsze specyfikacje AE, źr. Oxford Dictionaries):
enteprise – a business or company: entrepreneurial economic activity
architecture – the art or practice of designing and constructing buildings, the complex or carefully designed structure of something
Tak więc wypada przyjąć, że architektura korporacyjna to
„(całościowa) struktura organizacji prowadzącej działalność o charakterze komercyjnym”.
[[Jaap Schekkerman]] w swojej książce [[How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework. Creating or choosing an Enteprice Architecture Framework]] tak definiuje AK:
Enterprise Architecture in a complete expression of the enterprise (architektura korporacyjna to kompletny opis organizacji)
Pozostaje odpowiedzieć na pytanie, co zawiera ten kompletny opis? Schekkerman, jak i wielu innych, mówi „wszystko”:
źr. Jaap Schekkerman, How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework
Mamy więc strategię i technologie oraz odpowiadające jej zdolności operacyjne (zarządcze) i technologiczne. Taki opis jest „kompatybilny” z opisem procesu biznesowego w konwencji IGOE (Input, Guide, Output, Enablers, model w projektach z obszaru [[Business Process Manamegent]]) który, poza swoim wejściem i wyjściem, jest definiowany przez reguły (guide) oraz zasoby umożliwiające jego funkcjonowanie – enablers).
Tak więc mamy odpowiedź na pytanie „Co to znaczy wszystko”. Znaczy to: koncepcja biznesowa (strategia) i sposób zarządzania oraz wymagane technologie czyli strategia ich wykorzystania i zdolność użycia (ich absorpcji). Szczególnie to ostanie ma głęboki sens, gdyż sam fakt zakupu jakiejkolwiek technologii nie jest równoznaczny z jej operacyjnym wdrożeniem (o czym przekonał się niejeden beneficjent systemu np. ERP, CRM czy BI).
Teraz przewrotnie użyję fragmentu podtytułu ww. książki:
Creating an Enterprise Architecture Framework
Tworzenie ramy architektury korporacyjnej. Jak? W sumie, o czym wspominałem w niejednym poprzednim artykule, mamy darmowy komplet narzędzi, czyli systemy pojęciowe dla każdego z powyższych czterech obszarów: strategię możemy opisać z użyciem notacji BMM, reguł biznesowych oraz procesów end-2-end i notacji BPMN. Technologię i sposób jej wykorzystania z pomocą notacji UML. Odpowiednie mapowania (powyżej: poziome i pionowe) robimy albo w macierzy, albo z pomocą Siatki Zachmana. Wybór zależy od przyjętej metody i narzędzia CASE jakim zamierzamy ten projekt dokumentować (bez narzędzia odradzam).
Organizacja OMG dobrze zadbała o spójność tych notacji (Semantic Core), czego niestety nie można powiedzieć o TOGAF i The Open Group (notacja ArchiMate niestety, nie tylko moim zdaniem, pozostawia nieco do życzenia, pomijam już jej licencjonowanie).
Teraz polecam zapoznanie się artykułem Produkty w procesie analizy wymagań. Proszę zwrócić uwagę, że powyższe cztery obszary wiedzy o organizacji: strategia biznesowa, sposób zarządzania – model biznesowy, strategia i zdolność wykorzystania nowych technologii, są objęte opisaną analizą przed-wdrożeniową i analizą wymagań. Wzajemne mapowanie obiektów z tych czterech obszarów to nic innego jak tak zwane śladowanie i walidacja: każdy element musi czemuś służyć i z czegoś wynikać. Moim zdaniem:
Specyfikacja wymagań powinna być produktem (wynikać z) Architektury Korporacyjnej, a nie powstawać każdorazowo od zera z prowadzonych setek wywiadów i warsztatów.
Tak więc projekt
Architektura Korporacyjna, moim zdaniem, nie ma sensu „sam dla siebie”. Tego typu dokumentacja służy najpierw do zrozumienia działania złożonej organizacji a potem do podejmowania decyzji o każdej reorganizacji czy inwestycji w zasoby.
Wystarczy, że każda analiza wymagań będzie prowadzona w ten sam, powtarzalny sposób i jako efekt, będzie dawała kompatybilne z poprzedni modele (i dokumenty). Narastająco tworzona dokumentacja prostą drogą poprowadzi nas do dokumentu o nazwie Nasza Architektura Korporacyjna. Zwróci się (koszty stworzenia metodyki) najprawdopodobniej już przy drugim projekcie.
Koszty analiz i projektowania
(linia czerwona obrazuje kolejne projekty analityczne i ich narastający koszt, linia niebieska to kolejne projekty analityczne zastąpione stworzeniem i utrzymaniem dokumentacji Architektury Korporacyjnej podczas pierwszego projektu, źr. Jarosław Żeliński, opracowanie własne)
Od czego należy zacząć? Od zbudowania własnej (lub własnego wariantu) metodyki jej tworzenia oraz zatrudnieniu Architekta. Czy to powinien być własny pracownik? Moim zdaniem nie, gdyż po pierwsze nie będziemy w stanie obciążyć go pracą na 100%. Po drugie powinien to być ktoś z zewnątrz, by nie był uwikłany w wewnątrzorganizacyjne zależności – Architekt korporacyjny nigdy nie powinien być interesariuszem w projekcie związanym z reorganizacją a jako pracownik zawsze nim będzie (podobnie jak lekarz domowy to raczej nikt z domowników). Kolega w innym swoim artykule pisze:
Architektura korporacyjna nie powinna być utożsamiana z formalnym opisem organizacji (jak to definiuje TOGAF) i nie powinna być tak ?sprzedawana? wewnątrz organizacji.
Jeżeli nie tak ? to w jaki inny sposób? W tym miejscu należy koniecznie odwołać się do ?ojca? koncepcji architektury korporacyjnej ? czyli J. Zachmana. Uważa on, że architektura korporacyjna pomaga rozwiązywać problemy organizacji w iteracyjny i przyrostowy sposób. Przedstawiciele firmy iCMG idą wręcz dalej ? nazywają oni architekturę korporacyjną dyscypliną naukową zajmującą się tworzeniem, działaniem i rozwojem organizacji. (Czy już pora wymyślić od nowa architekturę korporacyjną? | Architektura Korporacyjna).
i wypada mi się z nim zgodzić 🙂 poza jednym: uważam, że powinien być to opis formalny bo tylko wtedy będzie jednoznaczny i „naukowy”. Tylko wtedy będzie możliwe jego „badanie” np. przeprowadzenie analizy skutków decyzji o reorganizacji zanim ją rozpoczniemy.
Teraz zapewne ktoś powie, że piszę tak tylko dlatego, że świadczę takie usługi. Otóż jest dokładnie odwrotnie: świadczę takie usługi bo głęboko wierzę, że tak właśnie należy postępować, bo – jeżeli organizacja istnieje to ona, architektura, też jest, należy ją tylko przeanalizować, zbudować jej model i korzystać z niego przy podejmowaniu każdej ryzykownej decyzji. Dobry model powinien wolno się zmieniać, tak jak wolno się zmienia organizacja. Jeżeli model jest zbyt szczegółowy i wymaga dużych nakładów na jego aktualizacje jest złym modelem.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę 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. Masz pytania?
Umów się na krótkie konsultacje.
Nie dałoby się przywrócić możliwości kopiowania fragmentów tekstu z Pana strony? Łatwiej skomentować fragment artykułu, a ci którzy chcą do złych celów wykorzystać treści i tak sobie poradzą z tym zabezpieczeniem 🙂
Strona używa plików cookie, aby zapewnić Ci wygodę przeglądania poprzez zapamiętywanie Twoich preferencji i powtarzających się wizyt. Klikając "Akceptuj wszystko", wyrażasz zgodę na użycie WSZYSTKICH plików cookie. Jednakże, możesz odwiedzić "Ustawienia plików cookie", aby zapewnić kontrolowaną zgodę.
Ta strona korzysta z plików cookie, aby poprawić wygodę podczas podczas przeglądania witryny. Pliko cookie, które są sklasyfikowane jako niezbędne, są przechowywane w przeglądarce, ponieważ są niezbędne do działania podstawowych funkcji witryny. Używamy również plików cookie stron trzecich, które pomagają nam analizować i zrozumieć, w jaki sposób korzystasz z tej witryny. Te pliki cookie będą przechowywane w przeglądarce tylko za Twoją zgodą. Możesz również zrezygnować z tych plików cookie. Ale rezygnacja z niektórych z tych plików cookie może mieć wpływ na wygodę przeglądania.
Niezbędne pliki cookie są absolutnie niezbędne do prawidłowego funkcjonowania witryny. Ta kategoria obejmuje tylko pliki cookie, które zapewniają podstawowe funkcje i zabezpieczenia strony. Te pliki cookie nie przechowują żadnych danych osobowych.
Wszelkie pliki cookie, które mogą nie być szczególnie potrzebne do działania witryny i są wykorzystywane w szczególności do gromadzenia danych osobowych użytkowników za pośrednictwem analiz, reklam i innych treści osadzonych, są określane jako niepotrzebne pliki cookie. Wymagane jest uzyskanie zgody użytkownika przed uruchomieniem tych plików cookie w witrynie.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Cookie
Duration
Description
__atuvc
1 year 1 month
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
__atuvs
30 minutes
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
bcookie
2 years
LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID.
bscookie
2 years
LinkedIn sets this cookie to store performed actions on the website.
language
session
This cookie is used to store the language preference of the user.
lidc
1 day
LinkedIn sets the lidc cookie to facilitate data center selection.
na_id
1 year 24 days
The na_id is set by AddThis to enable sharing of links on social media platforms like Facebook and Twitter.
ouid
1 year 24 days
Associated with the AddThis widget, this cookie helps users to share content across various networking and sharing forums.
vc
1 year 24 days
The vc cookie is set by addthis.com on sites that allow sharing on social media.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
at-rand
never
AddThis sets this cookie to track page visits, sources of traffic and share counts.
browser_id
5 years
This cookie is used for identifying the visitor browser on re-visit to the website.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
uid
1 year 24 days
This is a Google UserID cookie that tracks users across various website segments.
uvc
1 year 1 month
Set by addthis.com to determine the usage of addthis.com service.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
di2
1 year 24 days
AddThis sets this cookie on sites that allow sharing on social media. It is used to track user behaviour anonymously, to create usage trends that will improve relevance to their services and advertising.
loc
1 year 1 month
AddThis sets this geolocation cookie to help understand the location of users who share the information.
um
1 year 24 days
Set by AddThis for registering the user's sharing of content through social media.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt.innertube::nextId
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
yt.innertube::requests
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
Panie Jarku,
Nie dałoby się przywrócić możliwości kopiowania fragmentów tekstu z Pana strony? Łatwiej skomentować fragment artykułu, a ci którzy chcą do złych celów wykorzystać treści i tak sobie poradzą z tym zabezpieczeniem 🙂
pozdrawiam,
Daniel
Ok, ogłaszam moratorium 🙂
W kwestii definicji AE wpadłem na cos takiego 🙂 Many (flawed) Definitions of Business Architecture