Ali CM potrebuje še en CM

Pri razvoju programske opreme se občasno zgodi nekaj zanimivega.

Dolgo časa razvijaš sistem, rešuješ eno težavo za drugo, dokler nazadnje ne prideš do ovire in odkriješ, da je nekdo drug že pred leti prišel do skoraj povsem enakega problema. In nato okoli njegove rešitve zgradil podjetje.

Pri razvoju CM Plus in CM PRO smo pred kratkim prišli prav do takšne točke.

Od koledarja do sistema CM se ni začel kot poslovni načrt za nov hotelski PMS. Njegovi začetki so bili veliko preprostejši.

Potrebovali smo boljši način za upravljanje lastne nastanitve. Najprej je bil pomemben koledar. Nato rezervacije. Potem cene, ponudbe, povpraševanja, zasedenost, komunikacija z gosti ter pravila prihodov in odhodov.

Ko pa smo sistem začeli dejansko uporabljati, so se pojavila nova vprašanja.

• Kaj se zgodi z rezervacijo, ki še ni dokončno potrjena?
• Kdaj naj bo obdobje začasno zadržano in kdaj trajno zasedeno?
• Kakšna je razlika med plačano rezervacijo in zasedenim terminom?
• Kaj se zgodi, ko ponudba ali rezervacija poteče?
• In morda najpomembneje:
• Kateri sistem je dejanski source of truth za razpoložljivost?

Počasi je tisto, kar se je začelo kot koledar, postalo sistem.

Danes CM Plus že opravlja resnično delo pri upravljanju nastanitve, CM PRO pa nastaja kot bistveno širša evolucija prvotnega koncepta.

Okoli jedra CM so zrasli tudi samostojni moduli. Guestbook skrbi za podatke o gostih ter zakonsko zahtevano prijavo in poročanje gostov.

Financing povezuje rezervacije s finančnimi evidencami, davčnim poročanjem in postopoma tudi z državnimi informacijskimi sistemi.

Za temi moduli pa stoji pomembno arhitekturno načelo. Niso bili zasnovani kot deli ene ogromne monolitne aplikacije. Med seboj komunicirajo prek jasno določenih mostov in adapterjev.

Vsak modul lahko svoje delo opravlja samostojno, skupaj pa lahko tvorijo precej večji sistem.

Ta arhitekturna odločitev je postala še posebej pomembna, ko smo prišli do naslednjega velikega problema.

Rezervacija prispe z Booking.com Channel Manager brez neposredne povezave z rezervacijskimi platformami lahko še vedno naredi veliko.

Ne more pa opravljati ene od funkcij, ki na koncu upravičuje ime Channel Manager.

Ne more neposredno komunicirati s kanali. Ko gost naredi rezervacijo na Booking.com, bi moral pravi Channel Manager zanjo vedeti.

Ko je ta rezervacija odpovedana, bi moral vedeti tudi to. In ko se v CM spremenijo razpoložljivost, cene ali omejitve, bi se morale te spremembe poslati nazaj na rezervacijski kanal. Po možnosti skoraj takoj.

V idealnem svetu bi bila arhitektura čudovito preprosta:

CM → Booking.com API

Žal svet velikih spletnih rezervacijskih platform ne deluje povsem tako.

Booking.com svojih Connectivity API-jev ne ponuja preprosto vsaki aplikaciji, ki zna poslati tehnično pravilen HTTP zahtevek. Ponudniki povezljivosti morajo skozi partnerske in tehnične certifikacijske postopke. V času pisanja tega članka Booking.com Connectivity Portal tudi navaja, da so prijave novih ponudnikov povezljivosti začasno ustavljene.

Za majhen programski projekt to ustvari zanimiv paradoks. Programska oprema lahko postane tehnično sposobna komunicirati z Booking.com.

Pa vendar še vedno nima neposredne poti do API-ja. Ali torej Channel Manager potrebuje še en Channel Manager? Na prvi pogled se ideja sliši absurdno.

Če razvijamo lasten Channel Manager, zakaj bi ga povezovali z drugim Channel Managerjem?

Odgovor je: ne bi ga.

Potrebujemo samo tisti del infrastrukture, ki ga je nekdo drug že zgradil in certificiral.

