Ana Bilgisayar Geçişinde Riskleri Azaltma: Geçişten Önce Yapılması Gereken Analiz

Ana bilgisayar geçişleri tahmin edilebilir bir nedenle başarısız olur. Hedef bulut mimarisinin yanlış olmasından değil. COBOL'dan Java'ya dönüştürme araçlarının yetersiz olmasından değil. Ekibin niyet veya bütçe eksikliğinden değil. Başarısızlık, ekibin ne olduğunu bilmeden, her programın ne yaptığını, hangi programların hangilerine bağlı olduğunu, verilerin sistem içinde nasıl aktığını ve bir şey değiştiğinde nelerin bozulacağını varsayımlar yerine kanıtlarla yanıtlayamadan işleri taşımaya başlamasından kaynaklanır. Başarısızlık modu neredeyse her zaman aynıdır: geçişin ortasında kimsenin varlığından haberdar olmadığı bir bağımlılık keşfedilir, 400 program tarafından dahil edilen bir copybook'ta gizlenmiş bir iş kuralı, kimsenin belgelemeyi düşünmediği bir dosya aracılığıyla on iki alt sisteme veri gönderen bir toplu iş.

Ana bilgisayar geçiş süreci, riski en aza indirmek ve iş sürekliliğini sağlamak için dikkatli planlama ve uygulama gerektirir. Bu ifade doğru ancak eksiktir. Önemli olan dikkatli planlama, yol haritası, tedarikçi seçimi veya aşamalı zaman çizelgesi değildir. Bu, bu kararların hiçbiri alınmadan önce yapılan yapısal analizdir; sistemin aslında ne içerdiğini ve nasıl çalıştığını, dokümantasyonda belirtilenlerden ve başlangıçta nasıl çalışmak üzere tasarlandığından farklı olarak ortaya koyan analizdir. Bu iki açıklama, her büyük ana bilgisayar ortamında, genellikle geçişin başarılı olup olmayacağını belirleyen bir farkla birbirinden ayrılır.

Ana Bilgisayar Sistemlerinden Geçişlerin Başarısız Olmasının Nedenleri: Analiz Açığı

Ana bilgisayar sistemlerinden geçişler, kodun eski olmasından değil, çok geç olana kadar kodun ne yaptığını kimsenin gerçekten bilmemesinden dolayı başarısız olur. Gizli mantık. Belgelenmemiş uç durumlar. Unutulmuş iş akışları. Bunlar teorik riskler değil, projeleri durduran, üretim sorunlarını tetikleyen ve geçiş planına olan güveni sessizce aşındıran pratik engellerdir.

Analiz açığının belirli bir yapısı vardır. Yirmi veya otuz yıldır ana bilgisayar sistemleri kullanan kuruluşlar, dokümantasyonda hiç yansıtılmayan değişiklikler, açık arayüzler yerine paylaşılan dosyalar aracılığıyla programların birbirine bağlanmasıyla organik olarak oluşan bağımlılıklar ve yalnızca emekli olmuş geliştiricilerin zihninde var olan iş mantığı biriktirmiştir. Ana bilgisayar verilerini standart dosyalar gibi ele alan ekipler, geçiş sırasında "verilerin" koşullu ifadeler ve 88 seviyeli koşul adları arasında dağılmış onlarca yıllık iş mantığını içerdiğini fark ettiklerinde acı verici sürprizlerle karşılaşırlar.

Geçiş süreçlerini sekteye uğratan dört spesifik bilgi açığı vardır. Her birinin giderilmesi için bir analiz tekniği mevcuttur. Bunların hiçbiri yalnızca doküman incelemesi veya geliştirici görüşmeleriyle giderilemez.

