Nasza strona używa cookies. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

CMDB vs. repozytorium architektoniczne. Gdzie leży prawda?

Sprawne zarządzanie CMDB i repozytorium architektonicznym oraz umiejętne ich łączenie może mieć istotny wpływ na sprawne osiąganie celów biznesowych.

Często zastanawiamy się, po co w organizacjach są rozwiązania, które nie służą wprost realizacji celów biznesowych. W wyobrażeniach wielu osób są jedynie po to, by dokumentować stan i działania dotyczące IT w organizacji. Takimi bytami są między innymi CMDB (Configuration Management Database) oraz repozytorium architektoniczne. Opiszę pokrótce, czym jest jedno i drugie, co dają organizacji i dlaczego ważne jest zachowanie spójności między nimi.

Skupię się tutaj na kwestiach merytorycznych, jak zawartość obu powinna ze sobą współgrać, a nie jak technicznie połączyć te dwa repozytoria.

 


A co to jest CMDB i po co to?

Wyobraź sobie katalog elektronicznych sprzętów, których używasz. Powiesz no dobra, ale po co ja mam katalogować to, czego używam? Przecież świetnie to znam, wiem, co jest gdzie, do czego służy i jak działa. Do pewnego stopnia tak, ale czy na pewno? Masz w głowie, jak przebiega instalacja elektryczna albo komputerowa sieć przewodowa? Jak rozkłada się dystrybucja sygnału WiFi? Czy znasz informacje o gwarancjach, wiesz co zrobić, jak się zepsuje sprzęt? 

Pewnie masz jakieś teczki, instrukcje, spisy telefonów itp. Nawet na własnym komputerze, telefonie, tablecie itd. masz spis działających aplikacji, ale czy będziesz pamiętał szczegóły ich instalacji po kilku latach, jak działają i czemu służą ich funkcje? 

A teraz wyobraź sobie organizację, w której nie jesteś sam lub ewentualnie z rodziną/znajomymi, ale pracuje w niej kilkadziesiąt, kilkaset lub nawet kilka tysięcy osób. Każdy używa sprzętów elektronicznych czy wręcz informatycznych z zainstalowanym różnym oprogramowaniem. Powoduje to, że mamy kilkadziesiąt lub wręcz kilkaset systemów do różnych celów. Różnią się wielkością, sposobem dostarczania, dostawcami, technologią. Zainstalowane są na oddzielnej infrastrukturze, być może w różnych centrach przetwarzania lub w chmurze, pracują w wielu reżimach czasowych i na dodatek są ze sobą powiązane. 

W takiej sytuacji jest potrzeba zebrania informacji o tych systemach i powiązaniach, żeby wiedzieć, co i gdzie mamy zainstalowane, po co to jest i od czego zależy. Jest to ważne, aby móc zapewnić optymalne działanie systemów, a w przypadku awarii móc reagować szybko i właściwie. 

To jest właśnie CMDB, czyli Configuration Management Database. Baza (często osobny system), która zawiera informacje o kluczowych zasobach informatycznych w danej organizacji. Nazwa wywodzi się z ITIL, czyli zbioru dobrych praktyk dotyczących zarządzania usługami informatycznymi, powstałym jeszcze w latach 80, a obecnie rozpowszechnionym jako zbiór pewnych standardów w świecie informatycznym.

Zatem CMDB jest właściwym miejscem, z którego można czerpać wiedzę o złożonym środowisku informatycznym - jego komponentach i ich charakterystyce, żeby wiedzieć, czym dysponujemy, jak to działa, w przypadku awarii, szybko określać jej wpływ i być w stanie ją sprawnie usunąć. Dodatkowo jeśli organizacja podlega regulacjom zewnętrznym, musi też raportować stan swoich zasobów informatycznych. Do tego też służy CMDB. 


Druga strona konfiguracji, czyli repozytorium architektoniczne