Tu smo odkrili Channex. Channex nam ni zanimiv predvsem kot drug PMS, ki bi lahko nadomestil CM.

Zanimiv je zato, ker ponuja nekaj drugega: povezovalno infrastrukturo med PMS platformami in rezervacijskimi kanali. Njegov White Label API omogoča, da neodvisen PMS ali Channel Manager uporabi Channex kot povezovalni sloj do Booking.com, Airbnb, Expedia in drugih distribucijskih kanalov.

Arhitektura torej v resnici ne bi bila:

• CM → drug Channel Manager → Booking.com

Bolj bi bila podobna temu:

• CM → Connectivity Adapter → Channex → Booking.com

Ta razlika je pomembna.

• CM lahko ostane avtoriteta nad lastnimi podatki.
• CM pozna rezervacije.
• CM pozna cene.
• CM pozna razpoložljivost.
• CM pozna omejitve in poslovna pravila.

Channex preprosto zagotavlja infrastrukturo, prek katere te spremembe dosežejo distribucijske kanale — in prek katere se spremembe iz teh kanalov vrnejo nazaj v CM.

In potem je zgodba postala nekoliko zabavna Ko smo raziskovali Channex, smo pogledali tudi zgodbo podjetja.

Njegov ustanovitelj ni začel z idejo: "Zgradimo podjetje za API infrastrukturo v hospitality industriji." Prišel je iz hospitality sveta.

Zgradil je lasten PMS.

Nato pa ugotovil, da je ena največjih težav povezati ta sistem s Channel Managerji in rezervacijskimi platformami.

Problem, na katerega je naletel pri gradnji lastnega sistema, je sčasoma prispeval k nastanku Channexa. Takrat sem se moral nasmehniti.

Ker je bila pot CM presenetljivo podobna.

Nismo začeli z načrtom, da bomo zgradili veliko programsko platformo. Začeli smo z lastno nastanitvijo. Zgradili smo lasten sistem.

Nato smo ga uporabljali.

Resnična uporaba je pokazala naslednji problem.

Rešili smo ga.

Potem se je pojavil nov.

Rešili smo tudi tega.

In nazadnje smo prišli do problema povezljivosti.

Nekdo drug je do izjemno podobne ovire prišel že leta pred nami. Razlika je v tem, da je on iz te ovire zgradil podjetje. Zakaj adapter in ne odvisnost?

Nič od tega ne pomeni, da bi moral CM postati odvisen od Channexa. Ravno nasprotno.

Če se je med razvojem CM vedno znova potrjevala ena lekcija, je to vrednost jasnih meja med sistemi.

Integracija s Channexom bi zato morala biti izvedena kot adapter.

Danes bi lahko imeli:

ChannexAdapter Jutri:

BookingNativeAdapter

Pozneje:

ExpediaNativeAdapter

ali adapter za kakšnega drugega ponudnika povezljivosti.

Jedru CM ni treba vedeti, kako Booking.com pričakuje, da bo prejel podatke.

Razumeti mora le operacije, kot so:

• pošlji razpoložljivost,
• posodobi ceno,
• prejmi novo rezervacijo,
• obdelaj odpoved,
• preveri stanje sinhronizacije.

Kako ta zahteva fizično pride do Booking.com, je naloga povezovalnega sloja.

To je isto načelo, ki ga že uporabljamo drugje. Guestbooku ni treba razumeti notranje arhitekture Financinga.

Financingu ni treba poznati vseh notranjih podrobnosti CM.

Sistemi se dogovorijo, kaj si izmenjujejo.

Most ali adapter poskrbi za prevod.

Zanimiva ekonomika majhnega Channel Managerja S tem se pojavi še eno zanimivo vprašanje.

Channex trenutno ponuja White Label model, sestavljen iz osnovne platformne pristojbine in razmeroma majhnega dodatnega stroška za povezano nastanitveno kapaciteto.

Za eno samo majhno nastanitev skupna povezovalna infrastruktura očitno nima veliko ekonomskega smisla.

Toda CM Plus in CM PRO nista zasnovana na predpostavki, da bi moral vsak uporabnik posebej zgraditi svojo Booking.com integracijo. Predstavljajmo si drugačen model.

En ponudnik nastanitve uporablja CM Plus z dvema enotama.

