Czym jest aplikacja i dlaczego jest to takie ważne?
Przygotowując prezentację nt. portfela IT analizowałem zarządzanie portfelem aplikacji, jako jedną z jego składowych. Zacząłem oczywiście od zdefiniowania czym jest zarządzanie portfelem aplikacji (application portfolio management). Wykorzystałem tutaj propozycję S. Daniela, F. Kai i S. Detlef, którzy uważają, że zarządzanie portfelem aplikacji to realizowany w sposób ciągły i ustrukturalizowany proces ewaluacji aplikacji używanych w organizacji (wykorzystujący kryteria biznesowe oraz technologiczne), będący podstawą do podejmowania decyzji w zakresie działań mających na celu optymalizację, rozwiązywanie zidentyfikowanych problemów oraz dopasowanie aplikacji do celów organizacji. Jednocześnie w dalszej części prezentacji nt. portfela IT, kiedy dotarłem do omówienia portfela infrastruktury zacząłem się zastanawiać jakie systemy IT są aplikacjami (i podlegają pod zarządzanie portfelem aplikacji), a jakie nie są aplikacjami (i należy zaliczyć je do komponentów infrastrukturalnych). Zagadnienie być może na pierwszy rzut oka wydało się trywialne i niewarte poświęcenia mu czasu, ale dyskusja jaka wywiązała się na IMPAKCIE (wśród PRAKTYKÓW – bo obawiałem się również, że ten problem może być odebrany jako akademickie dzielenie skóry na niedźwiedziu) wskazała, że ten temat budzi wiele emocji. Dlaczego? Gdy nie wiadomo o co chodzi, to chodzi o pieniądze i władzę ;). Czyli w części organizacji za aplikacje (biznesowe) odpowiada departament rozwoju, a za systemy nie będące aplikacjami odpowiada departament utrzymania. Co więcej – listy aplikacji życzy sobie audyt wewnętrzny, dział bezpieczeństwa itp (i nie wystarczy podać enumeratywnie wymienionych z nazwy systemów – tylko wskazać kryteria ich umieszczenia na tej liście).
Dyskusja podczas IMPAKTU zaczęła się niewinnie – od zapytania czy MS SharePoint to aplikacja (po dyskusji stwierdziliśmy, że nie – naszym zdaniem jest to komponent infrastrukturalny)? Czy MS Excel to aplikacja (tutaj nie udało się osiągnąć konsensusu – ustaliliśmy, że należy udzielić odpowiedzi konsultanckiej – “to zależy” – w części organizacji Excel będzie aplikacją – bo jest wykorzystywany “z półki” i już, dla znacznej części organizacji nie będzie aplikacją, bo stanowi on PLATFORMĘ, na której buduje się aplikacje). Mniejsze emocje dotyczyły systemów operacyjnych, serwerów baz danych, serwerów aplikacyjnych. Tutaj było prosto – to nie są aplikacje. Niestety później było już pod górę – czy system SAP to aplikacja biznesowa? A czy narzędzie klasy BI to aplikacja biznesowa? Tutaj także był brak konsensusu.
Dlatego wykonaliśmy krok do tyłu i zdefiniowaliśmy “aplikację”. Oczywiście istnieje wiele definicji aplikacji (np. aplikacje są zdefiniowane w TOGAFie, ArchiMate). Ja jednak, na potrzeby zarządzania portfelem aplikacji zaproponowałem następującą jej definicję (powstała ona jako kompilacja iluś różnych definicji): wykonywalny komponent oprogramowania lub ściśle związany ze sobą zbiór komponentów, stosowanych razem, który/które zapewniają niektóre lub wszystkie działania związane z tworzeniem, aktualizacją, zarządzaniem, obliczeniami lub wyświetlaniem informacji związanych z realizacją konkretnego celu biznesowego. Czyli jeżeli system nie przetwarza informacji powiązanych z realizacją KONKRETNEGO celu biznesowego NIE JEST aplikacją biznesową.
Ta definicja ma wadę, bo wymaga określenia czym jest “komponent oprogramowania”. Według mnie jest to zestaw wykonywalnych instrukcji, zawarty w jednym, wdrażalnym kontenerze, w taki sposób, że zestaw ten nie może być zdekomponowany na podkomponenty. Co więcej przyjęto założenie, że każdy komponent oprogramowania może być składnikiem dokładnie jednej aplikacji.
Oczywiście takie ujęcie aplikacji nie wyczerpuje tematu. Będę wdzięczny za Państwa opinie.
Komentarze do wpisu
Faktycznie pojęcie "aplikacja" trudno zdefiniować. W zasadzie pozostaje chyba stwierdzenie, że "aplikacja to oprogramowanie mające dla kogoś jakąś funkcjonalność". Definicja "...konkretnego celu biznesowego", bo mój CASE pomaga mi realizować cele biznesowe, serwer baz danych także pewnym ludziom w firmach pozwala "realizować celem biznesowe". Niejawnie (intuicyjne znacznie słowa "aplikacja" w tworzonych powszechnie zapytaniach i ofertach "aplikacja" to "przydatne do nazwanego celu oprogramowanie".
Definicja, którą stosuję na użytek budowy application portfolio management capablity w swojej firmie: aplikacja, to grupa funkcjonalności oprogramowania wspierająca BEZPOŚREDNIO procesy biznesowe firmy. Aplikacja jest widoczna przez biznes i przetwarza konkretne dane biznesowa (które nie są częścią aplikacji).
W ArchiMate aplikacją będzie więc ten application component, który realizuje application service używany BEZPOŚREDNIO przez proces lub funkcję biznesową.
Aplikacjami nie są:
- "goła" poczta korporacyjna, systemy baz danych, komunikatory, system wydruku sieciowego, "goły" excell, word czy powerpoint
- moduły aplikacji nieoddzielalne od nich części, choć identyfikowalne w celu grupowania funkcjonalności w ramach jednej aplikacji
- platformy integracyjne, systemy operacyjne.
Ale aplikacjami będą:
- poczta korporacyjna użyta (zaaplikowana) do zintegrowania dwóch jednostek biznesowych lub firm, wspierająca konkretny proces biznesowy
- excell zaaplikowany do przetwarzania ofert w celu wybrania najlepszej oferty dla klienta.
czym jest tu więc MS Access i MS Excell? Powyższe prowadzi do tego, ze ten sam "program" raz jest aplikacją a raz nią nie jest :(... w efekcie dwa diagramy z dwóch różnych perspektyw będą zawierały niespójności: ten sam byt raz jest a raz nie jest tym czymś.... chyba, że coś pominąłem...
Moja koncepcja dotycząca narzędzi takich jak excel zakłada, że samo narzędzie MS Excel jest tożsame z serwerem aplikacyjnym. Natomiast już konkretny arkusz, z makrami, regułami, formułami jest aplikacją. Bo to nie MS Excel wspiera biznes, a konkretny arkusz na nim stworzony. Tak samo jak to nie Java jest aplikacją, a dopiero w Javie napisany kod może stać się aplikację
Idąc tym tropem, każdy pakiet oprogramowania to środowisko i coś użytecznego: system do księgowania, bez wprowadzonego planu kont także jest tylko platformą... a co do Javy to czym jest np. Eclipse?
To zależy od firmy. W przypadku firmy developerskiej eclipse jest aplikacją na której wytwarzają swoje produkty. W innych firmach eclipse nie wspiera procesów biznesowych, nie jest więc aplikacją. Ale już rozpatrują zdekomponowane przedsiębiorstwo i analizując np. tylko dział IT to w Architekturze Korporacyjnej tego działu eclipse już jest aplikacją.
Byłabym wdzięczna za pociągnięcie tamatu o Eclipse. O konkretnie jego pluginach, takich jak w projekcie Camunda.
Bardzo bym była zainteresowana dokonanym przez Ciebie podziałem. Co nieco wykorzystałabym do zidentyfikowania kompenentów wspierających procesy biznesowe u nas. Podobnie jak Ty zauważyłam, że jest potrzeba odświeżenia tego tematu. Obsługiwanie komponentów biznesowych na "utrzymaniu" (i to przez Service Desk)zamiast na "rozwojówce" moze przyprawić chociażby developera o pewien rodzaj schizofrenii.
Ja te "podchwytliwe" pytania zadaje, bo w swoich projektach widzę "to samo": "źle" znaczenie "pojęcia" zaczyna żyć własnym życiem w takt zmian miejsca (kontekstu) jego użycia. Dlatego, że od jakiegoś czasu robiąc "analizę pojęciową" testuje słownik na okoliczność tego jak reagują pojęcia (ich znaczenia) na zmianą kontekstu. Słownik pojęć to u mnie fundament każdej analizy i dlatego stosuje zasadę, stałości znaczeń pojęć.
Problem pojawi się, gdy zrobimy inwentaryzację oprogramowania i nagle to samo pudełko jest czymś innym w IT a czymś innym w księgowości.
... dlatego w zasadzie moim zdaniem spokojnie można uznać, że aplikacja to oprogramowanie użytkowe (bo faktycznie np. system operacyjny sam z siebie do niczego nie służy). Polecam także ten serwis i tę stronę jako głos w dyskusji http://www.brcommunity.com/b531.php
Jeżeli zdarza się sytuacja, że to samo pudełko jest czymś innym w IT a czymś innym w księgowości to znaczy, że model referencyjny nie został zdefiniowany. W przypadku mówienia o architekturze korporacyjnej (nawet o architekturze korporacyjnej IT) nie ma możliwości, żeby IT coś sobie zdefiniowało bez weryfikacji tego w szerszym kontekście. Model pojęć musi być szeroko przyjęty, a nie tylko przez architekta.
Zgadzam się z przedmówcą. Przeprowadziłem projekty racjonalizacji portfela aplikacji w dwóch różnych bankach w oparciu o metodykę Application Portfolio Management opisaną przez Gartnera. Arkusze Excel używane przez biznes w procesach biznesowych traktowaliśmy jako aplikacje, choć cały pakiet Office, systemy operacyjne, poczta itp. była traktowana jako infrastruktura niepodlegająca ocenie.
W języku polskim istnieje słowo "zaaplikować", które się ładne kojarzy ze słowem "aplikacja". Zaaplikować znaczy "zastosować coś wobec kogoś", zatem jeśli ktoś stosuje coś (“komponent oprogramowania”) w celu wykonania swojej pracy to można mieć już duże podejrzenia, że ten komponent nabiera cech aplikacji. Z mojego doświadczenia wynika, że często taki komponent NIE powinien być aplikacją ale sprytny biznes tak go wykorzystuje.
Przykład z życia: pracownicy robili listę klientów / transakcji i przesyłali ją do następnej jednostki organizacyjnej emailem. W tym momencie komponent infrastruktury stawał się aplikacją. Czy to dobrze. NIE! To bardzo źle. Szczególnie, że IT o tym nie wiedziało.
Musimy pamiętać (o czym sam Gartner pisze), że definicja aplikacji nie jest tutaj najważniejsza. Najważniejsze są działania racjonalizatorskie mające na celu optymalizację portfela podjęte na bazie wniosków i spostrzeżeń płynących z analizy APM.
Skupianie się na stworzeniu idealnych definicji, to źle spożytkowane zasoby. Biznes z tego nie będzie miał wartości dodanej. Trzeba stworzyć fundament merytoryczny w postaci "wystarczająco dobrej" taksonomii, zakasać rękawy i rozwiązywać prawdziwe problemy ;-)
Od końca: taksonomia to nic innego jak "właściwe definicje", ich brak (lub złe) to niejednoznaczność na co właśnie się nadzialiśmy. Jednoznaczność to kluczowa wartość dodana każdej dokumentacji.
Jeżeli okazuje się że pojęcie "aplikacja" zaczyna zależeć od otoczenia i kontekstu to tylko sygnał, że definicja jest zła. Zaaplikować to czasownik aplikacja w formie przyszłej dokonanej. My tu mówimy o rzeczowniku (przedmiocie) i nie mieszał bym tego, to po protu jakieś oprogramowanie i jak widać inwencja użytkowników jest duża (dlatego napisałem aplikacja=oprogramowanie).
Jeżeli ludzie użyli oprogramowanie (tu mail) niezgodnie z planem (zamysłem) IT to tylko sygnał, że reguły zostały źle ustalone, system został źle zaprojektowany (sam fakt, że IT nie wiedziało o tym źle świadczy i tym IT - stworzono proces i zabezpieczono sobie możliwości jego monitorowania, metody nakazowo rozdzielcze nie działają w zarządzaniu).
Idealne definicje to kluczowy element idealnej analizy, a "wystarczająco dobrze" oznacza tylko to, że świadomie tego ideału nie chcemy osiągać (bo np. było by to zbyt kosztowne) ale wiemy ile nam do niego brakuje.
Z uwagi na ograniczone miejsce tylko podam link: tu opisałem dlaczego:
http://it-consulting.pl/autoinstalator/wordpress/2013/02/21/utopia-czyl…
Kontekst jest kluczową sprawą zawsze i wszędzie, no może poza matematyką samą w sobie.
Kontekstem jest na przykład obecna i przyszła strategia IT oraz strategia całej organizacji. W zależności od strategii obrane kierunki racjonalizacji portfela będą różne.
Nie zgadzam aby dążenie do idealnej definicji aplikacji było uzasadnione w praktyce, dlatego napisałem "wystarczająco dobre". Dla mnie to tylko drążenie kieszeni klienta. Zanim Ty zdefiniujesz idealną definicję aplikacji, uzyskasz podpisy wszystkich władnych w organizacji pod nią i zinwentaryzujesz aplikacje, ja już będę wstanie dostarczyć pierwsze wyniki analizy dla CIO.
Gdy w organizacji istnieje kilkaset aplikacji (według takiej czy innej definicji, ważne aby była ona przyjęta na początku analizy) to te najważniejsze aplikacje i tak zostaną poddane badaniu. Nie ma sensu badać aplikacji której używa pięć osób w całej firmie a jej TCO roczne to 1000 złoty. Największe, najważniejsze i najkosztowniejsze aplikacje, systemy, komponenty czy po prostu oprogramowanie, ja Ty to nazywasz, zostaną przebadane, wnioski wyciągnięte i rekomendacje stworzone, tak aby można było rozpocząć działania mające na celu poprawę. Sama analiza APM nic nie poprawia, ogólnie rzecz biorąc dostarcza nam wiedzy na temat tego co jest dobre a co złe w portfelu aplikacji. Dlatego kluczowe są działania racjonalizatorskie następujące po analizie APM, które to przynoszą realną wartość organizacji.
Application Portfolio Management to narzędzie strategiczne w rękąch CIO, które pomaga mu podejmować decyzje co do racjonalizacji infrastruktury aplikacyjnej (rzadko kiedy to jest prawdziwa optymalizacja, ze względu na różne ograniczenia). Musisz zrozumieć, że pracujemy tutaj na innym poziomie abstrakcji niż przy "zwykłym" projekcie analizy biznesowej aplikacji. To jest poziom zarządczy IT.
Jeżeli komuś opracowanie modelu pojęciowego miało by zająć pół roku, to lepiej faktycznie by zajął się czymś innym, zaś dopuszczenie do procedury zbierania podpisów w ilości większej niż jeden pod jakimkolwiek dokumentem raczej świadczy o kompletnym braku panowania nad projektem (taki system d...po-chronów, tu proszę o wybaczenie, zabija projekty).
Osobiście stoję na stanowisku, że Architektura Korporacyjna (AK) to, zgodnie z jej definicją, jeden spójny model pojęciowy od poziomu motywacji biznesowej do poziomu "serwerów" włącznie. Oznacza to, że system pojęciowy dla wszystkich warstw musi stanowić jedną przestrzeń nazw (konceptów). Czyli pojęcie "aplikacja" musi zachowywać swoje znaczenia w każdej z warstw AK. W przeciwnym wypadku w jednym modelu to samo pojęcie będzie oznaczało co innego zależnie od tego, która stronę dokumentacji otworzymy.
To, że jakaś organizacja ma setki aplikacji nie powinno wpływać na definicję tego czym jest aplikacja, ich rozróżnienie to problem dodatkowych atrybutów a nie tworzeniu sztucznych nazw na "inne aplikacje", podobnie jak w systemach zarządzania dokumentami, nie budujemy kolejnych znaczeń słowa "dokument" tylko dlatego, że mam tysiące dokumentów w repozytorium, a budujemy system ich rodzajowego oznaczania-klasyfikacji (Rzeczowy Wykaz Akt).
Co do zasady poziom abstrakcji nie zmienia definicji pojęć... To co piszę to dość restrykcyjne podejście, moja praktyka pokazuje jednak, że jednym z głównych problemów w projektach tego typu jest niejednoznaczność i łamanie zasad budowania przestrzeni nazw (a każda notacja jest taką przestrzenią). Zapewniam, że opracowanie poprawnego modelu zawsze przynosi większe korzyści niż droga na skróty.... Po drugie w zasadzie pojęcie aplikacja ma swoja definicję np. ArchiMate czy UML/diagram komponentów, więc po co tworzyć nową? Co ciekawe aplikacja to po protu jakiś agregat usług (oprogramowania), więc mają listę usług (ta ma raczej kluczowe znaczenie) pojęcie aplikacja jest i tak dość płynne. Każdy kto przechodził np. migracje z jednego system ERP na kilka integrowanych komponentów wie, że (w pewnym uproszczeniu) lista usług się nie zmieni a lista (ilość aplikacja) jak najbardziej.
Właśnie skończyłam poranny fragment swojej pracy przy pomocy WinScp i przy jego zamykaniu pojawiło się "Czy zamknąć APLIKACJĘ ?", choć ogólnie wiadomo, że to typowa narzędziówka. Przyszło mi więc na myśl, by rzeczywiście pojęcie aplikacja rozumiec na tyle szeroko, by IT też się tą przestrzenią nazw posługiwało (jak radzi Jarek), ale aplikacje jednak dzielić na utrzymaniowe (co najwyzej upgrade-owane) i rozwojowo/utrzymaniowe (rozwój pod kątem implementowania nowych procesów, czy tez reguł biznesowych). Co więcej w rozwijanej przez nas architekturze SOA wydaje się, że na znaczeniu zyskują nie tyle same interfejsy wystawione do uzytkownika, co różnego rodzaju "enginy" chodzęce w tle. Służą one nie tylko do wymiany danych pomiędzy poszczególnymi klockami realizujacymi funkcje danej domeny, co także coraz częściej są pewnego rodzaju przejściówkami dla procesów, których reguły biznesowe leżą na styku dwóch różnych pól i sa BARDZO niestandardowe.
Ad. "KAŻDY kto przechodził np. migracje z jednego system ERP na kilka integrowanych komponentów wie, że (w pewnym uproszczeniu) lista usług się nie zmieni a lista (ilość aplikacja) jak najbardziej."
Skoro KAŻDY, to również ja :-) A skoro ja, to pozwolę sobie się nie zgodzić :-)
Dla mnie aplikacją jest nie instancja software'u ale zbiór funkcjonalności przez ten software realizowany, bo to on (zbiór) ma BEZPOŚREDNIĄ relację z warstwą biznesową. Aplikacja, to GRUPA funkcjonalności oprogramowania, wspierająca BEZPOŚREDNIO procesy biznesowe firmy.
Wracając do ww. przypadku migracji ERP'a - systemy zintegrowane, takie jak ERP czy CRM - to wg mnie nie są pojedyncze aplikacje ale całe ich zbiory aplikacji. Więc w ww. przypadku migracji ERP'a - jeśli podczas migracji zbiór oraz grupowanie funkcjonalności się nie zmieni, to lista aplikacji się również się nie zmieni :-)
co tylko potwierdza moja tezę "aplikacja=oprogramowanie", nie da się oderwać tych pojęć od siebie, co najwyżej zawieranie się "każda aplikacja to oprogramowanie", jeżeli zdefiniujemy, że aplikacja to jedna lub wiele usług świadczonych bezpośrednio jej użytkownikowi to mamy załatwione i sterowniki dysku (oprogramowanie ale nie aplikacja) o system ERP (oprogramowanie i aplikacja).
cytat: "systemy zintegrowane, takie jak ERP czy CRM – to wg mnie nie są pojedyncze aplikacje ale całe ich zbiory aplikacji." - niestety ich dostawcy twierdzą co innego :)
Jeszcze takie spostrzeżenie, wg mnie warte pamiętania:
- sam artykuł oraz dyskusja, która się tutaj toczy na temat definicji aplikacji, toczy się dzisiaj: mamy 2013 rok.
- podawane przykłady są z dzisiaj: mamy 2013 rok, istnieją ERP'y, CRM'y, excelle, outlook'i, ...
Ale:
- przed erą komputerów, systemy przetwarzania danych, to były przecież funkcje biznesowe a nie systemy/aplikacje,
- dopiero od 1960 roku ręczne przetwarzanie danych (funkcje biznesowe) jest stopniowo automatyzowane za pomocą systemów informatycznych / aplikacji.
Czyli:
- dzisiejsze aplikacje, to wczorajsze funkcje biznesowe
- dzisiejsze platformy, to wczorajsze aplikacje generyczne
- dzisiejsze struktury danych, to wczorajsze zahardkodowane procedury.
Więc:
- może samą definicję aplikacji dało by się wyprowadzić na raz i zawsze,
- ale z biegiem czasu jej znaczenie na pewno będzie się zmieniać :-)
- dzisiejsze aplikacje, to wczorajsze funkcje biznesowe
- dzisiejsze platformy, to wczorajsze aplikacje generyczne
- dzisiejsze struktury danych, to wczorajsze zahardkodowane procedury.
___
JŻ: nie spotkałem się z takimi definicjami... od początku program komputerowy był sekwencją poleceń i jest nadal. Platforma czyli co? płyta główna, chassis czy system operacyjny? Struktury danych to kod na dysku czy ich model? Mamy tu - przytoczone trzy zdania jako przykłady - klasyczną niejednoznaczność spowodowaną brakiem ścisłej definicji użytych pojęć ...
Na pewnie wykazaliśmy, że różnimy się podejściem. Nie widzę potrzeby by tu oceniać te różnicę ;) (kończąc dyskusję)
Kończycie dyskusję, a ja bardzo bym chciała wiedzieć, jak zinterpretowalibyście zakres moich zadań jako zatrudnionej na stanowisku specjalisty ds. Rozwoju Systemów i Aplikacji. Dopiero niniejsza dyskusja uświadomiła mi, że może ta nazwa nie jest najszcęśliwsza.
A jeżeli są komponenty reużywalne?
Pytanie brzmi: czy schodzimy w modelu do poziomu architektury wewnętrznej aplikacji czy nie, po drugie reużywalny komponent na poziomie całego systemu (aplikacja) to po protu komponent świadczący usługi innym komponentom (o ile nie mamy tu na myśli powielania jakiegoś kodu "dziedzinowego" w kilku aplikacjach, co raczej było by błędem.
Dodaj komentarz