Kuidas vähendada suurarvutite migreerimise riske: analüüs, mis tuleb enne kolimist teha

Suurarvutite migreerimised ebaõnnestuvad etteaimatava põhjuse tõttu. Mitte sellepärast, et sihtpilve arhitektuur oleks vale. Mitte sellepärast, et COBOL-Java teisendustööriistad oleksid ebapiisavad. Mitte sellepärast, et meeskonnal puuduks kavatsus või eelarve. Need ebaõnnestuvad, sest meeskond hakkab asju liigutama enne, kui nad teavad, mis asjad on, enne kui nad saavad vastata tõenditega, mitte eeldustega, mida iga programm teeb, millised programmid sõltuvad teistest, kuidas andmed süsteemis liiguvad ja mis lakkab töötamast, kui midagi muutub. Rikke režiim on peaaegu alati sama: migreerimise keskel avastatud sõltuvus, mille olemasolust keegi ei teadnud; ärireegel, mis on maetud 400 programmi kaasasolevasse märkmikku; partiitöö, mis toidab kahtteist allavoolu süsteemi faili kaudu, mida keegi ei tulnud dokumenteerima.

Suurarvutite migreerimisprotsess nõuab hoolikat planeerimist ja teostamist, et minimeerida riske ja tagada äritegevuse järjepidevus. See väide on küll tõene, kuid mittetäielik. Hoolikas planeerimine ei ole mitte tegevuskava, tarnija valik ega etapiviisiline ajakava. Enne selliste otsuste tegemist tehakse struktuurianalüüs, mis näitab, mida süsteem tegelikult sisaldab ja kuidas see tegelikult töötab, mitte seda, mida dokumentatsioon väidab ja kuidas see algselt töötama pidi. Need kaks kirjeldust erinevad igas suures suurarvuti keskkonnas, sageli marginaali võrra, mis määrab, kas migreerimine õnnestub või takerdub.

Miks suurarvutite migratsioon ebaõnnestub: analüüsilünk

Suurarvutite migratsioonid ei ebaõnnestu koodi vananemise tõttu, vaid seetõttu, et keegi ei tea tegelikult, mida kood teeb, enne kui on liiga hilja. Varjatud loogika. Dokumenteerimata ääremaa juhtumid. Unustatud vood. Need ei ole teoreetilised riskid, vaid praktilised takistused, mis takistavad projekte, käivitavad tootmisprobleeme ja vaikselt õõnestavad usaldust migratsiooniplaani vastu.

Analüüsilüngal on kindel struktuur. Organisatsioonid, mis on suurarvutisüsteeme käitanud kakskümmend või kolmkümmend aastat, on kogunud muudatusi, mis pole kunagi dokumentatsioonis kajastunud, sõltuvusi, mis tekkisid orgaaniliselt programmide ühendamisel jagatud failide, mitte otseste liideste kaudu, ning äriloogikat, mis eksisteerib ainult nende arendajate peas, kes on sellest ajast alates pensionile jäänud. Meeskonnad, kes käsitlevad suurarvutiandmeid standardfailidena, avastavad migreerimise ajal valusaid üllatusi, kui nad mõistavad, et „andmed” sisaldavad aastakümneid äriloogikat, mis on laiali pillutatud tingimuslausetes ja 88-tasemelistes tingimusnimedes.

Migratsiooni takistavad neli spetsiifilist teadmiste lünka. Igaühe neist sulgemiseks on olemas analüüsitehnika. Ühtegi neist ei saa sulgeda ainult dokumentatsiooni ülevaatamise või arendajaintervjuudega.

Lünk 1: Tundmatu programmide inventuur. Organisatsioonid avastavad rutiinselt, et nende tegelik programmide arv on oluliselt suurem kui dokumenteeritud programmide arv. Konkreetsete ärivajaduste jaoks kirjutatud programmid, testprogrammid, millest said tootmisprogrammid, utiliidiprogrammid, mille loomist keegi ei mäleta – kõik need on laadimisteegis ja neid saavad käivitada JCL-tööd, mis ilmuvad tootmisgraafikutes.

Lünk 2: Dokumenteerimata sõltuvused. Suurarvutid toidavad kümneid süsteeme keerukate vahetarkvara võrgustike kaudu nagu WebSphere, CICS Transaction Gateway, Enterprise Service Bus, lisaks jagatud utiliidid, ajastajad ja äriprotsessid. Viga on selles, et kõigi nende ühenduste, eriti allavoolu andmevoogude ja tarbimismustrite kaardistamisega oodatakse liiga kaua.

