15 lat Adobe Experience Manager - historia

W dniu dzisiejszym minęło 15 lat, odkąd Adobe sfinalizowało zakup Day Software, nabywając w ten sposób produkt, który wszyscy znamy teraz jako "AEM".

Dla każdego z Was, którzy (tak jak ja) pracują z tą platformą od lat, mam nadzieję, że ten post będzie zabawną(lub bolesną) podróżą w dół wspomnień, gdy ponownie przyjrzymy się, dlaczego Adobe kupił Day i co się zmieniło (i nie zmieniło!) w ciągu 15 lat.

Komunikat dnia - przed przejęciem przez Adobe

Day Software to szwajcarska firma z siedzibą w Bazylei, która stworzyła swój przełomowy Communique CMS na niestandardowej platformie opartej na systemie plików, ale później przekształciła się w system oparty na repozytorium treści Java, który znamy dzisiaj.

Pierwsza wersja CQ była zbiorem skryptów CGI dla Netscape Enterprise Server (ręce do góry, jeśli kiedykolwiek go używałeś!) na początku 2000 roku i została przepisana jako aplikacja Java dla CQ2, a następnie serwer HTTP został z niej wydzielony dla CQ3 (geneza CQSE).

Aż do CQ4 zawartość była nadal przechowywana w plikach w lokalnym systemie plików, ale w 2005 r., wraz z wydaniem CQ 4.0, została przełączona ze starszego systemu przechowywania plików "Content Bus" na repozytorium "Content Repository eXtreme" (lub CRX) w wersji 1.0, którego ewolucja nadal zasila AEM - 20 pełnych lat później.

CQ5 był MASYWNĄ AKTUALIZACJĄ & podstawą dzisiejszego AEM

CQ5 stanowił niemal kompletną przeróbkę produktu.

Istnieje wiele funkcji &, które dziś mogą wydawać się powszechne, a które były ogromnymi i rewolucyjnymi elementami platformy CQ5. Uroczy artykuł CMSwire z 2008 roku odnotował "Podczas gdy niektórzy dostawcy CMS unikają Web 2.0, myśląc, że implozja Web 2.0 jest nieuchronna; Day koncentruje się na nim w dużym stopniu". Ile osób w tamtych czasach & mogło nawet zdefiniować Web 2.0? Ale ogromne nowe funkcje wydane w CQ5 zasadniczo sprawiły, że stała się ona zupełnie nową platformą i większość z nas nie wyobraża sobie CQ/AEM bez niej, np:

Nie jest to nowość w tej wersji, ale warto o tym wspomnieć - oddzielne poziomy tworzenia & publikacji CQ sprawiły, że ograniczenia wydajności lub niestabilność po stronie tworzenia nie spowodowały awarii witryny publicznej i odwrotnie. Posiadanie CQ na fundamencie OSGI i Sling oznaczało niezwykle elastyczny silnik treści, zdolny zarówno do bogatych dynamicznych odpowiedzi, jak i renderowania stron, a także możliwość podłączenia ciężkiego podnoszenia w Javie dla wszelkiego rodzaju aplikacji, które wcześniej mogły być uruchamiane na własnym stosie serwerów aplikacji.

Oś czasu wydań CQ & Zmiany

Do momentu przejęcia przez Adobe historia wersji CQ wyglądała następująco:

Przejęcie Day Software przez Adobe & CQ

Adobe ogłosiło w lipcu 2010 roku, że zamierza kupić Day Software, a wraz z nim produkt CQ. W tym momencie Adobe prowadziło już własną stronę internetową na CQ, a biorąc pod uwagę ich nowy nacisk na budowanie linii biznesowej technologii marketingowych, miało to sens. Adobe właśnie przejęło Omniture we wrześniu 2009 roku za 1,8 miliarda dolarów i Scene7 w 2007 roku - było więc jasne, że Adobe zaczyna poważnie myśleć o czymś więcej niż tylko o swojej działalności związanej z oprogramowaniem kreatywnym.

Przejęcie przez Adobe zostało sfinalizowane we wrześniu 2010 roku za 240 milionów dolarów w ramach transakcji gotówkowej, 7 razy taniej niż zapłacono za Omniture - co z perspektywy czasu było niezłą kradzieżą.

Nie jestem pewien, jak ty, ale pamiętam dokładnie, gdzie byłem, gdy ogłoszono umowę. W tym czasie byłem w trakcie uruchamiania CQ 5.2 dla AARP (korzystali z CQ od wersji CQ 4.2). CQ w tamtym czasie było dla mnie w równym stopniu "ogromny ból głowy" i "czy to jest to, dokąd zmierza CMS?" Biorąc pod uwagę, że wciąż próbowaliśmy ustalić, które usługi powinny pozostać w JBoss, a które mogłyby równie dobrze działać w CQ5, teraz, gdy CQ ma tak solidny framework serwera aplikacji Java.

Ale CZY TERAZ ZAKUPIONE PRZEZ ADOBE? To zmieniło dla mnie całą matematykę, czy nadal inwestować czas w naukę CQ5, ponieważ oczywiście z Adobe za nim, to prawdopodobnie MIAŁO NOGI. I tak się stało!

"Branding Day Software" wewnątrz aplikacji został wkrótce zmieniony na "Adobe CQ", choć wszystko inne pozostało takie samo.

Zmiana marki na "Adobe Experience Manager"

Adobe wiedziało, że nie będzie się ono wiecznie nazywać "CQ", więc podjęło kilka nieudanych prób rebrandingu, najpierw nazywając go "Adobe WCM", a następnie "Web Experience Manager", zanim zdecydowano się nazwać go "Adobe Experience Manager". W połowie wersji 5.6 ekran logowania został zmieniony i po zalogowaniu się do CQ wyświetlany był ekran "Adobe Experience Manager".

O autorze

Tad Reeves

Główny architekt w Arbory Digital

Tad jest dwukrotnym mistrzem AEM i prowadzi praktykę AEM w Arbory Digital. Tad rozpoczął pracę z CQ5 w 2010 roku od Day CQ 5.2 i od tego czasu zajmuje się CQ/AEM. Ma bogate doświadczenie w infrastrukturze stron internetowych sięgające 1996 roku i nosił prawie każdy kapelusz w dostarczaniu stron internetowych, od architektury rozwiązań po zarządzanie produktem.

Kiedy Tad nie pracuje (a czasami, kiedy już pracuje), lubi jeździć na rowerze górskim i odkrywać przyrodę ze swoją żoną & 3 dzieci.

Kontakt z Tadem na Linkedin

Podoba ci się to, co usłyszałeś? Masz pytania dotyczące tego, co jest dla Ciebie odpowiednie? Chętnie porozmawiamy! Skontaktuj się z nami

Więcej artykułów na temat AEM, które mogą Ci się spodobać

category
Podcasts, AEM Technical Help, AEM News, Arbory Digital News, Customer Stories, Podcasts
tags
AEM, adobe experience manager, devops
number of rows
1