W naszej pracy nie raz spotykamy się z określeniem „aplikacja klasy enterprise” czy „oprogramowanie klasy enterprise”. Stosują je wszelkiej maści firmy informatyczne, działy IT, różnej wielkości przedsiębiorstwa wtedy kiedy mowa o bardzo wysokiej jakości oprogramowaniu na dużą skalę. No właśnie, tylko czym jest to wysokiej jakości oprogramowanie? W Internecie znajdziesz pewnie informacje o tym jak powinna być zbudowana taka aplikacja, z jakich warstw się powinna składać czy na co powinien zwracać uwagę programista, który ją tworzy. My natomiast w niniejszym artykule potraktujemy ten temat bardziej ogólnie prezentując raczej nasz sposób myślenia o tym zagadnieniu. Będziemy chcieli przy okazji tej terminologii zaprezentować to co jest dzisiaj tak bardzo poszukiwane – czyli wysoka jakość. Genezą do tego artykułu były spotkania z naszymi zaprzyjaźnionymi firmami, które tak jak my, w zapytaniach otrzymywały wysokie wymagania jakościowe dotyczące planowanego projektu. Klient na bezpośrednich spotkaniach podkreślał jak bardzo zależy mu na wysokich standardach kodowania i bezkompromisowej jakości w finalnym produkcie. Firmy spełniając oczekiwania tworzyły dopasowane do potrzeby oferty i kosztorysy. Zazwyczaj w tym momencie potencjalni klienci bledli widząc dość kosmiczne kwoty w wycenach „bardzo prostego” (bo tak zazwyczaj nazywane są wszelkie zlecane aplikacje) projektu. A z czego wynika taka pogoń za tego typu rozwiązaniami? Naszym zdaniem głównie z panującej na rynku bylejakości i niedbalstwa przy różnego rodzaju realizacjach. Tak więc jeśli należysz do grona osób inwestujących lub planujących zainwestować w oprogramowanie wysokiej klasy zobacz co dla firmy typu software house to oznacza i z czym się wiąże. Na początek kilka składowych dobrego oprogramowania:

• Skalowalność Słowo klucz, tworzenie oprogramowania w sposób przemyślany i zgodny ze sztuką prawie zawsze powinien gwarantować dość przyzwoitą skalowalność. Oczywiście, jeśli od samego początku programiści mają to na uwadze. Dobrze i mądrze przygotowane oprogramowanie, korzystające ze wzorców i dobrych praktyk używanych we wszelkiego rodzaju frameworkach powinno poza samą możliwością efektywnej dalszej rozbudowy zagwarantować jeszcze coś: krótki czas i relatywnie niskie koszty przyszłej rozbudowy oprogramowania bez konieczności przepisywania znacznej części gotowego już oprogramowania.
• Bezpieczeństwo Na każdym etapie powstawania oprogramowania przechowujące wrażliwe dane (więcej – jakiekolwiek!) należy zadbać o testy czy przeglądy kodu przez osobnego programistę (najlepiej specjalizowanego w tym kierunku), który z dużo większym prawdopodobieństwem wyłapie powstałe niedoskonałości (mowa o code review). Nacisk na bardzo wysokie standardy bezpieczeństwa, zgodności z publikowanymi rekomendacjami wiąże się z większymi nakładami pracy przez zespół realizujący, większy nakład pracy to jak łatwo się domyślić wydłużenie czasu realizacji i wyższy koszt. Z bezpieczeństwem jest troszkę podobnie jak z optymalizacją wydajności – można ją dopracowywać w nieskończoność. Warto więc jasno zdefiniować krytyczne wymagania.
• Przygotowanie pod działanie w infrastrukturze rozproszonej Każda większa czy mniejsza aplikacja potrzebuje do działania odpowiedniej infrastruktury. Te większe o dużych wymaganiach sprzętowych uruchamia się w bardziej rozbudowanych środowiskach. Aplikacja tym samym aby działać w większym rozproszeniu serwerowym powinna miedzy innymi uwzględniać:
  • Pracę z wieloma serwerami aplikacyjnymi równocześnie z wykorzystaniem np. load balancera
  • Możliwość wydzielenia operacji cyklicznych, obliczeniowych na niezależną infrastrukturę
  • Niekiedy wykorzystuje się środowiska dyskowe NAS, które wymagają również czasem specyficznego przygotowania oprogramowania.
  • Bazy danych są praktycznie zawsze oddzielone z których buduje się skalowalne klastry
  • W razie potrzeb serwery plików statycznych, serwery storage do przechowywania dużej ilości danych
  • Wykorzystując środowiska w chmurze czasem jest konieczność komunikacji z nimi przez API (np. Amazon EC2 API) – dobrze, kiedy oprogramowanie to uwzględnia
  • Replikacje, kopie zapasowe – gotowość do wykonywania awaryjnych operacji w przypadku niespodziewanych zdarzeń

    Model serwera LAMP jest dobry dla developerów do pracy przy mniejszych projektach, większe wdrożenia wymagają dedykowanych i bardzo dobrze dobranych środowisk. Jeśli potrzebujesz czegoś na większą skalę zapomnij o gotowych i pre-konfigurowanych serwerach.

