Budujemy portal. Własna aplikacja internetowa vs system CMS

Architektura, Różne takie, top5

Elementem wdrożenia systemu CRM jest bardzo często uruchomienie portalu internetowego. Aplikacja musi być zintegrowana z wdrażanym rozwiązaniem CRM i zazwyczaj korzysta z jego API oraz bazy danych. Oczekiwanie co do stworzenia tego typu aplikacji pojawia się zazwyczaj w wyniku następujących kwestii:

• Dynamics CRM z założenia jest systemem przeznaczonym dla pracowników danej organizacji, a nie dla jej klientów lub parterów.

• Aktualny interfejs CRM jest hmmm… dość nietypowy i różni się mocno od powszechnie przyjętych wzorców tworzenia aplikacji internetowych.

• Każdy użytkownik CRM musi mieć wykupioną stosowną licencję. W przypadku użytkowników portalu internetowego zakup licencji dla każdej logującej się i korzystającej z aplikacji osoby jest zadaniem niewykonalnym nawet dla największych i najbogatszych firm.

Z wyżej wymienionych powodów bardzo często osobny, internetowy portal zintegrowany z naszym ulubionym CRM jest dla wielu firm systemem typu: „musiszmieć”. Na szczęście Microsoft Dynamics posiada świetne API (dla przypomnienia – oparte na protokołach SOAP oraz OData), które umożliwia budowę rozwiązań korzystających z danych w bazie oraz z funkcjonalności omawianego systemu. Problematycznym tematem (któremu zresztą tak naprawdę poświęcony jest tenże wpis) może być natomiast wybór konkretnej technologii, która posłuży nam do budowy pożądanej aplikacji internetowej. Ponieważ wielu developerów CRM (w tym również niżej podpisany) żyje sobie błogo 🙂 w ekosystemie aplikacji i technologii stworzonych przez Microsoft – naszym naturalnym wyborem wydaje się być oczywiście framework ASP.NET MVC. Rzeczywistość bywa jednak brutalna. Klienci często potrafią narzucać dostawcom aplikacji swoje standardy („u nas Panie to tylko Apache i PHP”). W dodatku w chwili, w której przedstawiany jest kosztorys prac i okazuje się, że stworzenie danego rozwiązania zajmie określoną ilość roboczo-dni (*) w głowach wielu zaangażowanych w projekt oraz wycenę systemu osób zaczynają pojawiać się pomysły na zmniejszenie kosztów projektu. Polegają one często na zastąpieniu projektowanej aplikacji internetowej „gotowcem”, którym najczęściej jest jeden z dostępnych na rynku systemów CMS.

W jakich sytuacjach powinniśmy budować portal internetowy od podstaw, a kiedy skorzystać z gotowego rozwiązania? Poniżej znajdziecie listę przypadków w których (moim skromnym zdaniem) powinniśmy zdecydować się na jeden lub drugi scenariusz. Mam nadzieję, że okażą się one przydatne dla kogoś, kto być może stoi przed podobną decyzją w niedalekiej przyszłości. Wytyczne są na tyle ogólne, że możemy je stosować w wielu sytuacjach, zupełnie niezależnie od projektów wdrożeniowych CRM lub innych z którymi niżej podpisany ma na co dzień do czynienia.

Aplikacja tworzona od podstaw:

1. Zawartość witryny oraz funkcjonalność tworzonej aplikacji (logika biznesowa, workflow, itp.) będą niezmienne w czasie życia aplikacji. Nie będzie występowała konieczność dodawania nowych stron (statycznych lub też korzystających ze źródeł danych) przez pracowników organizacji z poza zespołu technicznego.

2. Nasz zespół nie ma doświadczenia we wdrażaniu systemów CMS.

3. Wymagania biznesowe odnośnie wyglądu i funkcjonalności aplikacji są na tyle specyficzne, że łatwiejsze będzie zbudowanie ich w aplikacji tworzonej od podstaw niż kombinowanie, w jaki sposób osiągnąć określony cel w wybranym systemie CMS.