CMDB zawiera informacje o zasobach informatycznych działających w firmie, ale daje to obraz na dany moment. Skoro jedyną stałą we wszechświecie jest zmiana, to potrzeba czegoś więcej. Repozytorium, w którym będzie można projektować zmiany w zasobach informatycznych wynikających z realizacji strategii danej organizacji, inicjatyw biznesowych, wymiany technologii na te dostarczane przez dostawców, czy wdrażania nowych koncepcji, stylów, frameworków itp. w tworzeniu oprogramowania lub stawianiu infrastruktury. Do projektowania takich zmian służy właśnie repozytorium architektoniczne. 

Oczywiście, żeby zaprojektować zmiany, trzeba się odnieść również do stanu obecnego, więc repozytorium architektoniczne zawiera również informacje o bieżącej architekturze systemów, elementach je tworzących i relacjach między nimi. 

Repozytorium z reguły zawiera elementy z różnych obszarów architektonicznych, takich jak architektura biznesowa zawierająca informacje o organizacji, produktach i procesach biznesowych, architektura aplikacyjno-systemowa (zwana często logiczną) zajmująca się obszarem powiązań funkcji biznesowych z systemami i ich komponentami, które je mają realizować, czy architektura techniczna (zwana często infrastrukturalną) dotycząca stosowanych rozwiązań infrastrukturalnych, platform, czy narzędzi koniecznych do działania systemów. Często też obszar aplikacyjno-systemowy łączy się z architekturą danych, w której specyfikujemy i opisujemy obszary danych i ich powiązanie z systemami. 

Repozytorium zatem zawiera częściowo te same informacje, co CMDB, ale różni się perspektywą czasową i zakresem informacji. Pokazuje przyszłe zmiany, coś, czego jeszcze w organizacji nie ma, bo dopiero projektujemy. Odnosi się też do komponentów, które mogą, ale nie muszą zostać wdrożone.

Drugą różnicą jest kwestia notacji. O ile w CMDB, które jest bazą danych, mamy po prostu tabele i kolumny, raporty czy proste wizualizacje, o tyle w repozytorium architektonicznym istotną rolę odgrywa graficzne (symboliczne) przedstawienie elementów i ich charakterystyk oraz zależności między nimi. Robi się to po to, by zebrana informacja była czytelna i zrozumiała dla różnych odbiorców  - od przedstawicieli obszarów biznesowych, przez doświadczonych developerów czy administratorów aż do zewnętrznych dostawców usług informatycznych. 

Stosuje się też określone notacje (wizualizacje). W architekturze najczęściej używa się notacji opartej o język modelowania UML do modelowania problemów w różnych obszarach w tym IT, albo ARCHIMATE - język modelowania dedykowany dla obszarów architektury korporacyjnej. Wybór notacji dyktuje poziom szczegółowości, nazewnictwo i formę graficzną przedstawianych diagramów

Kolejna różnica to kwestia kontekstu. W CMDB patrzymy na stan systemów, serwerów oraz procesów biznesowych, które wspierają, a w repozytorium architektonicznym potrzebujemy pokazać całościowo zmiany, czyli przejście z obecnego stanu do stanu pożądanego. Najczęściej zmiany są złożone i dotyczą wielu systemów lub ich modułów i wielu komponentów infrastrukturalnych, a nie pojedynczego procesu, systemu lub serwera. 


Zasady łączenia CMDB z repozytorium architektonicznym

Efektywność korzystania z informacji zgromadzonych w CMDB i repozytorium architektonicznym zależy od sposobu zarządzania tymi bazami. Poniżej kilka istotnych czynników, które mogą znacząco ułatwić bieżącą pracę w IT. 


Ontologia

Ważne jest, żeby była ona spójna między CMDB i repozytorium architektonicznym. Wszelkie nazwy od procesów, przez usługi, systemy i ich komponenty logiczne czy infrastrukturalne, aż do ich parametrów, powinny być nazywane tak samo. Cała klasyfikacja obiektów powinna być też spójnie budowana i opierać się na identycznych sformułowaniach. Do tego dochodzą relacje między wszystkimi obiektami, które funkcjonują w CMDB oraz w repozytorium architektonicznym. One też powinny mieć spójne nazewnictwo, żeby każdy używający wiedział, o co chodzi i żeby wymiana informacji między osobami, ale też między systemami, działała poprawnie. 


