Kysymys, johon tämä moduuli vastaa: Miten piirrän järjestelmäkartan, joka näyttää, minne tiedot kulkevat?
Anna minulle uusi skenaario ja tyhjä valkotaulu, niin yksi ensimmäisistä asioista, jotka piirrän, on järjestelmäkartta. Ei kaunis, ei jokaista API:a, ei vielä tietomallia. Haluan nähdä yrityksen: keitä käyttäjät ovat, mitkä järjestelmät ovat mukana, missä Salesforce sijaitsee, mikä sitä ympäröi, mistä tiedot tulevat ja minne ne menevät. Ja sitten haluan kävellä nuolet läpi. Hyvä järjestelmäkartta ei ole kuva laatikoista. Se on tapa tuoda arkkitehtuuriset päätökset esiin.
Teetän tätä harjoitusta CTA-kandidaateilla. Lue skenaario ja ala sitten piirtää. Älä odota, että olet ratkaissut kaiken päässäsi; piirtäminen auttaa sinua ratkaisemaan sen. Siksi ensimmäisen päivän kotitehtävä on aloittaa järjestelmäkartta ennen kuin yrität tietomallia. Piirrä tietomalli ensin, niin olet jo olettanut, mitä Salesforceen kuuluu. Piirrä järjestelmäkartta ensin, niin näet järjestelmät, joiden pitäisi muovata tuota päätöstä.
Aloita korkealta ja porau sitten alas: ensin koko yritys, sitten yksityiskohdat siellä, missä niillä on väliä.
Järjestelmäkartan voi piirtää monella tavalla. Tämä on vain minun tapani, jota olen hionut monta vuotta, ja jaan sen, jotta näet, miten sellaisen voi koota nopeasti. Käytän sitä jokaisessa Salesforce-järjestelmäkartassa, ja se luetaan kuin lause: vasemmalla olevat ihmiset tavoittavat keskellä olevan Salesforcen, luottamus tulee sen yläpuolella olevista järjestelmistä, palvelu kulkee sen alapuolella olevien kanavien kautta, ja se on yhteydessä oikealla oleviin taustatoimintoihin.
Ihmiset vasemmalla, ylhäältä alas: sisäiset käyttäjät, kumppanit, asiakkaat. Ei vielä jokaista persoonaa; tarpeeksi vastaamaan kysymykseen kuka yrittää tavoittaa tämän arkkitehtuurin? Jokainen ryhmä osoittaa sinne, mistä se tulee sisään: sisäiset käyttäjät Salesforceen, kumppanit kumppaniyhteisöön, asiakkaat asiakasyhteisöön. Järjestelmät eivät ole olemassa itsestään. Joku, tai jokin, yrittää käyttää niitä.
Vaihe 2/6: kuka yrittää tavoittaa tämän arkkitehtuurin?
Salesforce keskellä. Yksi pelkistetty laatikko. Ei siksi, että Salesforce olisi yrityksen keskipiste (käytimme juuri kolme moduulia sanoaksemme, ettei se ole), vaan siksi, että se on järjestelmä, jonka ympärille suunnittelen. Se on ankkuri.
Yhteisöt aivan sen alla, kiinni siinä. Kumppaniyhteisö ja asiakasyhteisö ovat erillisiä päätepisteitä, joten ne saavat omat laatikkonsa. Mutta ne ovat kiinni Salesforcessa, koska mitään ei tarvitse integroida niiden tavoittamiseksi: ne toimivat samassa orgissa.
Vaihe 3/6: Salesforce keskellä, yhteisöt aivan sen alla.
Identiteetti yläpuolella. Identiteetinhallinnan palvelut tulevat ylös, ne, jotka kehittäjät unohtavat: yksi sisäisille käyttäjille, ehkä toinen kumppaneille. Myös AppExchange-paketit menevät sinne, siirrettynä oikealle, koska ne ovat orgiin tuotuja ominaisuuksia eivätkä taustajärjestelmiä, jotka vaihtavat tietoja sen kanssa. Julkiset verkkosivustot ovat vasemmassa yläkulmassa.
Vaihe 4/6: identiteetti yläpuolella, laatikko, jonka kehittäjät unohtavat.
Integraatio ja sitten taustatoiminnot oikealle. Integraatiokerros, ESB tai iPaaS (tai MuleSoft, kun se on nimetty), on korkea palkki heti Salesforcen oikealla puolella. Sisäiset järjestelmät ovat sen takana: ERP:t, talous, tilaustenhallinta, vanhat järjestelmät, tietovarasto. Nyt sivu luetaan vasemmalta oikealle: ihmiset, Salesforce, integraatio, taustatoiminnot.
Kanavat alapuolella. Kaikki, millä on suora yhteys asiakkaisiin: email-to-case, web-to-lead, puhelin, viestintä.
Tiedot sisään ja ulos, oikeassa alakulmassa. Ulkoiset tietolähteet, arkistot, tietojen lataukset.
Data 360 oikealla, integraatiokerroksen alapuolella. Käyttäjät eivät koskaan yhdisty siihen, ja sen tenantti yhdistyy moniin taustajärjestelmiin, joten se on putkiston joukossa, missä nuo viivat pysyvät lyhyinä: sisäisten järjestelmien, tietovaraston ja oikean alakulman tietojen vieressä. Datatiimit kyllä avaavat sen näkymiä, mutta ne näkymät ovat orgissa: Data 360 on lähellä corea (near-core), sitä hallitaan coressa ja se isännöidään coren ulkopuolella (moduuli 1). Yksi viiva takaisin Salesforceen näyttää, kuka sitä hallitsee. Laatikon paikan pitäisi kertoa tarina siitä, mitä se tekee.
Mikään tästä geometriasta ei ole pyhää. Käytännön arvo on siinä, etten keksi visuaalista kieltä joka kerta uudelleen, ja jokainen, joka on nähnyt yhden kaavioistani, lukee seuraavan nopeammin.
Pidä merkintätapa yksinkertaisena. Jokainen järjestelmä on kortti: sen nimi, sen rooli ja pieni kuvake, joka kertoo, millainen asia se on: ERP, tietokanta, identiteetinhallinnan palvelu, ihmisryhmä. Juuri kuvaamani alueet piirretään himmeinä, nimettyinä vyöhykkeinä, joten itse asettelu näkyy. Alareunan selite kertoo, mitä jokainen kuvake ja viiva tarkoittaa.
Älä laita liikaa laatikon sisään. Vain hyvin monimutkaisessa järjestelmäkartassa avaan Salesforcen osiinsa (Sales Cloud ja Service Cloud orgin sisällä nuolineen niiden välillä). Äläkä keksi viittätoista muotoa, ellei jokainen niistä kerro lukijalle jotain. Haluan, että joku katsoo järjestelmäkarttaa kolmekymmentä sekuntia ja alkaa ymmärtää arkkitehtuuria. Hienous ei auta. Selkeys auttaa.
Älä odota yksityiskohtaista suunnittelua ennen kuin ajattelet volyymia. Nuoli, joka kuljettaa 500 tuotetta yössä, ja nuoli, joka kuljettaa 200 000 GPS-lukemaa päivässä, voivat näyttää järjestelmäkartassa täsmälleen samalta. Ne eivät ole sama ongelma. Joten ennen kuin piirrät yhtäkään nuolta, laske, mitä liikkuu. Aloita kuvan takana oleva inventaario määristä: yksi rivi kutakin tärkeää tietojoukkoa kohden volyymeineen. Nollat eivät ehkä koskaan näy nuolissa, mutta sinun täytyy tietää, milloin siirryt suuriin lukuihin: tuhansia tai miljoonia tunnissa, satojatuhansia transaktioita, jopa kymmeniä tai satoja transaktioita sekunnissa.
Nuo luvut ohjaavat mekanismia. Muutama sata tietuetta yössä on eräajo. Kutsu, jota joku odottaa, voi olla synkroninen, jos volyymi sen sallii. Kymmenet tai sadat sekunnissa voivat vaatia tapahtumia, kuten platform eventejä, tietuekohtaisen kutsun sijaan. Nuoli näyttää samalta; volyymi ratkaisee, mikä sitä kuljettaa, joten kirjaa se inventaarioon, jossa mekanismi valitaan.
Mekanismi voi jopa muuttaa nuolen suunnan. Lähetä pari tietuetta minuutissa, niin Salesforce voi yksinkertaisesti tehdä kutsun ulos: nuoli alkaa Salesforcesta. Lähetä paljon enemmän, niin Salesforce voi sen sijaan julkaista tapahtumia tapahtumaväylälle; ulkoinen järjestelmä tilaa ne ja kutsuu sisään hakemaan ne, joten nyt nuoli alkaa toisesta päästä. Vielä isompi, vaikkapa miljoonien tietueiden öinen synkronointi, ja se on eräajo. Tunne siis määräsi aikaisin, kun alat suunnitella mekanismeja, koska määrät voivat piirtää nuolet uudelleen.
Volyymilla on merkitystä kahdessa paikassa, kahdesta syystä. Tietomallissa tarvitsen sitä suurten tietomäärien tarkkailuun ja arkistoinnin suunnitteluun; osa 2 menee siihen syvälle. Järjestelmäkartassa inventaarion suuret luvut ohjaavat integraatiomallin ja mekanismin valintaa. Moduuli 6 laittaa todelliset nollat Steve Truckingin järjestelmäkarttaan ja sen inventaarioon. Kun määrät ovat käsissä, piirrä nuolet.
Kun järjestelmät ovat paikoillaan, yhdistä ne, niin järjestelmäkartasta tulee arkkitehtuuria. Laatikko on järjestelmä; nuoli näyttää, kuka avaa yhteyden. Se alkaa järjestelmästä, joka avaa yhteyden, ja osoittaa siihen, jota se kutsuu: asiakkaasta palvelimeen. Nimiö kertoo, mikä liikkuu ja mihin suuntaan.
Tuo sääntö koskee järjestelmäkarttoja, joissa järjestelmät puhuvat järjestelmille. Tietovirtakaaviossa nuoli seuraa tietoja, kuten odottaisitkin. Älä vie järjestelmäkartan sääntöä muihin kaavioihin; se vain lisää sekaannusta.
Nuolet lisätty. Jokainen laatikko on siellä, missä se oli; jokainen nuoli alkaa järjestelmästä, joka avaa yhteyden, ja sen nimiö kertoo, mikä liikkuu ja mihin suuntaan.
Joten jos integraatiokerros työntää tuotteita Salesforceen, nuoli kulkee integraatiokerroksesta Salesforceen nimiöllä tuotteet sisään. Jos Salesforce kutsuu ulos hakemaan ne, nuoli alkaa Salesforcesta, ja nimiö on yhä tuotteet sisään. Samat tiedot, eri keskustelu, ja se ero kertoo minulle, kuka tarvitsee tunnistetiedot ja kenen täytyy käsitellä virhe. Salesforce lähettää tilauksen integraatiokerroksen kautta: tilaukset ulos. ERP:n toimitustieto palaa: tilauksen tila sisään. Nyt näen, kuka aloittaa kunkin keskustelun, missä tiedot tulevat Salesforceen ja missä ne lähtevät, mitkä virrat ylittävät rajoja, missä omistajuus luultavasti on ja missä minun täytyy kysyä lisää.
Ja muista moduuli 1: aina kun näen vain yhden virran, huolestun. Korkealla tasolla tilaukset ulos -nuoli riippuu paluuvirroista: asiakkaat sisään, tuotteet sisään, hinnat. Katso vielä syvemmälle, niin siellä on paluumatka: hyväksyntä, hylkäys, tila, laskun numero, peruutus. Nuolet antavat minulle jotain konkreettista haastettavaksi.
Tässä kohdassa järjestelmäkartta lakkaa olemasta PowerPoint-taidetta. Arviointilautakunnassa mikä tahansa nuoli voi herättää kolme kysymystä, ja haluan, että sinulla on vastaukset:
Miten se todentaa? OAuth, varmenne, Named Credential, jokin muu?
Onko se synkroninen vai asynkroninen? Odottaako Salesforce ERP:tä, vai julkaiseeko se ja jatkaa? Kuinka nopeasti liiketoiminta tarvitsee tuloksen?
Mikä on mekanismi? REST-kutsu, tapahtuma, tiedosto, viestijono, MuleSoftin kautta vai suoraan?
Ja sitten: mitä tapahtuu, kun toinen puoli on alhaalla? Jokainen nuoli tarvitsee mekanismin. Jos et osaa selittää sitä, viiva on koriste.
Eikä ”lähetä ja unohda” ole vastaus. Se tarkoittaa yleensä: ”en ole suunnitellut, mitä lähettämisen jälkeen tapahtuu.” Saapuiko se? Hyväksyttiinkö se? Epäonnistuiko se? Yritetäänkö uudelleen? Kuka tietää, että se on jumissa? Entä jos sama viesti saapuu kahdesti? Mikään tästä ei mene järjestelmäkarttaan, josta tulisi lukukelvoton. Mutta nuolen pitäisi saada sinut tietämään, että nuo kysymykset ovat olemassa.
Zoomaa mihin tahansa nuoleen, niin siellä on asiakas ja palvelin, ja kumpikin omistaa oman puoliskonsa. Asiakas avaa yhteyden: se tarvitsee päätepisteen ja portin, hakee ensin tunnisteen (token) todennuspalvelimelta, kutsuu palvelimen määrittelemää protokollaa ja sopimusta ja päättää, odottaako se. Vain asiakas näkee koko edestakaisen matkan, joten vain asiakas voi yrittää uudelleen. Palvelin kuuntelee, määrittelee protokollan, sopimuksen ja payloadin, validoi sen, mitä sisään tulee, ja näkee vain oman osansa. Kun piirrän nuolen, tiedän jo, kumpi pää on kumpi, ja se kertoo minulle, kuka omistaa kunkin näistä kysymyksistä.
Yksi nuoli lähempää: asiakas hoitaa, palvelin määrittelee. Mikään tästä ei mene järjestelmäkarttaan, mutta jokaisessa nuolessa se on.
Käännä nyt nuoli toisin päin. Kun ERP kutsuu Salesforcea, Salesforce on palvelin: se määrittelee API:t, pyörittää omaa valtuutuspalvelintaan ja päättää External Client Appin ja integraatiokäyttäjän avulla, mitä kutsuja saa tehdä. Samat kysymykset, toinen puoli.
Tässä kohdassa arkkitehdit pilaavat hyvän kaavion: he laittavat yhden dokumentin vastaamaan kaikkeen. Järjestelmäkarttaan tulee API-nimiä, payloadeja, uudelleenyrityksiä, virhejonoja, muunnoksia, jokainen takaisinkutsu, ja pian kukaan ei pysty lukemaan sitä. Älä tee niin. Järjestelmäkartta on kokonaiskuva: järjestelmät ja niiden väliset tärkeät virrat.
Kun minun täytyy selittää vuorovaikutus, piirrän toisen kaavion, mutta en jokaisesta integraatiosta. Jos järjestelmä A lähettää jotain B:lle tai jopa kysyy ja saa vastauksen, nimetty nuoli riittää. Haluan uimaratakaavion, kun prosessista tulee keskustelu: A kutsuu B:tä, B tarkistaa C:ltä, C vastaa, B luo jotain ja kutsuu takaisin A:ta, ihminen hyväksyy, toinen järjestelmä jatkaa. Nyrkkisääntöni: enemmän kuin yksi tai kaksi edestakaista vaihtoa, niin järjestys saa oman uimaratakaavionsa. Nuolet järjestelmäkarttaan; keskustelu uimaratakaavioon.
Ja huomaa, että nuoli tarkoittaa siellä eri asiaa. Järjestelmäkartassa nuoli on yhteys: kuka sen avaa ja mikä liikkuu. Uimaratakaaviossa jokainen nuoli on yksi viesti keskustelussa, ja ne luetaan järjestyksessä: pyyntö menee yhteen suuntaan, vastaus palaa toiseen, ja seuraava vaihe seuraa.
Kolme nuolta järjestelmäkartassa; kuusi vaihetta uimaratakaaviossa. Järjestelmäkartassa nuoli on yhteys; uimaratakaaviossa jokainen nuoli on yksi viesti, järjestyksessä.
Kun järjestelmäkartta näyttää enimmäkseen valmiilta, kävele se läpi nuoli nuolelta. ERP:stä Salesforceen: mikä liikkuu, kuka sen omistaa, miten se todentaa, mikä on mekanismi, synkroninen vai asynkroninen, kuinka ajantasainen sen täytyy olla? Sitten seuraava nuoli, ja seuraava. Tässä aukot tulevat esiin. ”Ai, emme koskaan selvittäneet, miten kumppani oikeasti lähettää sen.” ”Lähetämme tilaukset ERP:hen, mutta emme ole suunnitelleet, miten hylätyt palaavat.” Hyvä. Löysit sen valkotaululta etkä tuotannosta.
Kuvan täytyy pysyä luettavana, joten yksityiskohdat menevät sen takana olevaan inventaarioon. Aloitit sen määristä; viimeistele se nyt, yksi rivi kutakin tärkeää tietojoukkoa tai virtaa kohden:
Siksi pidän tästä dokumentista: se auttaa minua ajattelemaan. ”Miten raportoimme Salesforcen ja ERP:n yli?” Se on moduulin 3 kysymys: mikä kaavioistani ratkaisee tämän kauniisti? Järjestelmäkartta. Jos kaikki on coressa, vakioraportit. Jos tiedot ovat ERP:ssä ja tietovarastossa, näet sen heti. ”Missä tämän asiakasattribuutin perustietoja pitäisi hallita?” Katso, mitkä järjestelmät käyttävät sitä ja mikä jo omistaa asiakkaan. ”Tarvitseeko Salesforce jokaisen GPS-lukeman?” Kuka sen tuottaa, kuka sitä kuluttaa, mikä on kuormitus? Ehkä Salesforce tarvitsee nykyisen sijainnin, ja toinen alusta säilyttää historian. Järjestelmäkartta ei ojenna sinulle vastausta. Se antaa sinulle oikean näkymän ongelmaan.
Vielä yksi kurinalaisuus. Olemassa olevassa yrityksessä piirrä se, mikä on olemassa, älä sitä, minkä toivoisit olevan olemassa. Taulukko, joka lähetetään sähköpostilla joka perjantai: piirrä se. Kumppanin CSV SFTP-palvelimella: piirrä se. Integraatio, joka ohittaa ESB:n historiallisista syistä: piirrä se. Ihmiset, jotka syöttävät tietoja käsin uudelleen kahden järjestelmän välillä: näytä se. Älä siivoa todellisuutta samalla kun dokumentoit sitä. Tarvitset nykyisen järjestelmäkartan ennen kuin suunnittelet tavoitetilan, ja juuri sen teemme Steve Truckingille moduulissa 6.
Kokeen jälkeen: mitä tekoäly muuttaa. Järjestelmäkartasta on tulossa agenttikartta. Jos agentti vastaa kysymykseen ”missä toimitukseni on?”, järjestelmäkartan täytyy kertoa, tuleeko vastaus Salesforcesta, kumppanin järjestelmästä, telematiikasta, ERP:stä vai niiden yhdistelmästä. Agentit eivät poista järjestelmien rajoja; ne tekevät vielä tärkeämmäksi sen tietämisen, mikä järjestelmä on auktoritatiivinen ja miten sen tavoittaa turvallisesti.
Mitkä järjestelmät ja käyttäjäjoukot kuuluvat järjestelmäkarttaan, ja miten niiden sijoittelu näyttää niiden roolin.
Mitkä virrat ylittävät järjestelmien rajat, mihin suuntaan ja mitä palaa takaisin.
Miten kukin yhteys todentaa, mikä mekanismi sitä kuljettaa ja onko se synkroninen, asynkroninen, eräajo vai federoitu.
Milloin nimetty nuoli riittää ja milloin vuorovaikutus tarvitsee oman uimaratakaavionsa.
Mitä kuvan takana oleva inventaario kirjaa: omistaja, kuormitus, volyymi, org, ajoitus, todennus sekä kopiointi, viittaus tai federointi.
Järjestelmäkartta ei ole jotain, mitä piirrän sen jälkeen, kun arkkitehtuuri on valmis. Se on tapa, jolla löydän arkkitehtuurin. Ja kun luulet sen olevan valmis, älä ihaile sitä. Kävele se läpi. Jokainen nuoli, jota et vielä osaa selittää, näyttää, missä työ on.