1. Açık: Bilinmeyen program envanteri. Kuruluşlar, gerçek program sayılarının belgelenmiş program sayılarından önemli ölçüde daha yüksek olduğunu sıklıkla keşfederler. Belirli iş ihtiyaçları için yazılan programlar, üretim programı haline gelen test programları, kimsenin oluşturulduğunu hatırlamadığı yardımcı programlar; bunların hepsi yükleme kütüphanesinde bulunur ve üretim planlarında görünen JCL işleri tarafından çağrılabilir.

İkinci Açık: Belgelenmemiş bağımlılıklar. Ana bilgisayarlar, WebSphere, CICS İşlem Ağ Geçidi, Kurumsal Hizmet Veri Yolu gibi karmaşık ara yazılım ağları ve paylaşılan yardımcı programlar, zamanlayıcılar ve iş süreçleri aracılığıyla düzinelerce sistemi besler. Hata, özellikle aşağı yönlü veri akışları ve tüketim modelleri olmak üzere, tüm bu bağlantıları haritalamak için çok uzun süre beklemektir.

3. Açık: Gömülü iş mantığı. COBOL programları on yıllar boyunca iş kurallarını biriktirir. 1985'te basit olan bir hesaplama, o zamandan beri on iki geliştirici tarafından değiştirilmiş ve her biri, başka hiçbir yerde belgelenmemiş bir iş kuralı değişikliğini yansıtan koşullu mantık eklemiştir. Mantığı anlamadan programı taşımak, orijinalinden farklı sonuçlar hesaplayan bir taşınmış sistem üretir; bu, kod açısından doğru, iş açısından ise yanlıştır.

4. Açık: Veri formatı ve şema bağımlılığı. API'ler yerine dosyalar aracılığıyla veri paylaşan programlar, FD ve COPY ifadeleri dışında hiçbir yerde bulunmayan veri formatı sözleşmeleri aracılığıyla birbirine bağlanır. Paylaşılan bir dosyanın kayıt düzeninde yapılan bir değişiklik, onu okuyan her programı bozar; bu, geçiş kapsamındaki programları ve ana bilgisayarda kalacak programları da içerebilir ve sessiz bir entegrasyon hatasına yol açar.

Göçten Önce Yapılması Gereken Sekiz Analiz

Herhangi bir geçiş kararı kesinleşmeden ve herhangi bir kod üzerinde değişiklik yapılmadan önce aşağıdaki analizler tamamlanmalıdır. Bunlar aceleyle yapılacak ön adımlar değil, sonraki her kararın dayandığı temeldir.

1. Program Envanterini Tamamlayın

İlk analiz bir sayım niteliğindedir: ortamda hangi programlar, iş akışları, copybook'lar, prosedürler ve veri tanımları gerçekten mevcuttur. Bu bir dokümantasyon incelemesi değildir. Bu, yetkili bir envanter oluşturmak için gerçek yükleme kütüphanelerinin, kaynak kütüphanelerinin ve prosedür kütüphanelerinin ayrıştırılmasıdır.

Envanterde şunlar yer almalıdır: her kaynak program, dili ve yaklaşık boyutuyla birlikte; her copybook ve onu içeren programlar; her kataloglanmış prosedür ve onu çağıran işler; DD ifadelerinde görünen her veri kümesi ve onu üreten veya tüketen programlar; gömülü SQL'de referans verilen her DB2 tablosu, görünümü ve saklı prosedürü.

Çoğu büyük ana bilgisayar ortamında, bu envanter, geçiş planlama ekibi tarafından bilinmeyen programları ortaya çıkarır; bu fark bazen toplam sayının %20-30'una kadar ulaşabilir. Eksik envanterlere göre planlanan geçiş programları, proje ortasında eksik programlar keşfedildiğinde maliyet aşımlarına yol açar.

2. Tüm Dillerde Bağımlılık Eşlemesi

Envanter oluşturulduktan sonra, bağımlılık haritalaması her bileşenin diğer her bileşenle nasıl bağlantı kurduğunu izler. Bağımlılık haritası, sonraki her değişikliğin kapsamını tanımladığı için en kritik geçiş öncesi analizdir.

