Cztery lata temu pisałem o książce Ronalda Rossa “Building Business Solutions”:

Druga to pozycja nowa, całościowo opisująca podejście polegająca na modelowaniu organizacji w analizie biznesowej (zawiera część materiału pierwszej) . Zwraca uwagę na fakt, że nie chodzi w analizie o tworzenie mnóstwa diagramów a o to, by zrozumieć jak organizacja funkcjonuje opisując to, oraz stworzyć model, który pozwoli na prognozowanie zachowania organizacji w odpowiedzi na bodźce, nawet te które jeszcze nie zaistniały. (Źródło: Business Rule Concepts ? czyli jak ?wyłuskać istotę rzeczy? | | Jarosław Żeliński IT-Consulting)

Niedawno wpadł mi w skrzynkę kolejny wpis na blogu R.Rossa:

Zachman?s basic premise is that whenever you engineer anything of complexity, no matter what ? a complex machine, a skyscraper, a microchip, a spacecraft, a product, a business (an enterprise), or some part of a business (a business capability) ? there are two basic aspects that need to be addressed. These two aspects correspond to the columns and rows of the Framework. (Źródło: What the Zachman Architecture Framework Is ? And How It Relates to Business Rules & Business Analysis | Ronald Ross | LinkedIn, Excerpted from: Building Business Solutions: Business Analysis with Business Rules, 2nd edition, by Ronald G. Ross & Gladys S.W. Lam, 2015)

I okazuje się, że zawsze warto wracać do książek :). Od dawna pracuje nad uwolnieniem sponsorów projektów od wymagania by rozumieli technologię i teorie systemów. W literaturze nie raz mozna spotkać pojęcie wymagań biznesowych, pisałem o tym trzy lata temu:

Mianem system określa się zwyczajowo specyfikowane oprogramowanie, jednak problem pojawi się natychmiast, gdy dotkniemy takich pojęć jak wymagania funkcjonalne na oprogramowanie i wymagania biznesowe. To ostatnie niesie pewną niejasność. Bo nie wiem czy chodzi o wymagania wobec (w stosunku do) biznesu (np. poprawa jakości obsługi klienta o 5% w najbliższym badaniu jakości ISO) czy wymagania biznesu wobec (w stosunku do) oprogramowania (np. minimalizacja do zera otrzymanych i zagubionych zapytań ofertowych). (Źródło: Inżynieria wymagań | | Jarosław Żeliński IT-Consulting)

Wymieniona wyżej książka Rossa zawiera rozdział Understanding Business Requirements i takie jego słowa pod tym tytułem:

“Model biznesowy tworzymy by opisać daną działalność, może być on także użyty do stworzenia wymagań biznesowych.” Nieco dalej czytamy:

Bardzo ważne: wymagania biznesowe definiujemy wobec systemu a nie wobec biznesu (firmy). I to faktycznie jest powodem wielu nieporozumień. W tym samym rozdziale Ross powołując się na Siatkę Zachmana przywołuje definicje:

Od dłuższego czasu stosuję w projektach pojęcie Wymagań Biznesowych (opisane w cytowanym wyżej, moim artykule Inżynieria wymagań), i po raz kolejny znowu, skłaniam się do próby wykorzystania siatki Zachmana w tym celu, gdyż jeżeli ten szkielet architektoniczny (Siatka Zachmana to tak zwany szkielet architektoniczny architektury korporacyjnej) faktycznie pozwoli sprawnie zarządzać wymaganiami i ich śladowaniem, to warto z tego skorzystać, na razie porównuje się (nakłada się) ten szkielet z MDA i jak widać jest światełko w tunelu :):

Dla ułatwienia siatka Zachmana w polskiej wersji (kard z pakietu Visual-Paradigm).