PortfólióDP.

Backendtermék · Capability-portfólió

Válaszd le az ügyfélutat,ne az üzleti célt.

A Customer Data Platform teljes termékfelelőssége hozzám tartozott, valamennyi moduljával együtt. Röviden: leválasztottuk az ügyfélutakat a legacy backendekről, miközben érdemben felgyorsítottuk a profiladatok elérését.

Szerepkör
Backend Product Owner
Időtartam
2022. máj. — 2023. okt.
Mérföldkő
A teljes termék leszállítva
Az első ügyféladat megjelenéséig eltelt idő a Telekom üzleteiben-75%
Teljes profilbetöltés-60%
Vezetékes My Profile-40%
Interaktív request flow

Kövesd a capabilityt,
ne a legacy topológiát.

Az ügyféladatoknak összetett legacy backendekből gyorsan változó frontend use case-ekbe kellett eljutniuk. A közvetlen függőségek lassították a változtatást, növelték a komplexitást és nehezítették az egyenletes teljesítményt.

FogyasztóNatív mobilalkalmazásokÜgyfélprofil az appos ügyfélútban
TermékhatárProfile APIREST · JSON · titkosított
Legacy backendrétegLegacy szolgáltatások orchesztrációjaÜgyfél · Megrendelések · Identitás
GET /profileStabil, use case-alapú szerződésCélérték <20 ms

Omnichannel kiszolgálás

Egy capability.
Három frontendcsatorna.

Ugyanaz az ügyfél-capability szolgálta ki a natív mobilalkalmazásokat, a webes ügyfélutakat és a Telekom üzletek belső platformjait. Minden csatorna stabil szerződést használt, miközben a CDP a termékhatár mögött kezelte a legacy backendek közötti különbségeket.

Lekérdezéshez kötött profilmigráció

Minden első, legacy backendből kiszolgált profillekérdezés egyben migrációs lépés is volt. Miután az ügyfél adatai bekerültek a CDP-be, a további lekérdezéseket már a CDP szolgálta ki, a legacy backend újbóli meghívása nélkül.

Közös ügyfél-capabilityCDP / Profile APIEgy stabil termékhatár
Natív mobilalkalmazásokÜgyfélprofil az appos ügyfélútban
WebMy Profile és webes ügyfélutak
Telekom üzletek belső platformjaiÜgyintézői ügyféllekérdezés

A termékdöntés

Egy proxy továbbadja a komplexitást.
Egy capability layer a saját határain belül kezeli.

A program egy AWS-en futó, legacy szolgáltatásokhoz kapcsolódó API-gyűjteményből álló Customer Data Platformot vezetett be. A natív mobilalkalmazásoknak, webes ügyfélutaknak és a Telekom üzletek belső platformjainak úgy kellett stabilan és biztonságosan elérniük az ügyfél-capabilityket, hogy közben ne kelljen ismerniük vagy kezelniük a backendek összetettségét.

01
Capability-alapú

A réteget tartós üzleti capability-k köré szerveztük a legacy rendszerstruktúrák leképezése helyett.

02
Use case-alapú szerződések

A frontend use case-ekből indultunk ki az endpoint-portfólió kialakításakor, így az API-szerződések a tényleges felhasználási igényekhez igazodtak.

03
Teljesítmény mint alapkövetelmény

A válaszidőt, a napi kérésszámot és a titkosítást termékkövetelményként kezeltük, nem pedig utólag ellenőrzendő technikai szempontként.

04
Stabil csatornahatár

A Customer Data Platformot és a REST API-kat használtuk határként a csatornák és az alaprendszerek között.

Nem funkcionális követelmények

Az architektúrát is konkrét termékkövetelmények keretezték.

Kialakítás

A legacy források eltérő struktúrákban és működési modellekben tették elérhetővé az ügyféladatokat.

Skálázhatóság

A rétegnek naponta több millió kérést kellett kiszolgálnia.

Sebesség

A válaszidő-elvárásokat milliszekundumokban mértük.

Biztonság

A titkosításnak, a helyben futó komponenseknek és a felhőszolgáltatásoknak egységes end-to-end architektúrában kellett együttműködniük.

Ügyfél- és csatornahatásAz ügyféladatok gyorsabban váltak elérhetővé anélkül, hogy a csatornáknak közvetlenül kezelniük kellett volna a backendek korlátait.
API-termékRESTJSONAWSMongoDBSAFeScrum
  • A Telekom üzleteiben több mint 75%-kal csökkent az első ügyféladat megjelenéséig eltelt idő.
  • A teljes profil betöltési ideje 60%-kal csökkent, felgyorsítva az ügyintéző által támogatott folyamatokat.
  • A vezetékes szerződéssel rendelkező ügyfelek My Profile betöltési ideje appban és weben egyaránt 40%-kal javult.
  • Lehetővé tettük a vezetékes és mobil szerződések, ügyfélprofilok és szerződő felek különböző domainek közötti összerendelését.
  • A profilmigrációt a valós használathoz kötöttük: miután az első, legacy backendből kiszolgált lekérdezés feltöltötte a CDP-t, a további kéréseket már a CDP szolgálta ki a legacy backend újbóli meghívása nélkül.
  • Naponta több millió kérést szolgáltunk ki 20 ms alatti válaszidő-céllal és vállalati szintű titkosítással.
A megfelelő leválasztási határ termékdöntés: a capability-k akkor maradnak értékesek, ha az ügyfél- és üzleti szándékot képviselik, nem a tegnapi rendszerek formáját.

Megjegyzés az eredményekhez · Az ügyféljourney- és teljesítményadatok a megadott projekteredményeket tükrözik; a saját szolgáltatástopológia absztrakt formában jelenik meg.

További munkák
Következő esettanulmány

FABRIC frontendmigráció

Kezdjünk beszélgetést

Találjuk meg, mit
érdemes megépíteni.

Szívesen beszélgetek összetett product ownershipről, üzleti elemzésről, beszállítóértékelésről és olyan kezdeményezésekről, ahol valódi együttműködésre van szükség az üzleti és a fejlesztői oldal között.