在企業軟體傳遞中,軟體供應鍊的産業化被視為成本控制和效率的基石。如本章所述的軟體工廠就提供了一個重要的工業化視角來看待企業軟體傳遞,從這裡面我們可以觀察到一些東西:
軟體工廠方法需要一套不同的思路來監測進展并實作有效的狀态管理。大多數傳統的名額突出了兩類衡量标準:生産力,即傳遞的功能點或源代碼行數;以及品質,即每個傳遞子產品中的缺陷數。這種措施有一定的用處,但對于企業軟體傳遞的供應鍊視角來說還顯不足。這些衡量标準必須着眼于各個供應商的更廣泛的服務水準協定 (sla) ,其中可能包括成本、可預測性、時間表變動、需求的波動、對新需求的響應速度等。類似地,供應鍊傳遞過程的透明度變得至關重要。這種透明度可能會介于下面兩種觀點之間:“黑盒”觀點,即供應商完全控制自己的傳遞方式(使用哪些流程、工具和做法)和“白盒”觀點,即所有活動都開放地進行讨論、檢查和審查。确定一種方法(并協調和管理這些活動)對于供應鍊的運作至關重要。
在許多情況下,機構會在企業軟體傳遞過程中選擇各種不同的合作夥伴。機構不僅為不同的專業任務選擇不同的供應商,還将在某些領域實施多源采購,以減少風險、提高靈活性并加強競争。雖然這樣的計劃能夠創造價值,但複雜的供應鍊也大大增加了管理成本。
多源采購的一個極端版本,就是在部件傳遞中采用“衆包”。一些機構已經開始做出傳遞方法的嘗試,基本上就是将新的需求進行“拍賣”,目标就是找到能滿足規定需求的最便宜的供應商。這是典型的提案邀請 (request for proposals, rfp) 方法的一個擴充,面向更開放的市場,推向更廣闊的候選對象,提高部件供應商的靈活性。當然,企業必須解決這種方法面臨的諸多挑戰,特别是在安全性、知識産權和品質等方面。
現在開始出現一種更标準化的方法來解決軟體工廠的基礎設施問題。對傳統的源代碼管理和變更管理工具進行擴充,協同應用生命周期管理 (collaborative application life-cycle management, calm) 對于采用軟體工廠方法的機構的重要性與日俱增[46]。calm的核心,就是認識到企業軟體傳遞中必須協調許多不同的分布式團隊。這些團隊可能來自不同的公司,地點也很分散。是以,calm技術加強了一套軟體工廠做法和工具,在各個層次的合作傳遞場景中都可以輕松适應廣泛分布的團隊。在極端情況下,這些團隊可能由職責、責任移交和産品所有權都非常明确的外包供應商構成。然而,許多較為折衷的混合情況也很常見,軟體工廠的基礎設施必須能夠适應這些安排。
已經證明,在供應鍊中,一個健康的部件供應商生态系統極為關鍵。軟體工廠中的供應商機構必須能夠對部件的傳遞進行優化,并且這往往是為許多潛在的消費者進行的。我們現在所看到的最有意思的方法之一涉及模型驅動架構 (mda) 和ple技術[47]。
在這些方法中,使用系統特性的抽象模型來生成部件和子部件。相比針對特定系統傳遞的代碼而言,機構可以更容易地針對不同的使用環境來分析和優化這些模型。有了這些方法,出現了專門針對部件和部件加工的供應商。例如,一些金融服務機構選擇用第三方核心銀行架構起步,并通過修改其資料模型和流程模型來讓它适應自己的經營環境,避免了自己從頭開發。
虛拟化技術平台對于采用軟體工廠方法的機構特别有吸引力。與其他行業類似,分布分散且營運靈活的供應鍊需要一個适合這些特性的自動化架構。calm技術的一個自然的延伸就是使用雲計算技術,“按需”提供這些自動化能力[48]。雲托管服務對于傳遞企業軟體的機構(在生命周期的峰谷時基礎設施的靈活性,盡可能廣泛地開放供應鍊)和供應商(無需昂貴的基礎設施投資就可以輕松通路他們的服務)來說都有優勢。
轉向雲托管服務的趨勢,催生了越來越多的“軟體即服務”産品,作為提供軟體工廠能力的一種方式[49]。例如,在軟體測試中,許多系統內建商和第三方公司紛紛宣布推出“雲端測試”的方法,讓企業軟體傳遞機構可以購買這些測試活動,比如将性能測試作為一種服務。機構無需投資于宏大的基礎設施,就可以在需要時利用雲基礎設施,對企業軟體系統按需求配置和運作各種負載測試。