Eksiksiz bir bağımlılık haritası şunları kapsar:

• Programlar arası görüşmeler: Çalışma zamanında çözümlenen CALL, PERFORM, LINK, ATTACH ve dinamik CALL işlemleri.
• JCL'den programa çağrılarJCL iş akışındaki her EXEC PGM= ifadesi, sembolik parametre ikamesi içeren PROC çağrıları da dahil olmak üzere çözümlenir.
• Defter dahil etme zincirleriHangi programlar hangi kopyalama dosyalarını içeriyor, diğer kopyalama dosyaları tarafından dahil edilen iç içe kopyalama dosyaları da dahil.
• Veri kümesi üretici-tüketici ilişkileriHangi programların hangi veri kümelerine yazdığı, hangi programların bu veri kümelerinden okuduğu ve bunun yarattığı ardışık iş zinciri bağımlılıkları.
• DB2 şema referansları: Hangi programlar hangi tablolardan okuma veya yazma yapıyor, hangi tablolar hangi diğer tablolarla şema paylaşıyor

Çıktı, yönlendirilmiş bir grafiktir. Bu grafikteki herhangi bir düğümde önerilen herhangi bir değişikliğin etkisi, kenarları dolaşarak ona bağlı olan diğer tüm düğümleri numaralandırarak analiz edilebilir. Bu grafik olmadan, etki analizi tahmine dayalıdır.

Kod üzerinde herhangi bir değişiklik yapılmadan önce, kapsamlı bir görünürlük son derece önemlidir. Güncelliğini yitirmiş belgelere güvenmek ölümcül bir hatadır; otomatik araçlar, JCL, COBOL ve PL/I'yi tarayarak, tüm uygulamaları, veri akışlarını, bağımlılıkları ve gizli görevleri haritalandırarak mevcut durumu otomatik olarak belirlemelidir.

3. İş Mantığı Çıkarma ve Belgeleme

COBOL programları, kuruluşun başka hiçbir yerinde bulunmayan iş mantığı içerir. Bu, geçiş planlamasında en çok göz ardı edilen analizdir ve geçiş sonrası en maliyetli başarısızlıkları doğuran unsurdur.

İş mantığı çıkarımı şu unsurların dokümantasyonunu üretir: IF/THEN/ELSE ve EVALUATE yapılarında kodlanmış karar kuralları; COMPUTE ifadelerindeki hesaplama formülleri; PROCEDURE DIVISION paragraflarındaki veri doğrulama kuralları; hata işleme yolları ve bunların iş anlamı; ve işlemlerin sırasının çıktının doğruluğu için önemli olduğu sıraya bağlı mantık.

Bu analiz, her programın her satırını manuel olarak okumayı gerektirmez. COBOL'u anlayan statik analiz araçları, karar yapılarını belirleyebilir, koşullu mantığı çıkarabilir ve kodladıkları kuralların yapılandırılmış dokümantasyonunu üretebilir. Bu çıktı iki amaca hizmet eder: geçiş ekibine, geçişi yapılan sistemin doğru sonuçlar ürettiğini doğrulamak için ihtiyaç duydukları spesifikasyonu sağlar ve işletmeye, on yıllarca yalnızca kodda var olmuş olabilecek iş kurallarının ilk sistematik dokümantasyonunu sunar.

4. Ölü Kod Tanımlaması

Ana bilgisayardaki her şeyin taşınması gerekmez. Hiçbir iş akışı tarafından çağrılmayan programlar, hiçbir çağrı yolu tarafından yürütülmeyen paragraflar, hiçbir zaman referans alınmayan copybook üyeleri; bunların hepsi, iş değeri üretmeyen taşıma çabalarını temsil eder.