• Utrzymanie i wsparcie W naszej pracy nie spotkaliśmy się chyba jeszcze nigdy, kiedy tworząc średniej lub dużej skali oprogramowanie nie trzeba było go po wdrożeniu wspierać, utrzymywać czy rozwijać. Niestety ale często jest popełniany taki błąd kiedy myśli się o aplikacji tej klasy tylko od momentu rozpoczęcia prac do momentu ich zakończenia (i podpisania protokołu odbioru). Aktualizacje, udoskonalenia, poprawki, monitoring, obsługa techniczna – to tylko niektóre usługi konieczne dla zachowania wysokiej jakości oprogramowania przez dłuższy czas.
• Integracje Jest to przygotowanie odpowiednich mechanizmów w ramach budowanej aplikacji aby umożliwić wymianę danych pomiędzy partnerami lub zewnętrznymi dostawcami danych. Mowa o wszelkiej maści WebSerwisach czy API. Teoretycznie prawie zawsze jakoś da się później dopisać odpowiednie mechanizmy komunikacji. Podkreślam „jakoś”. Dobrze jednak kiedy na etapie powstawania (a nawet projektowania architektury) aplikacji bierze się to pod uwagę, zostawiając sobie na przyszłość otwarte furtki.
• Budowa modułowa Im lepiej przemyślana i lepiej opracowana tym lepiej dla inwestora. Dobrze modułowo budowana aplikacja pozwala na pracę na przykład 2 firm przy 2 osobnych obszarach funkcjonalnych systemu nie przeszkadzając sobie wzajemnie i nie wchodząc sobie w drogę. Obecnie wzorce architektoniczne organizujące strukturę aplikacji (MVC) czy frameworki zasadniczo są pomyślane właśnie dla zapewnienia modułowości. Warto z nich korzystać i stosować je zgodnie ze sztuką a nie wg. własnych fantazji. (tu pewnie programiści czytający ten fragment pokiwają głowami) 
• Stosowanie wzorców projektowych W Polsce naszym zdaniem o tym się głównie mówi, rzadziej stosuje. Na zachodzie to bardziej standard i praktyka. Wzorce projektowe czyli sprawdzone, zdefiniowane i opisane sposoby realizacji fragmentów oprogramowania lub całej architektury oprogramowania. Może to dotyczyć sposobu nazewnictwa plików, architektury przechowywania plików, sposobu realizacji jakiejś często powtarzającej się funkcjonalności (np. dodawania zdjęcia do profilu). Dzięki ich stosowaniu wymiana developerów w trakcie trwania jednego projektu (np. na wypadek choroby) nie stanowi najmniejszego problemu. Dołączający do projektu developer szybciej zdobywa informację o tym gdzie znajdzie jakie elementy aplikacji, szybciej zrozumie jak i dlaczego tak jest całość zbudowana i będzie mógł dalej z tą myślą rozwijać oprogramowanie.
• Systemy wspierające Mowa tu o wykorzystaniu wszelkiego rodzaju aplikacjach uzupełniających główny program. Myślę tu o systemach raportujących błędy, monitorujących prace programu, sprawdzające poprawność wykonywanych operacji itd. Czasem wykorzystuje się gotowe rozwiązania a czasem pisze własne. Wszystko zależy od skomplikowania i wymagań.
• Testy Konieczne a nie zawsze przeprowadzane. Często spotyka się ze smoke-testami a rzadziej z jednostkowymi, funkcjonalnymi, regresyjnymi itd. Przyzwoite testy pochłaniają dość duże budżety, są też czasochłonne natomiast pozwalają bezpiecznie rozwijać oprogramowanie bez obawy, że dodanie czegoś w jednym miejscu spowoduje błędy w drugim. My ze swojej strony polecamy systemy typu continous-integration (np. Atlassian Bamboo) do których możemy przyporządkować zestawy testów (różnego rodzaju). Dzięki temu deployment przebiega spokojniej.
• Dokumentacja Konieczna – i ta dla użytkownika, i ta serwisowa, i ta techniczna. W gruncie rzeczy każdy proces w ramach oprogramowania powinien być dobrze opisany, zdefiniowany i (jeśli potrzeba) zwizualizowany w UML. Dzięki temu w razie zmiany dostawcy utrzymującego i wspierającego Twoje oprogramowanie proces przejęcia obowiązków będzie szybszy i bardziej bezproblemowy. Niestety przygotowanie jej to również dość spory nakład czasowy i kosztowy – im dokładniejsza i lepiej opracowana tym lepiej dla projektu ale gorzej dla budżetu. Wiele firm rezygnuje (świadomie lub nie) z jej przygotowania natomiast warto pamiętać, że dokumentacje najlepiej przygotowywać na etapie powstawania oprogramowania a nie wtedy kiedy będzie ona potrzebna.