Lünk 3: Sisseehitatud äriloogika. COBOL-programmid koguvad ärireegleid aastakümnete jooksul. Arvutust, mis oli 1985. aastal lihtne, on sellest ajast alates muutnud kaksteist arendajat, lisades igaüks tingimusliku loogika, mis peegeldab ärireegli muudatust, mida pole kusagil mujal dokumenteeritud. Programmi teisaldamine ilma loogikast aru saamata annab tulemuseks migreeritud süsteemi, mis arvutab erinevaid tulemusi kui originaal, koodi seisukohast õigesti, äri seisukohast valesti.

Lünk 4: Andmevormingu ja skeemi sidumine. Programmid, mis jagavad andmeid failide, mitte API-de kaudu, on seotud andmevormingu lepingute kaudu, mis eksisteerivad ainult nende FD- ja COPY-lausetes. Jagatud faili kirjepaigutuse muutmine lõhub kõik programmid, mis seda loevad, sealhulgas võivad olla nii migratsiooniulatuses olevad programmid kui ka suurarvutisse jäävad programmid, mis tekitab vaikse integratsioonivea.

Kaheksa analüüsi, mis peavad enne rännet toimuma

Enne mis tahes migreerimisotsuse lõplikku langetamist ja enne koodiga tegelema asumist tuleks läbi viia järgmised analüüsid. Need ei ole kiirelt tehtavad esialgsed sammud, vaid alus, millele iga järgnev otsus tugineb.

1. Täielik programmi inventuur

Esimene analüüs on rahvaloendus: millised programmid, töövood, koopiaraamatud, protseduurid ja andmemääratlused keskkonnas tegelikult eksisteerivad. See ei ole dokumentatsiooni ülevaade. See on tegelike laadimis-, lähtekoodi- ja protseduuriteekide parsimine autoriteetse inventuuri loomiseks.

Inventuur peaks hõlmama: iga lähtekoodiprogrammi koos selle keele ja ligikaudse suurusega; iga õpikut ja programme, mis seda sisaldavad; iga kataloogitud protseduuri ja töid, mis seda kutsuvad; iga andmestikku, mis esineb DD-lausetes, ja programme, mis seda loovad või tarbivad; iga DB2 tabelit, vaadet ja salvestatud protseduuri, millele viidatakse manustatud SQL-is.

Enamikus suurtes suurarvutikeskkondades paljastab see inventuur programme, mis olid migratsiooni planeerimise meeskonnale tundmatud, mõnikord 20–30% ulatuses koguarvust. Mittetäielike inventuuride alusel kavandatud migratsiooniplaanid põhjustavad kulude ületamist, kui puuduvad programmid avastatakse projekti keskel.

2. Sõltuvuste kaardistamine kõigis keeltes

Kui inventuur on olemas, jälgib sõltuvuste kaardistamine, kuidas iga komponent on omavahel ühendatud. Sõltuvuste kaart on kõige olulisem migratsioonieelne analüüs, kuna see määratleb iga järgneva muudatuse ulatuse.

Täielik sõltuvuskaart hõlmab järgmist:

• Programmidevahelised kõned: CALL, PERFORM, LINK, ATTACH ja dünaamilised CALL-id, mis lahendatakse käitusajal
• JCL-i programmi kutsumised: iga EXEC PGM= lause igas JCL töövoos, sealhulgas PROC kutsumised, mille sümboolse parameetri asendamine on lahendatud
• Koopiate kaasamise ketid: millised programmid milliseid vihikuid sisaldavad, sh teiste vihikute poolt lisatud pesastatud vihikud
• Andmekogumi tootja-tarbija suhted: millised programmid millistesse andmekogumitesse kirjutavad, millised programmid nendest andmekogumitest loevad ja millised järjestikused tööahela sõltuvused see loob
• DB2 skeemi viited: millised programmid millistest tabelitest loevad või millistesse kirjutavad, millised tabelid jagavad skeemi milliste teiste tabelitega

Väljund on suunatud graaf. Iga kavandatud muudatuse mõju selles graafikus saab analüüsida, läbides servi, et loetleda kõik teised sellest sõltuvad sõlmed. Ilma selle graafikuta on mõjuanalüüs oletuslik.