Ölü kod tespiti, üretim iş akışlarından gelen hiçbir referansı olmayan bileşenleri bulmak için bağımlılık grafiğini ayrıştırır. Bu bileşenler, işlevselliği azaltmadan maliyeti düşürmek için geçiş kapsamından çıkarılabilir. Büyük eski sistemlerde, ölü kod genellikle toplam envanterin %10-25'ini temsil eder; bu da sistematik olarak belirlendiğinde, tesadüfen keşfedilmesine kıyasla kapsamda önemli bir azalma anlamına gelir.

Analiz, gerçekten ölü kod (üretim yürütme yollarından hiçbir zaman erişilemeyen) ile nadiren yürütülen kod (erişilebilir ancak nadiren tetiklenen) arasında ayrım yapmalıdır. Yıl sonu işlem rutinleri, düzenleyici raporlama programları veya felaket kurtarma prosedürleri gibi nadiren yürütülen kodlar, seyrek yürütülmelerine rağmen kritik olabilir. Bunları geçişten hariç tutmak, sistemin %99 oranında doğru çalışmasını ve en çok ihtiyaç duyulduğu anda arızalanmasını sağlar.

5. Karmaşıklık ve Risk Sınıflandırması

Program envanteri ve bağımlılık haritası oluşturulduktan sonra, her program karmaşıklık ve geçiş riski açısından sınıflandırılabilir. Bu sınıflandırma, geçiş sırasını belirler: düşük karmaşıklık ve düşük bağımlılık içeren programlar önce, yüksek karmaşıklık ve yüksek bağımlılık içeren programlar ise en kapsamlı test kapsamıyla en son taşınır.

COBOL geçiş riskine yönelik karmaşıklık ölçütleri:

Karmaşıklık Faktörü	Ne Ölçülmeli	Yüksek Risk Eşiği
Siklomatik karmaşıklık	Program başına karar dallarının sayısı	Program başına 50'nin üzerinde
Kopya defteri bağımlılık sayısı	Dahil edilen defter sayısı	20'den fazla defter
Arayan sayısı	Bu programı çağıran program sayısı	15'ten fazla arayan
Veri kümesi referansları	Okunan veya yazılan veri kümelerinin sayısı	30'dan fazla veri seti
Gömülü SQL	SQL sorgularının sayısı	100'den fazla ifade
CICS yöneticisi aramaları	İşlem sunucusu bağımlılığı	Herhangi bir CICS bağımlılığı
Dinamik Çağrılar	Çağrılar çalışma zamanında çözümlendi.	Herhangi bir dinamik çağrı
Assembler çağrıları	COBOL dışı mantık gömülü	Herhangi bir Montajcı çağrısı

Birden fazla faktörde yüksek puan alan programlar, en yüksek riskli geçiş bileşenlerini temsil eder. Bunlar en kapsamlı analizi, en deneyimli geçiş mühendislerini ve en kapsamlı test kapsamını gerektirir.

6. Toplu İşlem Penceresi ve Planlama Bağımlılığı Analizi

Ana bilgisayar sistemlerindeki toplu işler, karmaşık bağımlılık zincirleriyle zamanlanmış zaman aralıklarında çalışır: B işi, A işi başarıyla tamamlanana kadar başlayamaz; C işi yalnızca ayın son iş gününde çalışır; D işinin, E işinin başlama zamanını etkileyen maksimum çalışma süresi kısıtlaması vardır. Bu zamanlama bağımlılıkları, sistemin operasyonel davranışının bir parçasıdır ve hedef ortamda da tekrarlanmalıdır.

Toplu işlem penceresi analizi belgeleri şunları içerir: her üretim toplu işlemi için tam yürütme zinciri; her adımdaki zaman kısıtlamaları; koşullu yürütme mantığı (bir adım başarısız olduğunda veya sıfır olmayan bir dönüş kodu ürettiğinde ne olacağı); adımlar arasında akan veri kümeleri; ve toplu işlem sisteminin ürettiği harici tetikleyiciler ve bildirimler.