I kilka elementów wtórnych:

• Koszt No i dotarliśmy do sedna sprawy. Przygotowanie takiej „idealnej” aplikacji wymaga bardzo dużo pracy i czasu. W efekcie zaprogramowanie prostej funkcjonalności to cały proces angażujący wiele osób I właśnie w tym momencie pojawia się to co nasi i pewnie Wasi klienci zauważają – różne oferty, różnych firm różnią się od siebie cenowo nawet kilkukrotnie. Możliwe? Jak najbardziej! Po prostu dla firm wkładających bardzo dużo pracy w każdy fragment aplikacji  i starających się zrealizować coś „książkowo” koszty produkcji są znacznie, znacznie wyższe aniżeli w firmie, w której jedna czy dwie osoby wykonają tylko suche oprogramowanie bez tych wszystkich aspektów o których pisałem wyżej. Teraz trzeba sobie tylko zadać pytanie – jaki mam budżet i na czym mi tak na prawdę zależy?Jest jeszcze jeden element związany z kosztami – to koszty pracy specjalistów. Różnią się często bardzo mocno a wynikają z doświadczenia, bogatej wiedzy, umiejętności. Pamiętaj, że kupując usługi tańsze – możesz narazić projekt na realizację go przez juniorów lub niedoświadczony w rzeczywistości zespół. To nie jest reguła ale miej na uwadze, komu dokładnie powierzasz projekt – nie realizują go (jeszcze) automaty tylko ludzie a Ci bardziej doświadczeni po prostu popełniają mniej błędów. 
• Czas realizacji Bardzo mocno powiązane z punktem wyżej, wyższy koszt zasadniczo wynika z większego nakładu pracy a tym samym większą ilością roboczogodzin (przyjmując stały poziom kompetencyjny). Każdy element procesu wytwórczego zajmuje czas natomiast można go skrócić eliminując elementy procesu, wymagania projektowe czy modyfikując sposób wytwórczy. Musisz pamiętać, że jeśli coś ma być zrobione dobrze to trzeba na to poświęcić więcej czasu a tym samym zapłacić więcej. Kończąc – kwestie kosztów i czasu pracy najlepiej od lat podsumowuje obrazek:

obrazek zaczerpnięty z: http://www.bjheinley.com/good-fast-cheap-pick-two/