4. Wymagania biznesowe odnośnie aplikacji są na tyle proste (3 formatki „na krzyż”), że nie ma sensu zaprzęgać do tego rozbudowanego systemu CMS. Lepiej zbudować prostą aplikację w ASP.NET, PHP lub innej, preferowanej technologii.

5. Chcemy mieć całkowitą kontrolę nad budowanym rozwiązaniem. Nie możemy pozwolić sobie na uruchamianie kodu nad którym nie mamy pełnej kontroli (np. w przypadku w którym korzystamy z „zamkniętego” rozwiązania) lub nie wiemy, w jaki sposób on działa.

6. Wszelkie poprawki błędów, dostosowania i aktualizacje wykonywane są na określone żądanie. Brak w tym przypadku cyklicznych aktualizacji i poprawek, które są zazwyczaj standardem w przypadku pudełkowych (zarówno darmowych jak i komercyjnych) rozwiązań.

„Pudełkowy” CMS:

1. Zawartość witryny będzie często modyfikowana. Zmiany (zarówno dotyczące zawartości, wyglądu jak i sposobu działania rozwiązania) będą musiały być dokonywane nie tylko przez osoby techniczne, ale również przez pracowników innych działów organizacji.

2. Nasz zespół ma doświadczenia w budowie aplikacji w oparciu o wybraną platformę (ADX Studio, SharePoint, Umbraco, Joomla, itp.), przez co czas zbudowania i wdrożenia danego rozwiązania będzie zdecydowanie krótszy niż tworzenia aplikacji webowej od podstaw.

3. Wymagania odnośnie wyglądu i funkcjonalności witryny są na tyle standardowe, że będziemy w stanie zaimplementować je lub nawet „wyklikać” w systemie klasy CMS.

4. Jako klient nie chcemy „uzależniać” się od 1 dostawcy rozwiązania. W przypadku standardowych rozwiązań przejęcie wiedzy oraz utrzymania danego systemu przez inny zespół może być stosunkowo łatwiejsze niż w przypadku customowego portalu, stworzonego na dodatek w jakiejś mocno egzotycznej technologii. Z drugiej jednak strony – wybór mało popularnego systemu CMS może spowodować odwrotny problem ze znalezieniem specjalistów w porównaniu z popularnymi technologiami w rodzaju ASP.NET lub PHP.

5. Chcemy zbudować system w oparciu o standardowe rozwiązanie, które docelowo może stać się standardem i zostać wykorzystane również w innych obszarach biznesu.

6. Chcemy w przyszłości integrować budowane rozwiązanie z innymi systemami za pomocą gotowego, opisanego API. Większość popularnych systemów CMS takowe API posiada. W przypadku customowej aplikacji zazwyczaj musi być ono zbudowane w ramach projektu, co oczywiście zwiększa czas developmentu.

Finalna decyzja powinna być podyktowana powyższymi warunkami, ale także (a może przede wszystkim) doświadczeniami, które posiadamy w pracy z daną technologią. Doświadczony zespół będzie w stanie zbudować najbardziej niestandardowe rozwiązanie z wykorzystaniem systemu CMS, w którym realizował już wcześniej dziesiątki projektów. I odwrotnie – dla zespołu tworzącego aplikacje w oparciu o (przykładowo) framework ASP.NET MVC zbudowanie prostego portalu zawierającego elementy CMS od podstaw będzie prawdopodobnie łatwiejsze i szybsze niż wykorzystanie gotowca, o którym żaden z członków omawianego zespołu nie ma najmniejszego pojęcia.

(*) Ilość roboczo-dniówek przekłada się w znaczący sposób na całkowity koszt projektu. Niezależnie od kwot o których mówimy – bardzo często początkowa propozycja jest dla działu zakupów nieakceptowalna. Dlaczego? Dla zasady. W końcu w innym przypadku działy zakupów byłyby być może niepotrzebne ;).

Total Views: 1044 ,