Bulut tabanlı hedeflerde bu, şu anlama gelir: eşdeğer CI/CD işlem hattı veya iş akışı düzenleme yapılandırması; hata işleme ve uyarı kurulumu; izleme ve SLA yapılandırması; ve toplu çıktıları alan alt sistemlerle entegrasyon.

7. Veri Kalitesi ve Biçim Değerlendirmesi

Eski sistemler genellikle COBOL, PL/I veya assembler dillerinde yazılmış binlerce satır kod içerir ve bunların çoğu yetersiz belgelendirilmiş veya birbirine sıkıca bağlıdır. Teknik borcu, gereksiz kodu ve modülerleştirilebilecek veya kullanımdan kaldırılabilecek modülleri tespit etmek için statik analiz araçlarını kullanın.

Veri kalitesi değerlendirmesi, üretim veri kümelerindeki gerçek verileri COBOL FD ve copybook tanımlarındaki format tanımlarıyla karşılaştırarak inceler. Sık rastlanan tutarsızlıklar şunlardır: belirli kayıt türleri için geçersiz bit desenleri içeren paketlenmiş ondalık alanlar, uzunluk göstergesinin kayıtların bir alt kümesi için aralık dışında olduğu değişken uzunluklu alanlar, belirli konumlarda görüntülenemeyen değerler içeren EBCDIC karakter alanları.

Bu tutarsızlıklar, geçiş testleri sırasında değil, geçişten önce belirlenip çözülmelidir. 500 milyon kaydı taşıyan ve daha sonra bunların %0.1'inin geçersiz formatta olduğunu keşfeden bir veri geçişi, kaynak verilerde mevcut olan ve doğrulama adımına kadar bilinmeyen, üretimi etkileyen bir kusura sahiptir.

8. Entegrasyon ve Harici Sistem Eşleştirmesi

Veri soy ağacınız, raporlama araçlarından iş ortağı entegrasyonlarına kadar ana bilgisayar verilerini kullanan her sistemi kapsamalıdır; çünkü modernizasyon projeleri, ekiplerin geliştirmenin son aşamalarında bu veri akışlarının korunmasının gerekli ancak planlanmamış olduğunu keşfetmeleri durumunda hayata geçirilemez.

Entegrasyon eşlemesi, ana bilgisayardan veri alan veya ona veri gönderen ana bilgisayar dışındaki her sistemi tanımlar: dosya aktarımı yoluyla toplu çıktıları tüketen alt uygulamalar; MQ, CICS veya API çağrıları aracılığıyla gerçek zamanlı arayüzler; belirli dosya biçimlerine ve iletim programlarına dayanan iş ortağı entegrasyonları; DB2 tablolarını doğrudan sorgulayan raporlama sistemleri; ve dönüştürülmüş ana bilgisayar verilerini alan veri ambarı akışları.

Her entegrasyon noktası potansiyel bir geçiş riskidir: alt sistemin beklemediği bir formatta veri üreten taşınmış bir sistem, alt tüketici bir anormallik bildirene kadar tespit edilemeyebilecek sessiz bir arızaya neden olur. Entegrasyon haritalaması, geçiş planlamasını iyimser olmaktan ziyade kapsamlı hale getiren analizdir.

Analiz Sonuçlarına Göre Göç Stratejisi Seçimi

Geçiş öncesi analiz, geçiş riskini azaltmakla kalmaz, aynı zamanda her bir bileşen için hangi geçiş stratejisinin uygun olduğunu da belirler. Ekipler, yönetebilecekleri değişiklik miktarına bağlı olarak ana bilgisayar iş yüklerini farklı şekillerde taşırlar. Analiz sonuçları bu kararı doğrudan etkiler.

