假設一種情況：用戶需要用到他們大型機上的某項應用，但是廠商卻不能再提供服務支持。比如以前負責升級該應用的某個開發人員/管理員離職了，或者公司決定停止對升級服務的繼續投入。那么，替代方案是什么？在這里，我們將介紹幾項應用遷移的策略及各自的優缺點。例如應用現代化、重組、分布集成。

　　一般來說，可以替換掉應用（希望***能這樣），改用能夠支持的語言/操作系統/平臺。或者直接把這個應用當作“黑匣子”，在它下面建立一個獨立子應用處理所有升級需求。后兩個策略使用到下面這些廣為人知的技術：

　　1.大型機應用現代化：在應用前端設置一個網頁服務供應商接口，用以處理所有與該應用發生的交互活動。

　　2.重組：利用應用的原有功能，在另外一個平臺上把它轉化為相應功能。

　　3.分布集成：分配眾多子系統在多虛擬機和物理機上運行，使它們猶如一個整體在運轉。

　　我們應該把正反兩方面意見，把策略和技術上難點都納入考慮范圍。

　　一、更換應用

　　理想情況下，應用更換在任何時候都是最棒的替代方案。只要想象一下，新應用能夠神奇地出現在對你來說最省成本的平臺上并能正常運轉，不需任何花費，而且能準確復制大型機上已有的應用。而現實世界中，應用更換通常是最糟糕的替代方案。現成的成套應用方案無法模擬現實應用，這讓終端用戶很惱火；但從零開始研發成本太高，不僅會占用主要的IT項目，而且常常會因為對現有應用的功能知之甚少，且少有記載導致失敗；而且，替代方案實施失敗的話，也沒有所謂的B方案可供選用。

　　眾多成功的應用更換在牽涉到“關鍵業務大型機應用”時，采取的都是“足夠好”的辦法。也就是，把重新開發工作外包給一家兼具大型機和替換平臺（通常是linux）專業知識的應用遷移公司。他們使用的基礎軟件是經過時間驗證的（不管是不是開放源）。他們關注舊大型機應用的主要功能，并盡其所能減少新應用可能帶給用戶的不便感受。而且采用了“平等追蹤”的部署方式，能夠確保只有在新應用“服役”滿一年后舊應用才正式“引退”。

　　與直覺相反，針對上述替換方案現今***的目標操作系統，可能經常是“大型機上的Linux”。這里提到“Linux”是因為，它能根據需要，只作最小的應用修正（大型機Linux與大型機、放大Unix和擴容PC服務器稍有不同，但新應用完全能寫成便攜方式）就能允許對平臺的進一步變更。而這里提到“大型機”的原因則是，直到現在，許多用戶仍反映大型機處理應用擴容最節約成本。一位技術執行官最近跟我說到了他的認識，他發現一臺大型機負載達98%但仍有處理冗余，而一臺擴容服務器負載只不過50%時但讓人感覺后勁全無。這僅僅意味著擴容應用在大型機上運行較節約成本，因為如果在擴容配置中增加常規服務器花費很大。

　　二、轉換與分布集成

　　應用現代化

　　大型機應用的持續現代化，也包含了對網頁瀏覽器的支持，以及對PC訪問和網頁服務供應商界面的支持。但實際上，許多應用還未達到現代化標準，無法支持此類網頁，這其中可能就包括了你的應用。多數大型機軟件供應商針對此類問題有許多應對工具和服務。不論客戶是想在遷移應用前，還是在應用遷移到新平臺后，他們都能夠幫助達成添加網頁服務供應商界面這一目標。對于哪種是***的應用遷移方法并無定論。但是對大型機應用結構和操作了解的越多，就越容易將其封裝成“網頁服務供應商”。

　　人們常常低估了大型機應用現代化的效用。不過，應用遷移負責人要明白，如果想要建立內部云或者使用外部云平臺，除非大型機應用已經被轉化成網頁服務模式，否則它在云平臺上是不可用的。如果應用被虛擬成網頁服務形式，那么從長遠來看，云平臺的施行是再簡單不過的事情了。

　　重組