• Drugi ponudnik ima svojo neodvisno CM namestitev s petimi enotami.
• Tretji ima eno.
• Četrti deset.

Vsaka CM namestitev je neodvisna in vsak ponudnik nastanitve ostaja gospodar svojih podatkov.

Skupna je samo povezovalna infrastruktura. Takrat osnovni strošek povezljivosti ni več strošek enega apartmaja.

Postane infrastruktura, ki si jo deli celoten ekosistem. In z rastjo števila povezanih uporabnikov postaja strošek infrastrukture na posameznega ponudnika vedno manjši.

To je precej drugače od tradicionalnega modela: "Vsak mesec plačuj za velik PMS paket."

CM lahko ostane majhen, lokalno nameščen in osredotočen na neodvisne ponudnike nastanitev. Deliti je treba samo tisto infrastrukturo, ki ima od skupne uporabe resnično korist.

Kaj pa neposredna povezava z Booking.com? Ta ideja ni izginila. Ravno nasprotno.

Še vedno ostaja zanimiv dolgoročni cilj. Če Booking.com ponovno odpre prijave za nove ponudnike povezljivosti in CM doseže potrebno stopnjo zrelosti, lahko raziščemo možnost, da tudi sami postanemo neposredno certificiran ponudnik.

In arhitekture zaradi tega ne bi bilo treba na novo zasnovati. Preprosto bi dodali nov adapter. Namesto:

CM → ChannexAdapter → Booking.com bi lahko določen kanal uporabljal: CM → BookingNativeAdapter → Booking.com medtem ko bi Channex še naprej zagotavljal povezljivost z drugimi kanali. To je bistvo dobre abstrakcije. Današnja praktična rešitev ne sme nikoli preprečiti jutrišnje boljše rešitve.

Potrkali smo na vrata Zato smo Channexu poslali nekoliko nenavadno sporočilo.

Nismo jih preprosto vprašali:

"Koliko stane vaš API?"

• Opisali smo CM.
• Pojasnili smo, zakaj obstaja.
• Opisali smo njegovo arhitekturo.
• Pojasnili smo, kako CM, Guestbook in Financing ostajajo samostojni, vendar med seboj komunicirajo prek mostov.

Opisali smo idejo distribuiranih, self-hosted CM namestitev, ki jih upravljajo mali ponudniki nastanitev.

In kar je pomembno, pojasnili smo, da ne želimo, da Channex postane središče našega sistema.

Želimo, da zavzame zelo natančno mesto v arhitekturi: med CM in rezervacijskimi kanali.

Vprašali smo tudi, kako se njihov cenovni model uporablja pri malih ponudnikih nastanitev z več apartmaji ali sobami ter ali lahko ena partnerska integracija služi številnim neodvisnim CM namestitvam.

V trenutku pisanja tega članka njihovega odgovora še nismo prejeli.

In pravzaprav je to dober trenutek za objavo. Ker ta zgodba ne potrebuje umetno izdelanega zaključka. Dogaja se zdaj.

Programska oprema, ki raste iz resnične uporabe CM se je razvijal nekoliko drugače kot številni programski projekti. Najprej nekaj potrebujemo.

Potem to zgradimo.

Nato to uporabljamo.

In šele resnična uporaba pokaže, ali je bila prvotna ideja zares dobra.

Guestbook je nastal iz dela z resničnimi gosti in resničnimi obveznostmi poročanja.

Financing je nastal iz resničnih računov, davčnih evidenc in finančnega poročanja. Connectivity pa zdaj nastaja iz še enega povsem resničnega vprašanja:

Kako lahko rezervacija, narejena na Booking.com, postane del našega sistema, ne da bi moral človek ročno prenašati podatke med njima? Morda bo odgovor Channex.

Morda bo nekoč neposredna Booking.com API povezava. Najverjetneje pa bo odgovor kombinacija več adapterjev. Eno pa je že jasno.

Ko lasten Channel Manager začne iskati certificirano pot v infrastrukturo največjih rezervacijskih platform na svetu, projekt ni več samo koledar, ki si ga nekoč zgradil zase. Prišel je do vrat precej večjega sistema.

Tokrat smo potrkali.

Zdaj pa čakamo, kdo bo odprl.