Analiza a architektura

Data: 2012-04-07
Autor: Sebastian Konkol
Analiza a architektura

Co jakiś czas, w ramach mojej bieżącej praktyki zawodowej, trafiam na temat wart opisania, choć związany bardziej z tą techniczną stroną moich działań. Ostatnio, w ramach jednego z projektów w jakich uczestniczę, wdałem się w dyskusję klasy „a nie mówiłem”. Sens takich dyskusji, o czym przekonujemy się zwykle już po ich zakończeniu, jest żaden. Tym niemniej, często przejawia się w nich ziarno mądrości, które warto pochwycić. W dyskusji, o której wspomniałem, takim ziarnem było wyjaśnienie zagadnienia architektura rozwiązań IT vs. analiza wymagań – kto teraz powinien rządzić: analityk, czy architekt.

Pod koniec XX wieku, powiedzmy na przełomie lat osiemdziesiątych i dziewięćdziesiątych, systemy informatyczne oparte na „wymaganiach użytkowników” pisane były na zamówienie. Odbiorca miał oczekiwania, przychodził analityk, analizował wymagania i produkował dokument analizy wymagań. Ten dokument był przewodnikiem po tym, czego oczekuje się od systemu – brali go projektanci i programiści, i przetwarzali go na system w wybranym przez siebie języku programowania. Tworzony był system informatyczny, który – nawet jeśli zawierał jakieś biblioteki, „gotowe” elementy – był dla klienta całością, monolitem. No i oczywiście na samym końcu okazywało się, że klient jednak nie miał racji, kiedy mówił, że czegoś chciał. Ale to już inna sprawa…

Systemy informatyczne jednak już od dość dawna nie są budowane od podstaw „na zamówienie” – są składane z komponentów. Ma to uzasadnienie zdroworozsądkowe i ekonomiczne. Zdrowy rozsądek, bo większość systemów (poza być może bardzo niszowymi rozwiązaniami) korzysta z tej samej bazy (np. serwerów aplikacyjnych, baz danych,  silników workflow, hurtowni danych itp.). Ekonomika, bo różne komponenty mogą być już w posiadaniu odbiorcy i kupowanie nowych nie powinno mieć miejsca (o ile wybór dokonany został rozsądnie). Dzisiaj sprawy biegną nieco inaczej. Najpierw określa się, czym jakiś system informatyczny ma być (bardzo zgrubnie „ociosane” oczekiwania odbiorcy) i gdzie mają być jego granice (czego na pewno nie powinien on robić). W ten sposób tworzona jest architektura rozwiązania – rola systemu, komponenty stanowiące szkielet rozwiązania, sposób ich łączenia i wykorzystania dla wypełnienia oczekiwanej roli, stosowane wzorce i standardy. Krótko mówiąc, wskazywane są: obszary elastyczności i obszary usztywnienia konstrukcji systemu. Taki opis dużo łatwiej jest przyswoić, ogarnąć jednocześnie i przedyskutować (ze zrozumieniem) z odbiorcą przyszłego systemu. Najpierw więc architektura rozwiązania.

Dopiero później przechodzi się do określania, jakie szczegółowe wymagania ma tenże system spełniać. Dla przykładu, jeśli jakiś system ma obsługiwać określony proces biznesowy, to dla ekonomicznego doboru komponentów tworzących system nie na konieczności znać pełnej definicji przebiegu tego procesu (krok po kroku) – wystarczy wiedzieć, czy ten proces ma charakter stały (wtedy może być „zakodowany” na stałe), czy może się istotnie zmieniać w czasie (wtedy powinna być wykorzystana gotowa platforma workflow). Taka filozofia opisu wymagań ma ogromne znaczenie. Określenie architektury rozwiązania to nie tylko kilka schematów i górnolotnych opisów – to także określenie bardzo konkretnych ram dla opisu wyników analizy wymagań. Wymagania bowiem powinny być „przyklejone” do określonych elementów architektury, a dobór tych komponentów determinuje często metodę opisu wymagań.

Przydałaby się jakaś analogia, żeby odnieść się do czegoś mniej kontrowersyjnego – niech będzie budownictwo. Kiedy zabieramy się za budowę domu jednorodzinnego, to nie określamy wymagań odnośnie umieszczenia gniazda elektrycznego na północnej ścianie kuchni – decydujemy o charakterze budynku: ile ma mieć pokoi, czy ma być energooszczędny, jaki charakter ma mieć elewacja, ile ma mieć kondygnacji itd. Decydujemy o architekturze budynku i nie musimy nawet zdawać sobie sprawę z wymagań na zapotrzebowanie na świeżą wodę i rozkład grzejników. Kiedy się już jednak zdecydujemy, wszystkie wymagania przywiązujemy do architektury. To architektura właśnie pozwala nam odróżnić dom jednorodzinny nowoczesny od małego dworku. Co więcej, to architektura narzuca sposób wykonania wszelkich projektów (konstrukcja, instalacje, wykończenia). Ustalamy architekturę na długo wcześniej, niż uzmysłowimy sobie wymagania stawiane przed poszczególnymi rzeczami w domu.

Dlaczego o tym piszę? W projekcie, o którym wspomniałem na początku, miała miejsce sytuacja, w której opracowałem architekturę dla całkiem złożonego systemu, po czym analiza wymagań poszła swoją ścieżką, bez zachowania związku z architekturą. Efekt? Awantura u klienta, niespójny wynik prac, wiele dodatkowego wysiłku. Bałagan strasznych rozmiarów. I to wcale nie jest tak, że architekci (jak ja) chcą być ważniejsi. To zasady i metody konstrukcji współczesnych systemów informatycznych wymagają takiej zmiany. Najpierw zrozumienie ogólnych oczekiwań odbiorcy i ich synteza dająca w wyniku architekturę systemu, a dopiero później rozbieranie na drobne i analiza wymagań, opisywanych zgodnie z architekturą. Najpierw architekt (synteza), później analityk (analiza). Inaczej wychodzi źle.

Pozostaw komentarz