　　如果能夠對應用本身進行提取程序模型（確定程序實際運行方式），那么重組對于應用遷移來說就是一個好方法。對大型機應用進行重組的副作用通常是出現一個標準化模式，允許在開發設計階段（例如UML）進行修改。這類提取不僅允許生成面向所有主要編程語言和環境（例如，所有平臺上的Java）的應用實例，而且使得程序的修改和升級變得更容易。它不是對應用本身進行修改，而是通過修改設計來達到目的。

　　因此，“重組專家”的主要任務是利用IBM，CA Clerity公司和Micro Focus公司這類廠商的重組工具生成一個適合企業現有開發流程的標準模式。從而確保今后企業若想把應用遷移到另外的平臺，或是計劃對其進行現代化，擴展或合并時（例如，使其成為復合應用的一部分），此類操作會更快捷和更安全。

　　分布集成

　　分布集成是關于讓大型機應用（作為“黑匣子”或轉型應用）在兩個或兩個以上的目標平臺運行的理念，就像IBM的zEnterprise（Linux在刀片上，也在大型機系統上）。對于“黑匣子”型分布集成，使用z/OS或大型機Linux作為其中一個平臺以減小平臺移動的風險通常是有道理的。然而更具典型意義的是，分布集成涉及到的是向兩個平臺遷移而不是一個，不過平臺之間（例如，虛擬機管理，網絡和調度）的集成工具使得實際中對產生的子應用的集成變得更簡單。

　　分布集成取得成功的關鍵在于爭取到一個能使應用性能***化的目標應用分布。比如，一個能從放大中受益的應用，要盡可能把重負荷放在放大服務器上處理（放大或大型機Linux），并利用應用的擴容元件執行“邊緣”任務，例如緩沖。擴容型應用則應把多平行復本放到網格型或刀片型網絡中的多重虛擬機上，同時把不易發生故障的放大機作為管理重點。

　　很多應用屬于zEnterprise方案的“折衷”版本，分別由放大和擴容來處理各自擅長的部分。在這種情況下，用戶要尋求跨平臺管理工具的***化支持。我們可以看到，通過一些努力，現在有可能讓Windows成為目標平臺之一--通過在z/OS上安裝Windows模擬器，以“黑匣子”方式部署或重新編譯Linux版本以兼容Windows（需要重新編寫多達20%的原代碼）。

　　分布集成的另一個關鍵任務是建立隨時可以與其它分布應用進行分布通訊和集成的應用。這點經常被錯誤理解為在各應用之間建立起標準化通訊。實際上，分布集成的主要目標是要建立起應用之間數據交換的標準化方式--更具體來說，要界定應用里的元數據并使其涵蓋進全球元數據池。然后，類似ETL和IBM’s Information Server的數據合并解決方案就可以利用這些數據掌握數據管理，跨企業報告等等。

　　轉換

　　就像前面所指出的那樣，轉換就是要改變現有大型機應用的代碼，以使其能適應在不同平臺上運行和升級。因此，轉換的目標是盡可能少作變動，盡可能自動化運行。也許還需要把它分解到多平臺上，或是在轉換過程中進行升級以便支持復合應用或適應更高級的云和網頁功能。

　　有三種基本途徑可以對此類大型機應用進行轉換：

　　1.建立一個包含基礎軟件型目標平臺的目標環境，并重寫不受支持部分。例如，依賴CICS,MQSeries和DB2的大型機COBOL應用可以利用廠商的轉換程序，雖然要重寫交叉匯編碼。可以從廠商和Clerity Solutions這樣的應用遷移外包商那里獲得Linux基礎支持。

　　2.上面已經介紹過大型機應用重組。這里補充一點，雖然應用遷移外包商在這方面做得越來越好，但是也存在一些情況會讓他們感到無能為力或困難重重。

　　3.根據需要逐項重新編寫應用。經驗表明，這很可能與更換應用一樣冒險，甚至代價會更大。無論如何，對于業務關鍵性應用，這可能是***的選擇了。

　　從長遠看，應用重組可能是***的方案。因為應用重組從根本上對代碼進行了現代化處理，使得對應用的進一步變更有更大靈活性。在上述三個例子中，轉換應用時，使應用現代化無疑是個好主意。因為類似的用途會是網頁型組織的一部分，甚至可能是云平臺的一部分。分布集成是可以自由選擇的。許多案例可以證明，要把轉換過程包含在分布集成內將會過于復雜。

