Wszystko co chciałbyś wiedzieć o aplikacjach
Zarządzanie portfelem aplikacjami jest jednym z trudniejszych tematów, z którym przyjdzie się zmierzyć architektowi korporacyjnemu. Po pierwsze wynika to z braku jasnej definicji aplikacji. Jeżeli Państwo nie wierzycie w to – proszę zapytać się u siebie w firmie ile jest aplikacji. Aktualizacja: 03.11.2014.
Usłyszane wartości mogą być dramatycznie różne (część osób zaliczy do aplikacji zaliczy tylko systemy centralne, a część – również lokalne “Excele i Accessy” z logiką biznesową, napisaną w Visual Basic for Application.O definicji aplikacji pisałem we wpisie “Czym jest aplikacja i dlaczego jest to ważne”.
Po drugie teoretycznie mówimy o IT (no bo przecież za “aplikacje” odpowiadają ludzie z działów IT), ale w praktyce okazuje się, że przy zarządzaniu portfelem aplikacji powinniśmy zawsze uwzględniać aspekty biznesowe [chociażby krytyczność aplikacji dla biznesu]…
Zainspirowany dyskusją prowadzoną na serwisie LinkedIn w grupie “Association Enterprise Architects” zacząłem tworzyć listę kluczowych pytań, które powinny być zadane w kontekście każdej aplikacji. Ma to zapobiec sytuacji, w której pytając się co organizacja chciałaby wiedzieć o aplikacjach – usłyszałbym w odpowiedzi: “Wszystko” ;). Miałem nadzieję, że zmieszczę się w “oczku” – czyli 21 pytaniach, ale się nie udało :(.
Uwaga 1: na razie pytania na poniższej liście nie są jeszcze uporządkowane.
Uwaga 2: poniższa lista rozpatrywana jest z perspektywy pojedynczej aplikacji; docelowo będzie ona uzupełniona o listę pytań dotyczących portfela aplikacji [dodane: 30.10.2014].
Uwaga 3: poniższa lista pytań jest bardzo rozbudowana. Należy ją potraktować jako punkt referencyjny (odniesienia) i na tej podstawie przygotować dwie sub-listy pytań:
a) z przeznaczeniem do opiekuna/właściciela aplikacji po stronie biznesu;
b) z przeznaczeniem do opiekuna/rozwijającego aplikację po stronie IT.
1. Jaka jest nazwa danej aplikacji?
2. Czy dana aplikacja wchodzi w skład jakiegoś pakietu/platformy – jeżeli tak, to jakiego?
3. Kto jest właścicielem biznesowym aplikacji [wskazanie KONKRETNEJ osoby w organizacji umiejscowionej w ramach komórki biznesowej]?
4. Kto jest odpowiedzialny za rozwój funkcjonalny aplikacji [wskazanie KONKRETNEJ osoby w organizacji umiejscowionej w ramach komórki IT]?
5. Kto jest odpowiedzialny za utrzymanie aplikacji [wskazanie KONKRETNEJ osoby w organizacji umiejscowionej w ramach komórki IT]?
6. Do jakiej kategorii zalicza się dana aplikacja (strategiczna/operacyjna/pomocnicza)?
7. Jakie funkcje biznesowe wspiera dana aplikacja (np. marketing, produkcja, sprzedaż,…)? Ew. jeżeli biznes modelowany jest procesowo – jakie procesy biznesowe dana aplikacja automatyzuje, a jeżeli biznes modelowany jest za pomocą potencjałów (ang. capability) jakie potencjały są wspierane za pomocą danej aplikacji.
8. Czy i w jakim zakresie dana aplikacja jest zgodna ze standardami technicznymi organizacji i ew. (o ile istnieją) z pryncypiami architektonicznymi?
9. Czy i w jakim zakresie dana aplikacja jest zgodna roadmapą biznesową/ technologiczną?
10. Jakie szczególne umiejętności są potrzebne do rozwoju danej aplikacji?
11. Jakie szczególne umiejętności są potrzebne do utrzymania danej aplikacji?
12. Czy organizacja posiada kody źródłowe aplikacji (dodatkowe uszczegółowienie: z możliwością lub bez możliwości ich modyfikacji)?
13. Czy organizacja posiada dokumentację deweloperską aplikacji (dodatkowe uszczegółowienie: gdzie się ona znajduje, czy jest aktualna)?
14. Czy organizacja posiada wsparcie producenta dla danej aplikacji (maintenance)?
15. W jakich technologiach i ich wersjach jest zbudowana dana aplikacja (języki programistyczne, frameworki,….)?
16. Ile lat ma dana aplikacja (kiedy została wdrożona)?
17. Ile użytkowników pracuje na raz w danej aplikacji – średnio?
18. Ile użytkowników pracuje na raz w danej aplikacji – maksymalnie?
19. Ile jest kont użytkowników założonych w danej aplikacji?
20. W jakiej architekturze została opracowana dana aplikacja (jednowarstwowej, n-warstwowej, …)?
21. Jakie interfejsy posiada dana aplikacja i jakie dane ona wymienia przy ich pomocy (jaka jest ich zawartość biznesowa/standard techniczny/wolumetria)? Ew. jakie inne mechanizmy integracji zostały zastosowane w ramach danej aplikacji?
22. Jakie są wymogi infrastrukturalne do działania danej aplikacji (system operacyjny, serwer aplikacyjny, baza danych, sprzęt…)?
23. Do jakich grup danych ma dostęp dana aplikacja (najlepiej opisać to za pomocą macierzy CRUD)?
24. Czy aplikacja przetwarza dane finansowe?
25. Czy aplikacja przetwarza dane osobowe?
26. Czy aplikacja przetwarza dane oznaczone gryfem poufności?
27. Jakie główne usługi aplikacyjne dana aplikacja wystawia/świadczy?
28. Jaki jest średni roczny koszt utrzymania danej aplikacji?
29. Gdzie jest utrzymywana aplikacja (na własnych serwerach, w chmurze prywatnej, w chmurze publicznej)? [dodane: 30.10.2014]
30. Jaki jest sposób wytworzenia danej aplikacji (wewnętrzne zasoby, siłami zewnętrznymi, model mieszany)? [dodane: 30.10.2014]
31. Kto jest wytwórcą/dostawcą danej aplikacji – nazwa firmy (w przypadku wytwarzania jej siłami zewnętrznymi, lub przy korzystaniu z chmury publicznej)? [dodane: 30.10.2014]
32. Jakie ryzyko związane jest z eksploatacją danej aplikacji na poziomie biznesowym (niskie, średnie, wysokie)? [dodane: 30.10.2014]
33. Jakie ryzyko związane jest z eksploatacją danej aplikacji na poziomie technologicznym (niskie, średnie, wysokie)? [dodane: 30.10.2014]
34. Jaki jest wymagany poziom dostępności danej aplikacji? [dodane: 30.10.2014]
35. Jaki jest status aplikacji (Toleruj, Inwestuj, Migruj, Eliminuj).
36. Szacunkowe koszty migracji z aplikacji (oszacowane wartością ekspercką: niskie,średnie, wysokie, lub kwotowo).
Na pewno nie jest to lista kompletna – dlatego zapraszam Państwa do jej komentowania i rozszerzania w formie komentarzy do wpisu.
Podziękowania:
Chciałbym podziękować Panom: Dominikowi Kacprzakowi, Maciejowi Sobierajowi oraz Arkadiuszowi Lefanowiczowi za cenne uwagi zgłoszone na LinkedIn, które pozwoliły uzupełnić wstępną listę o pytania 29-36 i uwag nr 2 i 3, na początku wpisu.
Dodaj komentarz