Vanha järjestelmä kantaa muutakin kuin vanhaa koodia
Kypsä järjestelmä sisältää usein vuosien aikana neuvoteltua liiketoimintakäyttäytymistä. Osa säännöistä näkyy koodissa. Toiset sisältyvät eräajojen ajoitukseen, tietokantakäytäntöihin, operatiivisiin tarkistuslistoihin, toimittajien menettelyihin ja kokeneiden ihmisten harkintaan. Teknologian näkökulmasta nämä voivat vaikuttaa sattumanvaraisilta, vaikka ne ovat edelleen välttämättömiä jatkuvuudelle.
Uudistaminen epäonnistuu, jos nykyinen järjestelmä dokumentoidaan vain korvattavina komponentteina. Hyödyllisempi näkymä kartoittaa järjestelmän mahdollistamat kyvykkyydet, sen tukemat päätökset, sen omistaman kriittisen datan, sen syöttämät jatkoriippuvuudet, sen tarjoamat hallintakeinot ja poikkeukset, joita ihmiset hoitavat sen ympärillä. Tämä näkymä paljastaa, mikä voi muuttua ja minkä on säilyttävä yhteydessä.
Laadi jatkuvuusrekisteri ennen korvaavan ratkaisun työjonoa
Jatkuvuusrekisteri kuvaa tosiasiat ja käyttäytymisen, jotka jokaisen siirtymän on säilytettävä: vakaa identiteetti, liiketoimintamääritelmät, hyväksymisvaltuudet, ajoitusvelvoitteet, täsmäytyssäännöt, auditointinäyttö, palautumisodotukset ja palvelurajat. Jokaisella kohdalla pitäisi olla omistaja ja testaustapa. Rekisteri ei ole peruste kaiken historiallisen käyttäytymisen toistamiseen, vaan pohja harkituille päätöksille siitä, mitä säilytetään, muutetaan tai poistetaan käytöstä.
Tämä muuttaa selvitystyötä. Sen sijaan, että kysytään vain käyttäjien tarvitsemia ominaisuuksia, tiimit selvittävät, miksi sääntö on olemassa, mitä sen muuttamisesta seuraisi ja kenellä on valta hyväksyä seuraus. Vanhentunut käyttäytyminen voidaan poistaa luottavaisesti, kun sen tarkoitus ja riippuvuudet on tutkittu. Tärkeä käyttäytyminen voidaan suunnitella uudelleen sen sijaan, että se katoaisi vahingossa.
Suunnittele tavoite ja siirtymät yhdessä
Tavoitearkkitehtuuri osoittaa tulevat vastuut ja rajat. Se ei yksin kerro, miten organisaatio pystyy toimimaan huomenna. Siirtymäarkkitehtuurit kuvaavat välitilat, joiden on kannettava todellista työtä datan, rajapintojen ja käyttäjien siirtyessä. Niihin kuuluvat väliaikainen omistajuus, rinnakkaiselo, täsmäytys, lisävalvonta ja nimenomaiset käytöstäpoistokriteerit.
Siirtymien suunnittelu tavoitteen rinnalla testaa, onko tavoite saavutettavissa. Jos kriittistä identiteettiä ei voida uskottavasti siirtää, vanhoja ja uusia sääntöjä ajaa rinnakkain tai tuloksia todentaa molemmissa järjestelmäkokonaisuuksissa, tavoite voi tarvita toisenlaiset rajat. Siirtymä on oma arkkitehtuurinsa, ei dokumentoimattomaksi jäävää projektin tukirakennetta.
Jaa migraatio osiin liiketoimintakyvykkyyden ja näytön perusteella
Tekniset kerrokset ovat harvoin turvallisin migraatioyksikkö. Kaiken datan, sitten kaikkien palveluiden ja lopuksi kaikkien kanavien siirtäminen voi synnyttää pitkiä jaksoja, jolloin kukaan ei omista kokonaista liiketoiminnan lopputulosta. Kyvykkyyteen perustuva osakokonaisuus seuraa mielekästä polkua sääntöjen, datan, rajapintojen ja operatiivisen toiminnan läpi. Se voi olla kapea, mutta se voidaan hyväksyä kokonaisuutena.
Valitse osakokonaisuudet riippuvuuksien ja seurausten, ei pelkän helppouden, perusteella. Varhaisen työn pitäisi testata riskialtteimmat oletukset ilman sietämätöntä vaikutusaluetta. Jokainen osakokonaisuus tarvitsee onnistumis-, täsmäytys- ja palautumiskriteerit. Valmis tarkoittaa, että organisaatio pystyy operoimaan ja selittämään uuden polun, ei vain sitä, että koodi on julkaistu.
Käsittele rinnakkaiseloa toimintamallina
Rinnakkaiskäyttö nostaa esiin kysymyksiä, jotka migraatiokaavio usein sivuuttaa. Mikä järjestelmä on määräävä kunkin tiedon osalta? Voivatko molemmat vastaanottaa muutoksia? Miten identiteetit korreloidaan? Kuka päättää tulosten poiketessa toisistaan? Kuinka nopeasti täsmäytyksen on tapahduttava? Mikä näyttö osoittaa uuden käyttäytymisen vastaavan vanhaa silloin, kun vastaavuus on tarpeen?
Nämä ovat operatiivisia päätöksiä. Ne tarvitsevat omistajat, toimintaohjeet, seurannan ja eskaloinnin. Kaksoiskirjoitus tai datan replikointi voi olla osa mekanismia, mutta kumpikaan ei määritä liiketoiminnallista toimivaltaa. Yksiselitteinen päätö määräävästä tietolähteestä ja hallittu poikkeuspolku ovat synkronointiteknologian hienostuneisuutta tärkeämpiä.
Palautumisen on katettava liiketoiminnan tila, ei vain ohjelmistoversio
Sovellusversion palauttaminen ei automaattisesti peru järjestelmän aktiivisena aikana hyväksyttyjä tilauksia, lähetettyjä ilmoituksia, kirjattuja päätöksiä tai muunnettua dataa. Palautumissuunnittelussa on tunnistettava peruuttamattomat vaikutukset, korvaavat toimet ja piste, jonka jälkeen palaaminen aiempaan tilaan ei enää ole vastuullista.
Määrittele jokaiselle siirtymälle, mitä voidaan yrittää uudelleen, käsitellä uudelleen, täsmäyttää, korvata vastatoimella tai palauttaa. Testaa mekanismin lisäksi päätösprosessi. Johdon on tiedettävä, kuka voi keskeyttää etenemisen, mikä näyttö laukaisee päätöksen ja miten toiminta jatkuu ongelman selvittämisen aikana.
Käytä päätöskynnyksiä pelkän kalenteriin perustuvan etenemissuunnitelman sijaan
Uudistamisen etenemissuunnitelman pitäisi osoittaa siirtymätilojen välillä etenemiseen tarvittava näyttö: sääntöjen kattavuus ymmärretään, data täsmää hyväksytyn toleranssin rajoissa, palautuminen on testattu, tuen omistajuus on hyväksytty tai kriittinen riippuvuus on poistettu. Päivämäärät ovat tärkeitä, mutta ilman kynnysarvoja ne kannustavat raportoimaan etenemistä jo ennen riskin todellista muuttumista.
Päätöskirjaukset säilyttävät perustelun valitulle tavoitteelle, vaiheistukselle tai väliaikaiselle kompromissille. Ne kertovat myös, milloin oletus on arvioitava uudelleen. Tämä tekee hallinnasta kevyempää ja hyödyllisempää: huomio kohdistuu seurauksiltaan merkittävään epävarmuuteen sen sijaan, että jokainen yksityiskohta kulkisi saman päätösfoorumin kautta.