Jedno źródło prawdy

Przy ustalaniu powiązań między elementami w CMDB a repozytorium architektonicznym ważne jest określenie, które miejsce dla danych informacji jest głównym repozytorium (tzw. źródłem master), dla którego uznajemy, że dane w nim przechowywane są tymi najbardziej poprawnymi. 

W sytuacji, kiedy operujemy na odrębnych fizycznych repozytoriach (a najczęściej tak jest), na pewno część informacji będzie tylko w CMDB (np. o dostawcy oprogramowania, umowach SLA, właścicielach czy opiekunach systemu), a część będzie tylko w repozytorium architektonicznym (szczegóły funkcjonalne czy dane o relacjach z innymi systemami) i wtedy oczywiste jest, które źródło jest „ważniejsze”. 

Natomiast duża część informacji znajduje się w obu miejscach i wtedy dane powinny się w 100% zgadzać. Jeśli tak nie jest, trzeba ustalić, które źródło uznajemy za podstawowe, a dane w nim za poprawne. Najczęściej za poprawne uważamy dane w CMDB, ponieważ to repozytorium jest formalnie uznane w organizacji jako źródło wiedzy na temat stanu środowiska informatycznego. Jest szeroko dostępne, aktualizowane przez wiele osób z organizacji czy mechanizmów automatycznych w zakresie parametrów działających systemów. 

Zatem o ile dane są przechowywane w CMDB, to uznajemy, że to jest źródło prawdy i aktualizujemy repozytorium architektoniczne właśnie na podstawie danych z CMDB. Synchronizacja może się odbywać automatycznie pomiędzy bazami danych lub na poziomie aplikacyjnym, ważne jest, by była realizowana niezwłocznie, uwzględniała potencjalne różnice w ontologii obiektów oraz by dane importowane do repozytorium architektonicznego nie wpływały negatywnie na prace w zakresie projektowania zmian. 


Cykl życia obiektów

Zarówno organizacje, jak i ich środowiska informatyczne ciągle się zmieniają i rozwijają. Pojawiają się nowe technologie, mechanizmy działające w inny sposób z użytkownikami (np. zmienia się sposób obróbki dokumentów). To powoduje pojawianie się nowych systemów, zmiany w istniejących, czy wręcz wycofanie starych technologii, urządzeń i systemów. 


W repozytorium architektonicznym są projektowane zmiany środowiska informatycznego, tam się pojawią nowe systemy i ich komponenty. Tam też będą projektowane zmiany do istniejącej infrastruktury, zanim się one zmaterializują i będą opisane w CMDB. Zatem dla takich przypadków to repozytorium architektoniczne będzie zawierało prawidłowe informacje, a sięganie po nie do CMDB może skutkować błędnymi decyzjami, np. w zakresie określania kosztów realizacji projektów, wyborów dotyczących używanych technologii czy planowaniu wykorzystania działających zasobów. 

Oczywiście na pewnym etapie realizacji zmian musi się dokonać aktualizacja danych w CMDB. W zakresie parametrów wdrażanych rozwiązań oraz w sytuacji zmian tej parametryzacji, która często może się pojawić na późniejszym etapie niż przygotowanie architektury, a na pewno po wdrożeniu zmian konieczna jest też zwrotna aktualizacja w repozytorium architektonicznym, by utrzymać spójność danych.


Podsumowanie

Jak widać opis środowiska informatycznego może być złożony i wymagać wysiłku, by go poprawnie zamodelować, skonstruować oraz utrzymywać. Na końcu drogi ważne jest, by to, co opisujemy, było zgodne z rzeczywistością. Od tego zależy prawidłowe i stabilne działanie organizacji, współpraca między zespołami IT i biznesem, a także współpraca organizacji z otoczeniem. Nie należy też zapominać, że spójne repozytorium wspomaga osiąganie założonych celów biznesowych. 

1 komentarz
Zobacz kogo teraz szukają