Analiz Bulguları	Önerilen Strateji	gerekçe
Düşük karmaşıklık, az bağımlılık, dinamik çağrı yok.	Yeniden barındırma (kaldır ve taşı)	En düşük risk; davranışsal eşdeğerliğe hızla ulaşılabilir.
Orta düzeyde karmaşıklık, iyi belgelenmiş iş mantığı	Yeniden platform oluşturma	Bazı değişiklikler kabul edilebilir; mantık anlaşılmıştır.
Yüksek karmaşıklık, yoğun bağımlılık grafiği	Aşamalı boğucu incir	Aşamalı olarak veri çıkarın; ana bilgisayarı temel işlevler için koruyun ve etrafındaki modernizasyon çalışmalarını sürdürün.
Kritik öneme sahip ortak program, 100'den fazla arayan	API sarmalama	Hizmet olarak sunun; programa dokunmadan tüketicileri başka bir yere taşıyın.
Geçersiz veri veya biçim sorunları içeren programlar	Önce veri düzeltmesi	Veriler temizlenene kadar geçiş işlemi başarılı olamaz.
Analizle ölü kod doğrulandı	emekli olmak	Geçiş işlemine gerek yok; kapsamdan kaldırın.
Belgelenmemiş iş mantığı, uzman desteği yok.	Derinlemesine analiz gereklidir.	Mantıksal kodlar çıkarılıp belgelenene kadar güvenli bir şekilde geçiş yapılamaz.

Bağımlılık Grafiğinden Göç Dizisini Oluşturma

Bağımlılık grafiği tamamlandığında, geçiş sırasını doğrudan tanımlar. Diğer ana bilgisayar bileşenlerine bağımlılığı olmayan bileşenler bağımsız olarak ve erken aşamada taşınabilir. Birçok bileşenin bağımlı olduğu bileşenler ise, tüm bağımlı bileşenleri hazır olduktan sonra en son taşınmalıdır.

Pratik bir sıralama yaklaşımı:

Aşama 1: Yardımcı programlar ve bağımsız toplu işler. Çağrı yapan programı ve paylaşılan veri kümesi olmayan programlar. Bunlar, koordinasyon gereksinimi olmadan tek başına taşınabilir.

2. Aşama: Bağımlılık ağacındaki yaprak programlar. Diğer programları çağıran ancak birçok program tarafından çağrılmayan programlar. Bunların taşınması, kalan programlar için bağımlılık kapsamından çıkarılmalarını sağlar.

3. Aşama: Veri bağlantılı programlar. Veri kümelerini paylaşan program grupları, taşınan grup içindeki veri formatı sözleşmesini çözerek, tek bir birim olarak birlikte taşınabilir.

4. Aşama: Paylaşımlı hizmet programları. Çok sayıda çağırıcısı olan programlar, bağımlılık grafiğindeki yüksek giriş sayısına sahip düğümler, tüm çağırıcılar taşınan uygulamaya karşı doğrulandıktan sonra taşınır.

Aşama 5: Temel işlem programları. En yüksek riskli bileşenler, en kapsamlı test kapsamı ve en kontrollü geçiş süreciyle en son taşınır.

Bu sıralama genel bir sezgisel yöntem değildir, taşınacak olan belirli sistemin özel bağımlılık grafiğinden türetilmiştir. Aynı program sayısına sahip iki ana bilgisayar ortamının, bağımlılık yapıları farklı olduğu için tamamen farklı optimal taşıma sıralamaları olacaktır.

Ne kadar SMART TS XL Göç Öncesi Analizi Üretir

SMART TS XL Bu araç, ortamdaki her bir bileşenin gerçek kaynak kodunu ayrıştırarak bu makalede açıklanan sekiz analizin tamamını otomatik olarak gerçekleştirir. Belgelere, geliştirici görüşmelerine veya mevcut diyagramlara dayanmaz; yapısal modeli kodun kendisinden türetir, bu nedenle model, hiç belgelenmemiş programlar ve kimsenin niyeti olmadan oluşan bağımlılıklar için bile doğrudur.