Enne mis tahes koodi puudutamist on ülioluline sügav nähtavus. Aegunud dokumentatsioonile toetumine on saatuslik viga; automatiseeritud tööriistad peavad kaardistama praeguse oleku, skannides automaatselt JCL-i, COBOLi ja PL/I-d, kaardistades kõik rakendused, andmevood, sõltuvused ja peidetud tööd.

3. Äriloogika eraldamine ja dokumenteerimine

COBOL-programmid sisaldavad äriloogikat, mida mujal organisatsioonis ei leidu. See on migratsiooni planeerimisel kõige enam tähelepanuta jäetud analüüs, mis põhjustab kõige kulukamaid migratsioonijärgseid ebaõnnestumisi.

Äriloogika ekstraheerimine dokumenteerib järgmise: struktuuridesse IF/THEN/ELSE ja EVALUATE kodeeritud otsustusreeglid; COMPUTE-lausetes olevad arvutusvalemid; PROCEDURE DIVISION-lõikudes olevad andmete valideerimisreeglid; veakäsitlusteed ja nende äriline tähendus; ning järjestuspõhine loogika, kus toimingute järjekord on väljundi õigsuse seisukohalt oluline.

See analüüs ei nõua iga programmi iga rea ​​käsitsi lugemist. COBOL-i mõistavad staatilise analüüsi tööriistad suudavad tuvastada otsustusstruktuure, eraldada tingimusloogika ja luua struktureeritud dokumentatsiooni nende kodeeritud reeglitest. Sellel väljundil on kaks eesmärki: see annab migratsioonimeeskonnale spetsifikatsiooni, mida nad vajavad migreeritud süsteemi õigete tulemuste kinnitamiseks, ja annab ettevõttele esimese süstemaatilise dokumentatsiooni ärireeglitest, mis võisid aastakümneid eksisteerida ainult koodis.

4. Surnud koodi tuvastamine

Kõike suurarvutis olevat pole vaja migreerida. Programmid, mida ükski töövoog kunagi ei kutsu, lõigud, mida ükski kutsumistee kunagi ei käivita, koopiaraamatu liikmed, millele kunagi ei viidata – kõik see kujutab endast migreerimispingutust, mis ei tooda ärilist väärtust.

Surnud koodi tuvastamine analüüsib sõltuvusgraafikut, et leida komponente, millele puuduvad sissetulevad viited ühestki tootmistöövoost. Need komponendid saab migreerimise ulatusest välja jätta, vähendades kulusid ilma funktsionaalsust vähendamata. Suurtes pärandkeskkondades moodustab surnud kood tavaliselt 10–25% kogu inventuurist, mis vähendab oluliselt ulatust süstemaatilise tuvastamise, mitte kogemata avastamise korral.

Analüüs peab eristama tõeliselt surnud koodi (mis pole kunagi üheltki tootmisprotsessist kättesaadav) ja harva teostatavat koodi (mis on kättesaadav, kuid harva käivitatakse). Harva teostatav kood, näiteks aasta lõpu töötlemisrutiinid, regulatiivsed aruandlusprogrammid või katastroofide taastamise protseduurid, võib olla kriitilise tähtsusega hoolimata haruldasest teostamisest. Selle migreerimisest väljajätmine loob süsteemi, mis töötab korrektselt 99% ajast ja tõrgub just siis, kui seda kõige rohkem vajatakse.

5. Keerukus ja riskide liigitamine

Kui programmide inventuur ja sõltuvuste kaart on olemas, saab iga programmi liigitada keerukuse ja migreerimisriski järgi. Klassifikatsioon määrab järjestamise: madala keerukusega ja madala sõltuvusega programmid migreeritakse esimesena; kõrge keerukusega ja suure sõltuvusega programmid migreeritakse viimasena, läbides kõige põhjalikuma testimise.

COBOL-i migratsiooniriski keerukusnäitajad:

Keerukuse tegur	Mida mõõta	Kõrge riskilävi
Tsüklomaatiline keerukus	Otsustusharude arv programmi kohta	Üle 50 programmi kohta
Copybooki sõltuvuste arv	Kaasasolevate vihikute arv	Üle 20 vihiku
Kutsutud isikute arv	Programmide arv, mis seda programmi kutsuvad	Üle 15 helistaja
Andmekogumi viited	Loetud või kirjutatud andmekogumite arv	Üle 30 andmekogumi
Sisseehitatud SQL	SQL-lausete arv	Üle 100 avalduse
EXEC CICS kõned	Tehinguserveri sidumine	Mis tahes CICS-sõltuvus
Dünaamilised kõned	Kõned lahendati käitusajal	Iga dünaamiline kõne
Assembleri kutsumised	Mitte-COBOL-loogika sisse ehitatud	Iga Assembleri kõne

Mitme teguri põhjal kõrge punktisummaga programmid esindavad kõige suurema riskiga migratsioonikomponente. Need nõuavad kõige põhjalikumat analüüsi, kõige kogenumaid migratsiooniinsenere ja kõige ulatuslikumat testimist.

6. Pakiakna ja ajastamise sõltuvusanalüüs

Suurarvuti partii-tööd töötavad ajastatud akendes keerukate sõltuvusahelatega: töö B ei saa käivituda enne, kui töö A on edukalt lõpule viidud; töö C töötab ainult kuu viimasel tööpäeval; tööl D on maksimaalse käitusaja piirang, mis mõjutab töö E algusaega. Need ajastamissõltuvused on osa süsteemi töökäitumisest ja neid tuleb sihtkeskkonnas korrata.

Partiiakna analüüs dokumenteerib: iga tootmispartii käivitamise täieliku täitmisahela; iga etapi ajapiirangud; tingimusliku täitmisloogika (mis juhtub, kui etapp ebaõnnestub või annab nullist erineva tagastuskoodi); etappide vahel liikuvad andmekogumid; ja partiisüsteemi loodud välised päästikud ja teavitused.

Pilvepõhiste sihtmärkide puhul tähendab see: samaväärset CI/CD torujuhtme või töövoo orkestreerimise konfiguratsiooni; veakäsitluse ja teavituste seadistamist; jälgimise ja SLA konfiguratsiooni; ning integratsiooni allavoolu süsteemidega, mis saavad partiiväljundeid.

7. Andmete kvaliteedi ja vormingu hindamine

Pärandsüsteemid sisaldavad sageli tuhandeid COBOL-, PL/I- või assembler-keeles kirjutatud koodiridu, millest suur osa võib olla halvasti dokumenteeritud või tihedalt seotud. Kasutage staatiliste analüüside tööriistu tehnilise võla, üleliigse koodi ja moodulite tuvastamiseks, mida saab modulariseerida või mis on eemaldatavad.

Andmekvaliteedi hindamisel uuritakse tootmisandmestike tegelikke andmeid COBOL FD ja koopiaraamatu definitsioonide vormingumääratluste alusel. Lahknevused on levinud: pakitud kümnendväljad, mis sisaldavad teatud kirjetüüpide puhul sobimatuid bitimustreid; muutuva pikkusega väljad, mille pikkusindikaator on kirjete alamhulga puhul vahemikust väljas; EBCDIC-märgiväljad, mis sisaldavad teatud positsioonidel mittekuvatavaid väärtusi.

Need lahknevused tuleb enne migreerimist tuvastada ja lahendada, mitte avastada migreerimise testimise ajal. Andmete migreerimisel, mis teisaldab 500 miljonit kirjet ja seejärel avastab, et 0.1% neist on sobimatutes vormingutes, on tootmist mõjutav defekt, mis esines lähteandmetes ja oli valideerimisetapini teadmata.

8. Integratsioon ja väliste süsteemide kaardistamine

Teie andmepäring peab hõlmama iga süsteemi, mis tarbib suurarvutite andmeid, alates aruandlustööriistadest kuni partnerintegratsioonideni, sest moderniseerimisprojektid ei saa käivituda, kui meeskonnad avastavad arenduse hilisemas etapis, et nende andmevoogude säilitamine oli küll oluline, kuid planeerimata.

Integratsioonikaardistus tuvastab kõik suurarvutivälised süsteemid, mis sellelt andmeid vastu võtavad või sinna andmeid saadavad: allavoolu rakendused, mis tarbivad partiiväljundeid failiedastuse kaudu; reaalajas liidesed MQ, CICS või API kõnede kaudu; partnerintegratsioonid, mis tuginevad kindlatele failivormingutele ja edastusgraafikutele; aruandlussüsteemid, mis pärivad otse DB2 tabeleid; ja andmelao kanalid, mis tarbivad teisendatud suurarvuti andmeid.

