sty
01

Quo Vadis UML?

Źródło: Andrzej Sobczak
kompas

Język UML ma długą historię.  Jego początki sięgają połowy lat 90-tych XX w., kiedy to Grady Booch, Ivar Jacobson oraz James Rumbaugh rozpoczęli wspólne prace nad zunifikowanym językiem modelowania systemów informatycznych, który wspierałby paradygmat obiektowy. W czerwcu 1996 roku opracowana została dokumentacja języka UML w wersji 0.9.  Następnie powstało konsorcjum odpowiedzialne za rozwój UML, w które zaangażowali się tacy giganci jak HP, IBM, Oracle i Microsoft. Wynikiem współpracy był UML 1.0. W styczniu 1997 roku UML 1.0 przekazano grupie Object Management Group (OMG), która do dzisiaj zajmuje się jego rozwojem.

gru
07

Nowa wersja języka ArchiMate

Źródło: Andrzej Sobczak
archimate21

Na początku grudnia 2013 r. konsorcjum The Open Group opublikowało nową wersję standardu dla języka ArchiMate – opatrzoną numerem 2.1. O ile wersja  2.0 języka ArchiMate (była ona opublikowana blisko dwa lata temu – bo w styczniu 2012 r.) stanowiła istotną różnicę w stosunku do wersji 1.0 (wprowadzono m.in. rozszerzenia języka dotyczące implementacji, czy też motywacji), o tyle wersja 2.1 w stosunku do 2.0 wnosi jedynie zmiany porządkujące/kosmetyczne.  Zmiany te zostały przygotowane na bazie uwag/komentarzy użytkowników wcześniejszej wersji języka.  Poniżej zostały przedstawione wprowadzone  modyfikacje (muszę przyznać, że chociaż dobrze znam ten język – musiałem spędzić sporo czasu aby je wyłapać; […..]

wrz
03

Trzy kategorie produktów architektonicznych

Źródło: Andrzej Sobczak
trzy_pudelka

Firma analityczna Gartner dokonała klasyfikacji produktów architektów korporacyjnych na trzy kategorie – tj. produkty diagnostyczne (diagnostic products), produkty umożliwiające podjęcie określonych działań/decyzji (enabling products) oraz produkty wykonywalne (actionable products). Uważam, że to bardzo dobry pomysł, bo od razu można określić, czego należy spodziewać się od produktu, należącego do danej kategorii. Poza tym ta klasyfikacja zmusza do przygotowania materiałów, które nie mają jedynie charakteru tzw. “paper consulting”. Do pierwszej kategorii (tj. produktów diagnostycznych) zaliczyłbym wszystkie te materiały, które opisują stan bazowy (stan odniesienia) – czyli architekturę “as-is”. Do kategorii produktów umożliwiających podjęcie określonych działań/decyzji zaklasyfikowałbym definicję pryncypiów architektonicznych, wizję architektury, opis standardów, opis […..]

gru
03

Wymiana modeli architektury korporacyjnej

Źródło: Andrzej Sobczak
puzzle

W sytuacji, w której organizacja stosuje produkty różnych firm do tworzenia modeli architektonicznych w pewnym momencie pojawia się problem: w jaki sposób wymieniać te modele między poszczególnymi narzędziami. W tym celu najczęściej stosuje się mechanizmy bazujące na standardzie XMI. Skrót XMI pochodzi od zwrotu “XML Metadata Interchange”. Standard ten jest rozwijany przez Object Management Group (OMG) i  od samego początku nastawiony był na wymianę modeli z wykorzystaniem odpowiednio zaadaptowanego języka XML. Za jego pomocą  można np. eksportować i importować modele w najpopularniejszym narzędziu w Polsce – tj. Enterprise Architect firmy Sparx. Oczywiście nie ma róży bez kolców.

lis
27

Jaki powinien być idealny język modelowania EA?

Źródło: Andrzej Sobczak
model_ea

Wiadomo, że każdy z języków stosowanych obecnie do tworzenia modeli architektury korporacyjnej ma swoje ograniczenia. Np. w mojej subiektywnej ocenie UML jest zbyt techniczny i złożony w przygotowywaniu modeli, których odbiorcami ma być również biznes. W przypadku BPMN jego zastosowanie ogranicza się tylko do procesów. Ta sama sytuacja występuje w przypadku EPC. ArchiMate jest ciągle mało popularny (chociaż moim zdaniem najbardziej zbliża się do ideału języka dedykowanego architektom korporacyjnym).

cze
18

Dobre praktyki modelowania architektury korporacyjnej

Źródło: Andrzej Sobczak
best_practices

Procesu tworzenia architektury korporacyjnej nie da się zautomatyzować. W znacznym stopniu przypomina on bowiem prace o charakterze twórczym (niektórzy wręcz mówią o sztuce tworzenia architektury korporacyjnej).

cze
06

Katalog architektonicznych punktów widzenia (viewpoints)

Źródło: Andrzej Sobczak
Businessman looking for business

W jednym z wcześniejszych wpisów przedstawiłem różnice pomiędzy widokami (views) oraz punktami widzenia (viewpoints). Dla przypomnienia widok to reprezentacja zbioru powiązanych ze sobą trosk (concerns) interesariusza/interesariuszy (przy czym troski są to kluczowe obszary zainteresowania, które mają szczególne znaczenie dla danej grupy interesariuszy). Natomiast punkt widzenia definiuje perspektywę, z której ujmowany jest dany widok. Zawiera on informacje dla kogo (jakiego grona interesariuszy) dany widok będzie tworzony oraz jaka będzie przyjęta konwencja konstruowania i używania tego widoku.