Niedawno napisałem, ze Architekt korporacyjny nigdy nie powinien być interesariuszem w projekcie związanym z reorganizacją ((Jak rozmawiać z biznesem nt. Architektury Korporacyjnej | Jarosław Żeliński IT-Consulting). Cytowany w tym artykule prof. A.Sobczak, pisze w odpowiedzi: Ze względu na fakt, że decyzje, których podjęcie rekomenduje architekt korporacyjny (poprzez przygotowanie odpowiednich analiz) odcisną trwałe piętno na organizacji oraz ponieważ organizacja będzie musiała funkcjonować w oparciu o modele zaproponowane przez zespół architektoniczny ? dla mnie architekt korporacyjny powinien w pełni identyfikować się z organizacją i być jej pracownikiem etatowym! Czy to oznacza, że…
Smith, B. C. (1985). Computers, Models, and the Embedding World, The Limits of Correctness. SIGCAS Comput. Soc., 14,15(1,2,3,4), 18?26. doi: 10.1145/379486.379512
Pojawia się próba diagnozy. Pełna tak zwana śladowalność wymagań (nazwana tu hipertracebility) jest podobno kosztowna i trudna do utrzymania. Zaraz potem: niedbałość w definiowaniu wymagań - no to w końcu dokładnie czy nie? Kolej na analityków: zrzucanie odpowiedzialności ? analitycy tworzą dokument wymagań i wypychają go do programistów. Oczywiście jest to problem, co z tym? Analityk powinien ponosić odpowiedzialność za swój produkt do końca projektu. Założenie, że można stworzyć skończony dokument wymagań. Otóż można ale o tym za chwilę. Poza ważnymi elementami zarządzania takim projektem, w tym zarządzaniem zespołem autorzy wskazali jedną z głównych moim zdaniem przyczyn: brak dokumentu HLD (projektu wysokopoziomego).Otóż nie da się czymś tak złożonym jak oprogramowanie (zakładam, że to nie trywialny system), zarządzać na poziomie detalicznych szczegółów.