Iga integratsioonipunkt on potentsiaalne üleminekurisk: migreeritud süsteem, mis genereerib andmeid vormingus, mida allavoolu süsteem ei oota, põhjustab vaikse tõrke, mida ei pruugita tuvastada enne, kui allavoolu tarbija anomaaliast teatab. Integratsiooni kaardistamine on analüüs, mis muudab üleminekuplaneerimise pigem terviklikuks kui optimistlikuks.

Migratsioonistrateegia valimine analüüsi tulemuste põhjal

Migratsioonieelne analüüs mitte ainult ei maanda migratsiooni riske, vaid määrab ka iga komponendi jaoks sobiva migratsioonistrateegia. Meeskonnad migreerivad suurarvutite töökoormusi erinevalt, olenevalt sellest, kui palju muudatusi nad hallata suudavad. Analüüsi tulemused mõjutavad otseselt seda otsust.

Analüüsi leid	Soovitatav strateegia	Põhimõte
Madal keerukus, vähe sõltuvusi, dünaamilisi kõnesid pole	Ümberpaigutamine (tõstmine ja nihutamine)	Madalaim risk; käitumuslik samaväärsus saavutatav kiiresti
Mõõdukas keerukus, hästi dokumenteeritud äriloogika	Ümberplatvormimine	Mõningane modifikatsioon on vastuvõetav; loogika on arusaadav
Kõrge keerukus, tihe sõltuvusgraaf	Faasiline kägistaja-viigimari	Ekstrakti inkrementaalselt; säilita suurarvuti tuuma jaoks, samal ajal selle ümber moderniseerides
Kriitiline jagatud programm, üle 100 helistaja	API mähkimine	Avalikusta teenusena; migreeri tarbijaid programmi puutumata
Sobimatute andmete või vorminguga programmid	Andmete parandamine kõigepealt	Migreerimine ei saa õnnestuda enne, kui andmed on puhtad
Surnud kood kinnitati analüüsiga	Pensionile jääda	Migratsiooni pole vaja; eemalda ulatuselt
Dokumenteerimata äriloogika, VKE-d pole saadaval	Vajalik on põhjalik analüüs	Ei saa turvaliselt migreerida enne, kui loogika on eraldatud ja dokumenteeritud

Migratsioonijärjestuse koostamine sõltuvusgraafikust

Kui sõltuvusgraafik on valmis, määrab see migratsioonijärjestuse otse. Komponente, millel puuduvad sõltuvused teistest suurarvuti komponentidest, saab migreerida iseseisvalt ja varakult. Komponendid, millest paljud teised sõltuvad, tuleb migreerida viimasena, pärast seda, kui kõik nende sõltuvad on valmis.

Praktiline järjestamismeetod:

1. etapp: Utiliidiprogrammid ja eraldiseisvad partiitööd. Programmid ilma kutsujateta ja jagatud andmekogumiteta. Neid saab migreerida eraldi ilma koordineerimisnõueteta.

2. etapp: Lehtprogrammid sõltuvuspuus. Need on programmid, mis kutsuvad teisi, aga mida paljud ei kutsu. Nende migreerimine eemaldab need ülejäänud programmide sõltuvusulatusest.

3. etapp: Andmetega seotud programmid. Programmide rühmi, mis jagavad andmekogumeid, saab migreerida ühtse üksusena, lahendades migreeritud rühma andmevormingu lepingu.

4. etapp: Jagatud teenustega programmid. Paljude kutsujatega programmid, mis on sõltuvusgraafiku kõrge sissetungivusega sõlmed, migreeriti alles pärast seda, kui kõik kutsujad olid migreeritud implementatsiooni suhtes valideeritud.

5. etapp: Põhilised tehinguprogrammid. Kõige suurema riskiga komponendid migreeriti viimasena kõige põhjalikuma testimise ja kõige kontrollituma üleandmisprotsessiga.

See järjestus ei ole üldine heuristika, vaid tuletatakse migreeritava süsteemi spetsiifilisest sõltuvusgraafikust. Kahel sama programmide arvuga suurarvutikeskkonnal on täiesti erinevad optimaalsed migreerimisjärjestused, kuna nende sõltuvusstruktuurid erinevad.

