Oprogramowanie dla aplikacji klasy “enterprise” - na co zwrócić uwagę
23.7.2019 | LCloud
Dobrze zaprojektowane oprogramowanie dla aplikacji klasy enterprise jest kluczem do jej sukcesu. Wszak ma ono na celu, pomóc w rozwiązaniu problemu biznesowego. By takie oprogramowanie spełniało postawione przed nim cele, warto stworzyć je z zachowaniem najlepszych praktyk, czyli skupić się na kilku kluczowych dla niego aspektach. Elementy te przeanalizujemy z punktu widzenia biznesu i procesu projektowania. Zanim jednak zagłębimy się w dalsze rozważania, warto zapoznać się z ogólnymi przyjętymi kryteriami, przy analizie aplikacji.
Powszechnie stosowanym podejściem w odniesieniu do aplikacji enterprise, jest jego specyfikacja w odniesieniu do:
- warstw, z których się składa
- właściwości, które je charakteryzują
Podział warstwowy, wskazuje na praktyczne kwestie związane z działaniem zaprojektowanego rozwiązania., Natomiast podział z wskazaniem właściwości jest istotny dla architekta, w procesie projektowania. Warto nadmienić, że obecnie większość aplikacji jest projektowana wielowarstwowo – najczęściej w oparciu o 3 warstwy. Jednak bywają również aplikacje: 1. – warstwowe (przykładem mogą być aplikacje desktopowe), 2. – warstwowe (przykład architektury klient – serwer) czy innych projektów z większą ich ilością.
Na wspomnianą wcześniej 3.-warstwową aplikację składają się:
- warstwa prezentacyjna;
- warstwa biznesowa;
- warstwa danych.
Warstwa prezentacyjna jest odpowiedzialna za interakcję z użytkownikiem końcowym. Tutaj działają aplikacje klienckie np. aplikacja bankowa znajdująca się na telefonie użytkownika. Warstwa biznesowa odpowiada za realizowanie wszelkiego rodzaju funkcjonalności biznesowych. Ta sama warstwa jest odpowiedzialna również za komunikację z warstwą danych. Na tym poziomie przetwarzane są dane (żądania) klientów i przygotowywane dane do wysłania do warstwy prezentacyjnej. Jest ona swego rodzaju połączeniem pomiędzy dwiema krańcowymi warstwami. Ostatnia warstwa – warstwa danych jest odpowiedzialna za ich przechowywanie. Tutaj umieszczone są bazy danych. Podział ma na celu określenie funkcjonalności projektowanego oprogramowania, z biznesowego punktu widzenia.
Przejdźmy teraz do kwestii związanych z właściwościami takiej architektury. Aspekty ważne z punktu widzenia architekta lub programisty to:
- Bezpieczeństwo – warto jasno określić priorytety i kryteria jakie powinna projektowana architektura spełniać.
- Skalowalność – system/aplikacja powinny być gotowe na przyjęcie zwiększonego ruchu. Tworzenie oprogramowania w sposób przemyślany i zgodny ze sztuką zawsze powinien gwarantować przyzwoitą skalowalność.
- Budowa modułowa – chodzi tutaj o możliwość dostarczania modułów przez różnych dostawców.
- Krótki czas i niskie koszty przyszłej rozbudowy – tworzenie architektury w oparciu o najlepsze praktyki stosowane w różnych frameworkach, nie powinno wymagać od nas przepisywania znacznej części kodu, co daje oszczędność czasu i budżetu,
- Struktura rozproszona – aplikacja powinna być odpowiednio dostosowana do infrastruktury, w której ma działać. Ważnym aspektem jest możliwość uruchomienia jej m.in. z wieloma serwerami, z użyciem load balancera czy gotowości do wykonywania awaryjnych operacji w przypadku niespodziewanych zdarzeń,
- Monitoring i wsparcie – bardzo istotnym jest fakt, iż oprogramowanie po wdrożeniu często wymaga wsparcia, utrzymania, by następnie było dalej rozwijane,
- Integralność – ważnym jest przygotowanie odpowiednich mechanizmów, w ramach budowanej aplikacji, aby umożliwić wymianę danych pomiędzy partnerami lub zewnętrznymi dostawcami danych. Chodzi przede wszystkim o różne serwisy webowe i API,
- Systemy wspierające -warto skupić się na aplikacjach związanych z analizą stanu architektury, raportowaniu o zagrożeniach i stanie bezpieczeństwa itd. Punkt uzależniony jest od wymagań, jakie zostały postawione na początku projektowania aplikacji,
- Dokumentacja – kluczowym jest, aby rozwiązanie posiadało pełną dokumentację: serwisową, techniczną i tą dla użytkownika. Każdy proces w ramach oprogramowania powinien być dobrze opisany, zdefiniowany i (jeśli istnieje taka potrzeba) zwizualizowany. Dzięki temu, w razie zmiany dostawcy wspierającego lub utrzymującego środowisko, proces przejęcia obowiązków będzie o wiele szybszy i bezproblemowy.