Eski sistemlerin modernizasyon analizi, eksiksiz bir envanter oluşturulmasıyla başlar: her COBOL programı, JCL iş akışı, copybook, PROC ve SQL şeması, kaynak konumu, boyutu, dil sürümü ve önsel karmaşıklık puanıyla birlikte kataloglanır. Uygulama bağımlılık eşlemesi , JCL sembolik parametrelerini JCL genişletme özelliği aracılığıyla çözerek, çözümlenmemiş şablon referansları yerine çağrılan gerçek programları gösteren eksiksiz bir bağımlılık grafiği oluşturur .

Etki analizi özelliği, bağımlılık grafiğini sorgulanabilir hale getirir: Herhangi bir bileşeni taşımadan önce, ekip ana bilgisayardan kaldırılmasının neleri etkileyeceğini sorabilir ve doğrulama veya koordinasyon gerektiren her bağımlı bileşenin numaralandırılmış, yapılandırılmış bir listesini alabilir. Kurumsal arama özelliği, tüm envanteri tüm dillerde eş zamanlı olarak aranabilir hale getirir; milyonlarca satırlık bir kod tabanında belirli bir veri kümesini okuyan her programı, belirli bir alanı tanımlayan her copybook'u, belirli bir sütuna referans veren her SQL ifadesini saniyeler içinde bulabilirsiniz.

Göç öncesi analizinin çıktısı bir proje planı değildir. Yapısal kanıtlardır: bağımlılık grafiği, karmaşıklık sınıflandırması, ölü kod envanteri, iş mantığı dokümantasyonu ve entegrasyon haritası; bunların hepsi birlikte göç ekibine tam olarak neyle çalıştıklarını gösterir. Bu kanıtlar, üretimde sürprizlerle karşılaşan bir göç ile analiz aşamasında sürprizlerle karşılaşan bir göç arasındaki farkı yaratır; çünkü bu tür sürprizleri bulmanın ve çözmenin maliyeti aylar yerine haftalar sürer.

Analiz, ek bir yük değil, bir geçiş işlemidir.

Kapsamlı geçiş öncesi analizine yönelik en yaygın itiraz zaman çizelgesiyle ilgilidir: kuruluş bir geçiş başlangıç ​​tarihi belirlemiştir, üst düzey yöneticiler üzerinde baskı yüksektir ve herhangi bir koda dokunmadan önce altı ila sekiz hafta analiz yapmak gecikme gibi gelir. Bu mantık, risk hesaplamasını tersine çevirir. Kurallar görünür hale geldiğinde ve akışlar haritalandırıldığında, proje spekülasyondan mühendisliğe geçer. Otomasyon araçları görünmeyeni görünür hale getirir ve önemli olan da budur.

Tam bir analiz yapılmadan başlayan bir geçiş daha hızlı başlamaz, bilinmeyen bir kapsamla başlar. Bilinmeyen kapsam, keşfedilmemiş bağımlılıklar ortaya çıktığında zamanlama sürprizlerine, bütçe aşımına ve üretim olaylarına yol açar. Analiz aşaması geçişi geciktirmez; geçişin kendisidir. Geçiş sırasında değil de analiz sırasında keşfedilen her bağımlılık, gerçekleşmeyen bir üretim olayıdır. Geçişten önce ölü kod olarak tanımlanan her program, harcanmamış bir çabadır. Dönüşümden önce belgelenen her iş kuralı, tahmin edilmek yerine test edilebilen bir doğrulama kriteridir.

Başarılı olan kuruluşlar, karmaşıklığı proaktif bir şekilde ele alan, bağımlılıkları erken aşamada belirleyen, bilgiyi demokratikleştiren, iş değerine odaklanan ve ilk günden itibaren net hedefler etrafında birleşen kuruluşlardır. Bunlar sadece en iyi uygulamalar değil, ölçülebilir yatırım getirisi sağlayan dönüşüm projeleri ile ibretlik öykülere dönüşen projeler arasındaki farkı yaratan unsurlardır.