Kuidas SMART TS XL Loob migratsioonieelse analüüsi

SMART TS XL teostab kõik selles artiklis kirjeldatud kaheksa analüüsi automaatselt, parsides keskkonna iga komponendi tegeliku lähtekoodi. See ei tugine dokumentatsioonile, arendajaintervjuudele ega olemasolevatele diagrammidele, vaid tuletab struktuurimudeli koodist endast, seega on mudel täpne isegi programmide puhul, mida pole kunagi dokumenteeritud, ja sõltuvuste puhul, mis tekkisid tahtmatult.

Pärandi moderniseerimise analüüs algab täieliku inventuuri genereerimisega: iga COBOL-programm, JCL-töövoog, koopiaraamat, PROC ja SQL-skeem kataloogitakse koos selle allika asukoha, suuruse, keeleversiooni ja esialgse keerukusskooriga. Rakenduse sõltuvuste kaardistamine loob täieliku sõltuvusgraafiku, lahendades JCL-i sümboolsed parameetrid JCL-i laiendusvõimaluse kaudu , et näidata tegelikke käivitatud programme, mitte lahendamata malliviiteid.

Mõjuanalüüsi funktsioon muudab sõltuvusgraafiku päringuliseks: enne mis tahes komponendi migreerimist saab meeskond küsida, mida selle eemaldamine suurarvutist mõjutab, ning saada nummerdatud ja struktureeritud loendi igast sõltuvast komponendist, mis vajab valideerimist või koordineerimist. Ettevõtte otsingu funktsioon muudab kogu inventuuri otsitavaks kõigis keeltes samaaegselt, leides iga programmi, mis loeb konkreetset andmestikku, iga märkmiku, mis määratleb konkreetse välja, iga SQL-lause, mis viitab konkreetsele veerule, sekunditega miljonite ridade koodibaasis.

Eelmigratsioonianalüüsi väljund ei ole projektiplaan. See on struktuuriline tõendusmaterjal: sõltuvusgraafik, keerukusklassifikatsioon, surnud koodi inventuur, äriloogika dokumentatsioon ja integratsioonikaart, mis koos näitavad migratsioonimeeskonnale täpselt, millega nad töötavad. See tõendusmaterjal teeb vahet migratsioonil, mis avastab üllatusi tootmises, ja migratsioonil, mis avastab need analüüsis, kui nende leidmise ja lahendamise kulud on nädalate, mitte kuude pikkused.

Analüüs ei ole üldkulu, see on ränne

Kõige levinum vastuväide põhjalikule migratsioonieelsele analüüsile on ajakava: organisatsioon on migratsiooni alguskuupäevaga paika pannud, juhtkonna surve on suur ja kuue kuni kaheksa nädala kulutamine analüüsile enne mis tahes koodi puudutamist tundub viivitusena. See arutluskäik pöörab riskikalkulatsiooni ümber. Kui reeglid on nähtavad ja vood kaardistatud, nihkub projekt spekulatsioonist inseneritööks. Automatiseerimisvahendid muudavad nähtamatu nähtavaks ja see on see, mis loeb.

Ilma täieliku analüüsita algav migratsioon ei alga kiiremini, vaid tundmatu ulatusega. Tundmatu ulatus tekitab ajakavaga seotud üllatusi, eelarve ületamisi ja tootmisintsidente, kui avastamata sõltuvused ilmnevad. Analüüsifaas ei lükka migratsiooni edasi; see ongi migratsioon. Iga sõltuvus, mis avastatakse analüüsi käigus, mitte ümberlülituse ajal, on tootmisintsident, mida ei toimunud. Iga programm, mis enne migratsiooni tuvastati surnud koodina, on pingutus, mida ei tehtud. Iga enne teisendamist dokumenteeritud ärireegel on valideerimiskriteerium, mida saab testida, mitte arvata.

Edukad organisatsioonid on need, mis tegelevad keerukusega ennetavalt, kaardistavad sõltuvused varakult, demokratiseerivad teadmisi, keskenduvad äriväärtusele ja koondavad oma tegevuse esimesest päevast alates selgete eesmärkide ümber. Need pole lihtsalt parimad tavad, vaid need eristavad mõõdetavat investeeringutasuvust pakkuvaid ümberkujundamisprojekte neist, mis muutuvad hoiatavaks näiteks.