#p#　　三、“黑匣子”分布應用

　　應對撤消大型機應用支持，“黑匣子”方案并不是一個理想的長遠解決辦法。它會加大應用再變更的難度，但它卻是風險最小、最省成本的辦法。基本思想是，不觸動應用本身，但要用網頁服務供應商界面把應用包圍起來，使得在開發人員，管理員和終端用戶看來，它就像Linux或Unix應用一樣在運行。需要升級時，界面會把終端用戶需求轉化成新代碼并交付給新平臺來處理。

　　這個辦法行得通的原因在于，在現實世界中，從現在起，即使不是全部亦是大多數大型機應用漏洞將會成為調整的問題，遠超出以前的麻煩程度。網頁服務界面處理這類問題的辦法是暫緩需求處理，重寫功能代碼。這么做肯定會造成問題，所以這不是一個優越的執行方案，存在自身風險--假設問題被解決了，然后又發現那并不是最糟糕情況--但是精心做的話，它卻是快速節約的實施方案，風險也極低。

　　從定義看，“黑匣子”分布應用實施包括，應用現代化（供應商界面），分布集成（供應商界面代碼和新平臺的新代碼，但是“黑匣子”在老平臺上），但并不包括重組。這意味著大型機環境要有網頁服務供應商界面的開發支持和跨虛擬機網絡和管理--現在多數大型機環境都具備這點，在機箱外。所以，如果把大型機型Linux作為新平臺，可以自己動手操作，也可以從IBM獲取一點幫助。當然，所有其它環境也同樣支持網頁服務供應商界面，虛擬機，跨平臺網絡和開發；只不過，跨平臺管理可能要多花點力氣。

　　成本低的緣故，自己動手安裝“黑匣子”的想法很有吸引力。但是，預算足夠的話，我還是建議把活外包給IBM，CA Technologies，或Clerity這樣專業的公司。即使這樣，還是比其它方案來得省錢。這些公司憑借與其它IT大型機應用長期打交道的經驗，了解難點在哪里，所以能給出諸如該類型應用架構未來可能出現的漏洞之類有價值的建議。這些建議對于業務關鍵性應用可以說是無價之寶。

　　大型機應用現代化的現實情況

　　關于上述所有的策略還有一則警示：代碼轉移到新平臺，意味著性能損失。損失可能不大，就像“黑匣子”方案中出現的；損失也可能很大，遭遇到重新編寫多數甚至全部代碼的情況。但經驗表明，很少出現新應用一開始就在新環境出運行順暢的情況。

　　那么該如何在這些策略中做出選擇呢？首先，剔除那些不可行選項。很多情況下，無法做到有效替換。有時候，代碼過于定制化或無法滲透，那么根本不能進行重組。這時，你要問問自己這個應用到底有多重要，撤消支持的需求有多急迫。對于不是特別關鍵的應用，如果時間允許的話，重組或者別的形式的轉換可能正是需要的手段。如果需求很急切，“黑匣子”可能是唯一出路。

　　只有到這個時候你才需要考慮費用。這是因為現實生活中經常出現這樣的情形，“要么現在付錢，要么回頭多付”。初期投入最少方案似乎很有吸引力，例如根據需要逐項重寫應用，或是直接啟用號稱能起到同樣作用的新型開放源應用。但是據調查，很多項目都是由于終端用戶對于新應用，及伴隨出現的停機時間和無法修復的故障等情況產生了極大不滿而最終失敗。所以仔細權衡承擔的風險和后續將產生的維護費用后再做出合理的初始投入決定才是明智的。

　　***一個忠告：一些把大型機應用重新配置到新平臺的應用遷移項目從長遠看確實是值得的。通常是因為，網頁服務供應商界面允許大型機代碼在復合應用中得以重新使用，或者重組讓終端新用戶能夠獲取所需功能，而代碼也能為新應用所用。所以不要把應用遷移看作逃不掉的苦差事，像人體的牙根管。它也可能是沙子里的鉆石，蘊含著優秀的潛質。