專家視角看IT與架構
作者 Bruce Laidlaw and Michael Poulin 譯者 侯伯薇
軟件產業目前的狀態很混亂，開發成本越來越高，質量卻越來越差。云計算所給出的承諾和具體實現還有相當大的差距： 最近，在Batler小組的討論會中舉行了一場題為“業務流程管理和面向服務的架構”的座談，得出的結論認為，只有公有云才是真正能夠節省成本的方法，但是它還不夠透明，中型和大型企業暫時還無法考慮把它作為節省IT成本的解決方案。當前在行業中有很多這樣的宣傳性的說法，但是它們能夠解決真正的問題嗎？ 真正的問題又是什么呢？
對于意識到軟件開發生產力缺乏的開發者，以及當前各家公司雇傭的大量技能較差的開發者，業界已經為他們發明了各種各樣的方法和工具，這使得業界的大環境中充滿了有很多需要學習的零散知識。人們真正想要得到什么呢？ 系統只是一種工具，用來幫助業務完成必須完成的任務嗎？ 或者系統不僅僅是工具？ 想要達到軟件的“天堂”，我們只需要選擇正確的工具和正確的方法嗎？ 為什么軟件開發看起來這么困難呢？
Bruce Laidlaw和Michael Poulin是兩位擁有超過30年經驗的IT專家，他們對IT的過去和現在做了比較，做出相關的結論，目的是要確定我們要做些什么才能繼續前進。Bruce曾經有過使用行業中幾乎所有方法和技術的經歷，并在各個級別上參與過，他所參與過的項目從開發費用幾千美元到三億美元的都有，甚至還有初始階段就耗費了20億美元的。他的經驗涵蓋了小家電公司、私營公司、英國政府、美國國家級、省級、地方級的機構，并且涉及到各個行業領域。Michael主要在大型軟件開發公司工作，另外還在大西洋兩岸的幾家主要財政機構的IT部門工作過。他專注于在跨功能和企業的層級上架設業務和和技術之間的橋梁，并為幾家全球性的標準制定機構工作。他的行業背景很豐富，包括多年數學算法開發、高級軟件設計和測試、分布式計算、面向服務以及開發治理等等。
Bruce和Michael在以下幾個方面對他們的經驗進行了提煉：
- 軟件產業的狀態
- 業務需求
- 架構師是業務和技術的粘合劑
- 在IT中我們如何做事
- 架構是保證交付的敏捷工具
他們從各自的角度對這些觀點進行了討論，目的是要明確做我們這行所要知道的知識，以及為了推動IT發展所要做的工作。
軟件產業的狀態
想要知道如何推動軟件產業，我們需要知道它當前的狀態，以及曾經的歷史。
Bruce
自從有了軟件產業，不管使用的方法和工具如何，我們都能夠創造出設計良好、構建合理的軟件。然而，同時也存在很多編寫得很糟糕的軟件，即便現在也是一樣。不幸的是，從過去到現在，大多數軟件系統都可以被歸到設計糟糕、編寫糟糕的那一類中。并且，我們不得不承認，當前開發的一些軟件也可以歸為糟糕的那類。
想要得出更客觀的觀點，我們需要跳出局外，并提出這樣的問題： 和30年前相比，企業使用購買或者構建的軟件，得到了什么好處嗎？ 我認為總體上的回答是沒有得到什么好處。以下是我所看到的當前軟件產業的特征：
- 高成本： 多年前只會耗費幾萬元的項目，現在要耗費幾百萬元。即便以現在的貨幣價值衡量，之前那些項目的成本也只是現在的一小部分。
- 低質量： 現在的軟件質量顯然并不比多年前好到哪去，盡管測試和“方法論”方面的“進展”試圖改變這種情況。
- 耐久性： 有一種說法認為，軟件系統只會持續五到六年，然后就會被替換掉，然而那只是一種神話，大多數企業仍然在使用二、三十年前開發的軟件。
- 技術： 在業界有人認為，和30年前相比，技術上已經有了很大進展。如果說的是硬件，那是毋庸置疑的，計算機越來越小、越來越快；然而對于軟件來說，肯定不是那樣。事實上，我們會看到，在總體上生產力正在下降。一些針對業務的革命性方法讓工作可以同時進行，從而減輕了這種情況。但是軟件并不是藝術品，只是工具，盡管有些不同的特點，但還是工具。
Michael
在過去的幾十年間，軟件在各個方面都有了發展： 從核電站的應用到影響了商業的社交化用戶論壇。比方說，30年前，我們需要為后花園制定藍圖而編寫程序嗎？ 我看沒人會那么做，也沒有什么必要，因為我們不認為那是軟件技術的職責所在——園藝這樣的工作沒那么嚴肅，不需要考慮在上面使用昂貴的計算機資源。現在，軟件無處不在，完成了各種不同的工作，任何單獨的例子都無法完整地描述它。
盡管如此，如果我們比較一下就會發現，以對財務行業建模為例，有了軟件系統之后，管理成本大大增加，同樣還消耗了更多資金。有些人把問題的原因歸于架構/設計和管理結構，我們正是使用這些方法來管理各種各樣的軟件開發項目的。然而，這些結構中的大多數都應該會提高軟件產品的質量。那么，在這樣的情況下，為什么我們看到的結果卻恰恰相反呢？ 我相信對此會有多種不同的解釋，而我也不想自稱能夠涵蓋主要的內容。我只是會指出一些我所能夠想到的方面：
- 一般軟件項目的規模和復雜度已經超出了軟件開發者的平均技能水平。例如，和多年前一樣，人們仍然對軟件項目持有兩種觀點： a) 我們需要交付能夠工作的東西； b) 我們盡自己最大的努力交付。然而，在很多情況下，“能夠工作的東西”和“最大的努力”并不是業務所需要的。IT項目需要更加專業化、為成功而付出的努力，這樣，就需要架構設計工作和對業務的分析工作能夠更好地彌補需求和技能之間的差距。
- 對簡單性提出的建議讓解決方案過于簡單了，而資源的限制則是主要的驅動因素。任何要做出的進一步改變都會導致原始的、雜亂的、意大利面式的代碼，他們把所有一切都耦合在一起，并導致接下來的項目成本居高不下。
- 能夠編寫程序的軟件工程師被批量地生產出來，他們知道如何編寫代碼，但是缺乏對企業中IT角色的總體概念，另外，對于為什么要編寫被要求編寫的內容也缺乏理解。
- 和批量生產程序員相關，人們還嘗試以制造業或者生產線的方式來管理他們的工作。然而，即便是最簡單的編程工作也要比生產線上的操作要復雜得多，但是人們依然故我。這種說法看起來與流行的精益開發和管理方法背道而馳，那是一種在IT領域實行的方法，而起源于日本的制造業。事實上，在軟件行業采用精益思想已經改變了最初的精益生產的概念，而且應用這些原則所能夠得到的好處還有待驗證。
- 軟件開發方法之前的目的是要滿足各位利益相關者的利益，而現在是要符合企業的需求。在很多情況下，人們會使用敏捷方法來安撫失望的利益相關者，另外，他還讓業務人員用愿望來代替業務需求。
- 在某種程度上，先進的代碼編寫工具也導致了軟件質量的下降。好工具值很多錢，如果你不是一個完美主義者，那么你會向CFO演示之前失敗的情況，只是為了證明需要花費這筆錢。同時，便宜一些的工具更原始，這讓程序員更可能只編寫簡單的代碼。簡單的代碼不總是正確的代碼（盡管正確的代碼總是很簡單），但是它非常適合交付“可以工作的東西”。也就是說，這樣的工具讓人們認為低質量的開發是“標準方法”。
- 海外外包也讓軟件的質量倒退了十年。為了盲目地追求海外外包的“經濟效益”，業務和IT的決策者把IT轉移到技術文化不成熟、對業務價值和IT在公司中的角色有不同理解（業務環境中文化也不同）的地區。盡管情況慢慢地在改善，但是本地開發者需要對海外團隊提交的交付物進行“改進”，這使得外包的成本大大增加。
- “我們會在明天把今天搞砸的部分修復。” 這種退化的項目管理哲學為人們在一些開發方法學中找到理論上的借口，他們堅持只實現給定的需求，而不關心將來的變更。如果業務部門允許自己被這種“低成本”的項目愚弄，那么他們就需要為擁有這樣的項目而付出沉重的代價（通常更高）。
理解自己企業中的業務
如果你在任意規模的一家公司的IT部門工作，那么你就需要定期問自己以下兩個問題： ““我在做什么？”和“為什么我要做這些工作？” 你的答案可能類似于“我做這些是為了我的薪水，所以我會做能夠讓公司支付薪水的工作。”，這么說沒什么不對，也沒有人會質疑你。盡管公司需要熱心人，但并非所有人都會是那樣。然而，如果你為一位雇主工作，且答案是“我想要創造出最棒的解決方案或者最整潔的代碼”，那么我們就需要談論一下了，因為這種動機通常會產生浪費。理想的方法應該這樣： “我想要創造出對業務有意義的代碼，并且能夠在不重寫代碼的前提下支持業務增長。“ 如果開發系統的人們不理解業務，也不努力去學習，那么你可能無法實現系統，也可能實現的系統會阻礙業務的發展。
Bruce
誰最了解你的業務？
大多數情況下，最了解業務的總體作用和愿景的是那些高級經理。那種愿景不會經常表現在企業的低級架構中。低級別的人員能夠更好地把握業務的過程以及目前業務是如何組織來完成它的愿景，但是他們無法理解為什么過程是那樣，或者什么時候應該對其做出改變。和小型企業相比，大型企業中尤其是這樣，但是，試圖理解業務是一項持久的挑戰。
有些方法學首先要讓業務分析師了解“當前的系統”，那可能是手工的過程，也可能是自動的，或者是二者混合的形式。誠然，通過了解當前系統，業務分析師能夠獲得一些關于業務的信息，但是更可能無法獲得，他們所能夠獲得的是你的業務當前的運作方式，那和它應該如何運作可能沒有任何聯系。一旦我們知道新系統的樣子，并且需要對變換做個計劃，這種映射當前系統的活動的作用就體現出來了，但是為了達到分析和需求的目的，這還有很多缺陷，并且可能會浪費大量的時間和金錢，并且從開始就可能為項目設定了錯誤的方向。
誰能擔當業務分析師的角色，捕獲業務知識呢？ 他們需要接受什么樣的培訓呢？ 想要有效地完成這項工作，他們需要擁有什么樣的技能呢？ 為了把工作做好，他們需要是行業領域的專家嗎？
在“過去”的日子里，新的IT從業者會經歷一系列的成長步驟，比方說像下面這樣：
- 初級程序員
- 程序員
- 高級程序員
- 程序員分析師
- 分析師程序員
- 分析師
- 業務分析師
我們知道，新的從業者可能已經擁有一些技術方面的技能： 某種喜歡的語言或者數據庫技術等等，但是在有效地應用這些技能方面，他們的能力還很“初級”。培訓中能夠讓他們提升級別的部分就在于，讓他們開始看模式，并了解業務人員是如何工作的。什么是總賬？ 什么是庫存系統？ 這兩個系統如何交互？ 通過這種在指導下的成長，他的計算機技能會得到鍛煉，對業務的理解會更敏銳，知識也會不斷增長。當一個人達到業務分析師階段時，他們不僅能夠完全理解一般的業務工作，而且能夠理解技術和系統如何為這些業務提供支持。
然而，在軟件中沒有“過去的美好時光”。曾經有很多問題，現在仍然會有同樣的問題。并非所有公司都有前瞻力和耐心，能夠管理他們的IT員工的成長過程，并且所有正常的人性弱點都會阻礙讓正確的人做正確的工作。
然而，當他們那么做時，就會起到非常好的作用。
現在，上面的七個級別只剩下兩個了，兩個相互沒有關聯、規則不同的級別，也就是“程序員”和“業務分析師”，各種“程序員”之間已經沒有區別，不管擁有一年經驗還是二十年經驗。對于“業務分析師”也一樣，你或者是，或者不是，與經驗無關。這樣的缺點在于，經常會由一些初級的人員負責控制昂貴項目的產出。
另外還有一個事實，盡管能夠勝任的架構師對于組件是必要的，但分析師卻并非充分條件。有些人擁有二十年的經驗，但看起來卻像是只有一年經驗。（我認為，在項目最初的階段中，合格的架構師會起到業務分析師的作用，然而業界已經把“業務分析師”從架構師小組中剔除，也不需要他們擁有做架構師所需要的經驗和深度。因此，我寧愿把他們稱之為“主管業務分析師”，這里的主管意味著他們本質上也是架構師。）
那么，好的業務分析師或者架構師有哪些特征呢？ 以下是我的觀點：
- 他們已經做過很多行業領域的項目
- 他們確實親自構建和成功地實現了系統
- 他們能夠對概念進行思考，能夠快速識別一種業務與其他業務之間的相似點和模式。
- 他們都能夠快速地學習，并且能夠與人清晰地溝通，在很短時間內了解你的業務是什么；可能比你的員工還要好。
- 當你解釋業務是什么、需要什么的時候，他們能夠很快把握重點。
最后，我要提出一個問題： 誰知道你的業務需求？ 是客戶、業務用戶或者擁有者，還是應該準確表達系統需求的人？ 他們都經過系統架構師或者分析師的培訓嗎？ 不。業務用戶最擅長描述業務是什么樣的，以及想要獲得某些信息，他應該做些什么。他們甚至能夠表達他們認為一切是如何運轉的，但是那只是從建議的角度提出的需求。其實是（也應該是）業務分析師/架構師才能夠最好地把針對業務用戶的業務需求“系統化”。
當前很多方法學都在這里出了問題，導致很多系統最終失敗了。我不止一次聽到構建系統的程序員們抱怨，客戶沒有準確地表述他們的需求。很遺憾，伙計們，客戶的工作不是要產出需求，那是你的工作，我的分析師朋友們。分析師必須擁有這樣的技能：傾聽業務的講述，然后從那些談話中挖掘真正的需求。在沒有真正分析，而且信任關系是通過管理手段構建的情況下，如果分析師說他“明白”的時候，業務人員就會強迫分析師接受自己的看法。不幸的是，這樣做的風險非常大。他們能夠得到所要求的，但是并不是所需要的。
Michael
多年以來，IT始終沒有確定或者說是在忽略業務的角色。IT人創建了一種信念，他們更知道應該為業務做什么和怎么做。即便是在集中的IT中，開發者也只把眼光放在眼前的項目上，比方說，他們的同事做了什么，而一些軟件開發方法把關注點只放在交付某些功能。當業務和技術之間的橋梁幾近崩塌，IT就會開始談論靈活性，說業務對問題一點都不理解。
我是經過了過去十年間參與面向服務的解決方案的工作，才發現了這個問題。我看到，盡管我告訴很多公司SOA具有強大的交付靈活性，但是他們還是在剛剛起步就失敗了。我知道他們之所以失敗，其中主要的原因不僅僅是IT對SOA產生了誤解，而且在于IT在提供以服務為中心的解決方案時，試圖讓業務以過程為中心。換句話說，IT對業務如何運轉做出響應，而不是對業務應該如何運轉做出響應。
在很多行業中，IT已經從工具開發者的角色轉換為解決方案開發者，那其中會包含業務解決方案的開發。然而，為了產出正確的解決方案，IT需要知道正確的業務任務或者業務需求。當處理主要由低級別的運營業務團隊提出的問題時，IT會鎖定這個級別業務人員的問題（大多數情況是那樣），然而，這個級別的人員反應的都是過去的業務需求。事實上，低級別的運營業務過程只不過是對功能的業務實現，并且，隨著時間的推移，這些過程會與當前的需求以及公司的目標脫節。
想要達到業務敏捷，IT需要知道業務的發展方向，還要知道業務計劃在將來如何發展，然后再相應地對軟件開發做出調整。在IT中對業務變更做出調整會比在業務中花費更長的時間，因為在代碼中存在很多隱藏和缺少文檔描述的依賴關系，并且還有在不關聯的應用程序之間共享的重要程序庫，一項變更可能會產生很廣泛的影響，這樣，在業務用戶可以重新使用之前，都必須對程序進行重新平衡，讓它變得足夠穩定才行。這意味著IT需要比中層和底層業務運營單位更了解業務所期望的改變。過去十年中的經濟動蕩使得IT無法培養出理解業務的軟件專家。這意味著IT再也無法依賴于在技術團隊中所能夠正常學習到的業務知識；IT需要有一些專注的人員，他們不得不與業務一起工作。這些人員兼任了架構師和業務/系統分析師的角色。
所以，IT架構師和業務/系統分析師需要和中層到高層的業務人員緊密合作，以了解他們的意圖和方向，一方面要為現存的業務提供指引，另一方面要提供新的技術能力。這項工作無法在一個項目接一個項目的情況下完成；它或者要作為完整工作職責的部分完成，或者是在全局項目的范圍內完成。也就是說，IT需要跨當前和將來的項目，擁有一個由架構師和業務/系統分析師組成的組織。在外包或者經常有臨時工的情況下，架構師和業務/系統分析師才是企業中最重要的IT財富，而不是經理。如果你讓IT中的業務知識減少了，那么就是對IT的大腦做了損害。那樣的話，你需要和沒有大腦的IT一起工作了……
遵循這種邏輯，讓我再向業務更進一步。顯然，中層和高層的業務人員沒有時間（或者沒有意愿）幫助IT解決問題。理解這樣的事實，會讓我們做出把業務架構師的機構和業務合并的決定。業務分析師實際上會負責對實現戰術上和戰略上的業務任務進行管理，業務架構師會和他們一起處理最高級別的業務計劃，識別業務需求，構建業務架構，并為了實現業務任務對其進行描述。業務架構師還會與IT管理者和技術架構師交互。這意味著業務部門中的業務架構師和業務分析師會負責構思核心業務需求。最終，這些需求會在業務單位和IT之間切分。
根據我的經驗，以及我的同事們的實踐，我知道在某些情況下，業務需求是從不同的低級業務過程的主觀需求中提取出來的，并且陷于其中無法自拔，最終這些業務需求會耗費掉IT所有的資源。我認為對于這種問題只有一種緩和的解決方案，所有想要傳遞給IT的業務需求需要經過某種形式的業務驗證，根據業務策略和部門的計劃來檢驗，并且進行驗證的人員應該是業務部門中的業務架構師和業務分析師。我見證了這種方法，它很有效，當IT推動了對業務需求的業務驗證，他們也會得到越來越多的尊重。
現代企業中架構師的角色
在過去的幾年間，人們普遍認為，在爭論之前要在語義上達成統一。因此，對于這個討論，我們都認為架構（軟件、業務、技術、硬件等）都是依據IEEE 1471標準定義（而不是描述）的。我們只能向IEEE 1471標準中添加組成架構的元素
- 它們必須是基本的、能夠自給自足且連貫的
- 它們能夠不依賴其他元素存在（例如，不能是從其他元素衍生的）
- 它們應該提供架構元素視圖（從內向外），而不是由視圖來提供架構元素（由外向內）。
我需要對最后一句話加以解釋。不管是誰在看，也不管是從哪里看（查看的角度如何），事物的所有視圖都會有誤解的風險，無法真實反映該事物，因為 1) 它是主觀的；2) 它不知道事物的邊界，也無法把環境的一部分作為事物的一部分來考慮。相反，對事物的視圖是基于實際的知識獲得，那些知識是與所有外部利益相關者的興趣相關，并且會考慮如何才能夠生成持久的視圖。
盡管架構的概念相對清晰，但我們還是無法認為架構師的角色也同樣清晰。在業界中還沒有一種標準來定義架構師的特征，兩種主要陣營之間的意見截然不同。一種認為架構師是超級技工，他能夠熟練地掌握一些或者所有最新的技術。這樣的架構師被稱為.Net架構師或者JEE架構師，等等。
另一個陣營認為，架構師的技術性要差一些，他應該更關心“系統科學”和方法，那與自動化本身沒有任何關聯。這場討論的結果認為架構師應該是后者的樣子，但是因為有多年的技術經驗，他也應該是很不錯的技術專家。我們在上面提到“技術性稍差”，意味著架構師是知道為什么（why），何處（where）和何時（when）的人，例如，需要在解決方案中使用消息機制；從架構角度來說，不管是廠商開發的消息機制還是自己開發的消息機制，都不重要（盡管從實現和管理的角度，那是非常重要的）。這種架構師不會是前衛的技術專家，但是他能夠勝任溝通業務和技術兩伙人的工作。在這種情況下，超級技工指的是軟件工程師或者技術主管，而不是架構師。
Bruce
現在各種職位的稱謂已經被濫用了，所以我在猶豫是否可以說最好的業務分析師就是系統架構師，但是如果那些人是通過經驗和技能獲得他們的技藝，那么架構師通常是擁有經驗和洞察力的人。在那種情況下，業務分析師的角色是由架構師擔任的，那比創建架構的優先級高。在兩種情況下，負責業務分析工作的人都應該符合已經列出的條件。
當業務需求已經表述清楚時，業務團隊中所有閱讀需求的人都應該對其很清楚，而且那就是所要求的內容。需求不會說明如何設計，盡管需求能夠強調設計中的一些方向以供考慮。例如： 如果管理的愿景是為客戶提供自我服務的門戶，那么需求這樣描述就很合適了。然而，指定用戶號是20位數字和字符，其中帶有分隔符，這就不是一個業務需求，這只是某人的主意，從而可以更好地追蹤客戶，最好能夠根據經驗來設置這些內容。
如果一家企業的IT部門能夠理解一致戰略的的需求，從而符合業務的需求，那么它就會投資創建包含有業務活動模型和業務信息模型的業務架構。這些模型與自動操作無關，而是會根據業務需要做什么、業務需要什么樣的信息來捕獲業務的本質。如果存在這些模型，那么所有系統項目就有了堅定地基礎，并在總體的戰略中擁有屬于自己的位置。
如果沒有這種戰略，也沒有這些模型，那么系統項目就不得不在時間和預算允許的范圍內做最大的努力。如果員工能夠了解企業的愿景，那么這種方法會生效，使得企業業務架構會慢慢增長。不幸的是，這種情況很少發生。這種情況下所能夠期望達到的最好結果就是，對系統和標準來說冗余的部分之間不會有太多沖突，或者需要設置昂貴的數據整合過程來修補數據和過程之間的脫節。
總之，只有當合格的業務分析師和架構師能夠與企業中理解業務的遠景和方向的人緊密合作，才能夠透徹地理解業務需求。通過這種合作，我們會得到連貫且有用的需求文檔，它會為你的業務服務，不僅僅是為當前的系統項目，也會對將來所計劃的業務需求起到作用。
Michael
近來對架構師的地位和角色的討論逐漸升溫。一些企業中的經理還是無法接受，在項目中架構師的地位要比業務分析師高。同時，企業架構機構和相關的架構師越來越多地占領了傳統的業務領域。
技術架構師已經把結構合理性和規范的邏輯引入到業務操作中，它是構建在個性化很強的人與人的交互和關系上的。這可能對于某些業務活動很好，但并非對于所有都是那樣。自動化和形式化的機械應用程序對有形的價值鏈方法學肯定有效，但人不是機器。忽略了價值網絡中無形的、面向交互的價值，使得業務和技術更難以實現革新，從而革新會更慢，成本會更高。
然而，與業務架構師緊密合作，不僅對IT架構師有利，而且對企業本身也有利。這樣的合作在業務和IT的邊界上生產力并不高，因此需要新的組織形式。業務和技術企業架構都有責任保護整個企業，那意味著唯一符合該任務的組織形式就是跨功能、跨部門的團隊，其中業務和技術企業架構師能夠協同工作。和單獨的業務和IT部門以及海外企業級別的項目中的權威相比，這種團隊的權威與之同級或者更高一些。
企業架構位于組織中架構功能層級機構的頂端，該結構中會依次把所有單位和部門（業務和技術部門）都包含到每個開發項目中。依照協作的業務戰略計劃，架構師會定義在組織的各個層級所需要完成的任務。然后，公司的管理層會負責如何根據自身的情況來實現架構上的決定和解決方案。這意味著，當項目經理設定項目的時候，相關的架構師會確認他們合適地設置了并解釋了項目的目標和方法。
技術、業務和系統分析師都會完成自己與業務相關的工作，這是通過找到需求細節和依賴關系，并編寫相關文檔來完成的。技術、業務和系統分析師并不是“擁有企業洞察力的員工”，而只是專注于特定的項目需求。其他項目所做的工作，以及它們（在實現上）是否重疊通常不在他們的考慮范圍之內。這樣，他們經常會依賴于業務需求，那只是由技術、業務和系統分析師搜集獲得；IT有很大的風險，可能會轉向錯誤的方向，因為他們很容易就會忽略重要的依賴關系。不幸的是，我們看到這種情況經常會發生。
我堅信所有業務想法、建議、明確表述的需求和任務都是需要IT來實現的，而支持和集成工作在引入到IT之前，需要業務對其進行檢驗和驗證。業務架構師和業務部門中的業務分析師需要共同組成一個管道，對進入到技術部門的需求進行控制。技術架構師會把業務需求轉換為架構解決方案，并把它們傳遞給技術、業務和系統分析師來豐富細節。
因此，這個管道會以如下的方式運作：
- 業務請求者對業務需求進行表述
- 業務架構師和分析師審核需求，看它是否符合策略性業務計劃和公司的目標。
- 業務架構師和分析師會分析實現這個需求對周圍的業務執行環境的影響和反作用。
- 如果所有人都批準，那么需求會被傳遞給IT架構師，他會根據需求來考慮IT的能力，并向業務反饋解決方案的概要。
- 如果IT解決方案在某種程度上影響了業務需求（例如，做了某種程度上的優化），那么就會通過迭代的過程達到最終的意見。
- 大家達成共識的需求會被明確表述為核心業務需求，并傳遞給IT部門。
- IT架構師和系統分析師會分析其中的細節，并產生出業務和技術上的需求，以便在IT部門中進行細節的設計和實現。
這是一種普遍的業務需求構建過程，可以應用在所有行業和企業中。這個過程非常適合業務和IT的治理，以及相關的質量控制。我認為，在所有營銷高峰中，實現得不合適的IT產品會造成很大的利益損失，這凸顯出用來定義真正的業務需求所付出的努力和時間是值得的。
構建“好”/“壞”系統的過程
Bruce
假設我們已經找到了合適的人，上述的需求也已經獲取完畢，我們就能夠保證擁有更好的系統嗎？ 有可能會，也可能不會。
如果已經獲取了良好的需求，那么和沒有獲取良好的需求的情況相比，我們更有機會創造出好系統，所以從那個角度來看，情況要好一些。但是，還是有很大的可能會失敗。
Dr. Paul Dorsey的一份報告強調了保證項目成功最主要的三種要素：
- 高級管理層的支持
- 合理可靠的方法
- 由已經成功完成類似項目的人所領導的技術
很有趣的是，這與“過程”是什么樣的無關——換句話說，開發的風格并不是問題。那么這種管理承諾的失敗在何處明顯體現了呢？
看起來，當項目開始的時候，管理層通常會缺乏分析的耐心。現在有種流行詞叫做“分析麻痹癥”，并且經常會為了得到“產出結果”而犧牲分析的時間，似乎設計根本就是在浪費時間。我曾經和技術能力很強的團隊一起工作，他們最終沒能成功交付項目，只是因為管理層沒有讓他們做該做的工作。不幸的是，IT業界讓初級的員工來做超出他們經驗的工作，從而造成了這種形勢。作為響應，很多方法認為規避問題的方法就只是不做分析。問題就解決了！ 可能是吧。
在討論的最初階段，有人聲明，不管是在成功還是失敗的項目中，使用的方法都不是決定性因素。如果堅持這種看法，那么極限編程、敏捷、Rational統一過程等方法本身都不會讓事情走上正軌。這些方法所做的就是，試圖調節被破壞的過程，在壞形勢下獲得最好的結果；并且，這些方法的確使得情況有了一定程度的改善。不幸的是，如果通過合格的設計溝通出業務需求，開發者又能開發出什么呢？ 這些方法把業務人員放在開發者中間，期望隨著他們一起工作來構建系統，需求就會逐漸顯現出來。如果業務人員非常了解企業和它的愿景，那么這會很有效，但如果不是那樣的話，就不那么有效了。人們必須了解總體上系統會變成什么樣子。那并不是說要在做任何工作之前把整個愿景描述清楚，愿景可以慢慢改進，只要負責愿景的人（架構師）能夠勝任這項工作，并且知道他的設計是要做什么。
問題是，什么因素讓系統對業務來說“好”或者“壞”呢？ 誰來判斷好壞，這是一種黑白分明的判斷嗎？
事實上，不管一個系統的構想有多糟糕，至少都會完成一部分它想要做的事情。和最初就計劃好目標相比，這可能需要更多的資金和時間，但是大多數系統都以某種方式達到了目的。不幸的是，構想很差的系統無法確保業務能夠增長，也無法隨著時間的推移滿足業務的需求。
在此，我把“好”系統定義為能夠滿足業務需求的系統，它讓業務能夠隨著時間的變化靈活地改變，并且用戶會認為系統能夠很好地支持業務。
相反，我對“壞”系統的定義是在某種程度上完成某些或者所有業務需求的系統，但是完成的方式會阻礙業務在將來的改變和發展。
Michael
我對“好的”技術系統的解釋與運行環境（業務和技術）緊密相關。我發現，在繁榮的時期，在外部業務環境中發生的業務變化要比蕭條的時期少。據此我們可以認為，業務會為相同的技術系統設置不同的期望和需求。例如，在90年代末，在美國，系統的可伸縮性和性能是主要目標；而現在，優先級最高的是系統的靈活性/可擴展性和安全性。
現在業務的靈活性需要技術解決方案足夠靈活，我們只需要對系統變更做最小的投資，對周圍系統調整作最小的投資，就能夠適應業務的變化，并且所有工作都應該在最短的時間內完成（這就是我所定義的系統靈活性）。這與過去“實用的”實踐形成了鮮明的對比，那種實踐宣揚給定的需求必須明確地發布，不要給修改和替換留余地，好像將來不會有任何變更。
在IT部門實現業務需求的正常流程經常會被破壞，而那并不一定是IT的過錯。IT創建并且繼承了很多舊的遺留系統，其中有大量不定和“意大利面式”代碼。如果業務想要快速推進，那么就需要修復IT資產，使得它們更靈活。這項工作需要大量時間和資金，但這兩樣往往都很缺乏。云計算和外包對此不會有什么幫助，因為IT中舊的遺留系統中有很多公司財富——知識、邏輯和數據，并不適合外包。
引用Forrester研究公司的話，我們可以說“你的業務只能和你的技術以同樣的速度變化”。因此，“好”系統就是靈活的系統，當前很有用，并且考慮到了將來的擴展性。在“敏捷說法”中，“好”系統會滿足每天活動的業務需求，并且根據業務策略計劃平滑地轉換。
IT發明了一種又一種敏捷方法，目的就是為了構建出好的系統。敏捷方法的主要部分都是基于這樣的假設：業務不能也不會以與今天不同的方式工作；這些方法不敢挑戰業務的工作方式，即便這種方式對于企業來說會降低生產力。這會導致這樣的趨勢：敏捷開發者主張簡單的設計，其中很少涉及未來的架構和設計，或者根本不涉及。 實際上，開發團隊負責依據業務需求交付軟件，而軟件的業務價值與團隊是無關的： “如果業務想要這種方式，那么他們應該知道那是什么，也知道為什么要那么做。”
我們經常會遇到這樣的情況，敏捷團隊承諾稍后會添加錯誤處理機制、調整、通知/警告、補償邏輯、事務完整性、安全性以及操作穩定性等等，并把它們放在接下來的“時間表”中。然而，所有這些技術功能都是IT所關心的；它們是業務部門期望從技術部門立刻得到的服務質量（QoS）特性，而不是要拖延到下次。業務邏輯很簡單： “如果軟件已經有效地運行，（哦，真的嗎？）為什么要等待更長時間才能得到最終的發布版本，并投入更多資金呢？ 相反，既然IT已經做得很好了，那么讓他們做其他任務吧。”
讓我們回到精益方法學，在此重新回顧一下大野耐一所描述的真正的精益生產原則，這非常重要：
- 只構建我們需要的
- 如果出問題了就停下來
- 去除所有不產生價值的工作
不可否認，這些原則都非常合理，可以很容易地在生產環境中對其加以解釋，在那種環境中我們可以完整地定義和指定最終的結果。然而，當Mary Poppendieck和Tom Poppendieck描述精益項目管理方法的七項原則時，他們在很多地方已經脫離了精益生產的本意。
比方說，讓我們來看一下精益方法在面向服務的情況下如何起作用，在其中精益團隊會構建一項SOA服務。因為人們集中關注于精益原則“消除浪費”，因此那成為團隊的首要任務。順便說一下，消除軟件開發中的浪費是一項非常有挑戰的任務，要比生產行業中難得多，因為在所有的業務需求中都會有很多不確定的因素，而架構的愿景無法在其中反映出來。那么，如果我們討厭并且忽略了將來的架構設計，我們如何才能判斷出什么是浪費，什么不是浪費呢？
在SOA中，所有服務都可能被用戶使用到，而最初請求服務的人（構建服務也是基于他的需求）可能很快就會被大家忘掉。SOA服務必須為未知的用戶（或者使用精益術語，客戶）服務。每個客戶都能夠在服務中找到屬于自己的價值，而這個價值與開發團隊所要達到的目標可能會截然不同。這是說生產行業中定義的浪費無法適用于面向服務的開發嗎？ 或者說，沒有健壯的架構設計，它可能無法適用于所有軟件開發中……
另一項精益原則——“延遲交付”，這在概念上與“消除浪費”是相互矛盾的。我們可能會延遲交付。比方說，延遲完成對產品的實現，因為我們認為我們的任務中某些業務會發生變化。如果我們認為會發生變化，但是又不知道會發生什么樣的變化，那么如何才能夠識別出浪費呢？對于即將發生的變更來說，一項工作可能是浪費，而另一項可能會是非常有用的特性。我想那就是面向服務的規則——“為變更而設計”——那會比延遲交付更有效。
還有兩項原則：“內建質量”和“整體優化”，這可能與“為團隊授權”原則矛盾。我們認為精益團隊應該專注于特定的任務，那樣就很難發現“整體”。并且，創建于IT中其它不在項目范圍內元素的完整性就更難了。這兩項原則都應該屬于跨團隊的架構職能，而不是屬于開發團隊；應該是有了架構之后才能夠定義浪費。
最后，我覺得“為團隊授權”這條原則很有意思（而不是為管理層授權），它被添加到IT精益方法中，而最根本的原則“如果出問題就停止”卻被排除在外。這意味著在開發中只有“大晴天”，所有的執行情況都是可以預料的嗎？ 沒有停止原則，為團隊授權之后，精益項目經理就缺少后退的機制。也就是說，他們會持續交付所有可以提供的內容，包括浪費。這樣，結論只能是以下兩種之一： 或者IT精益方法的基礎還不成熟，或者說它又是一種錯誤的方法。
我們能做得更好嗎？
Bruce
在本次討論中我們說的是：
- 方法不是成功的決定因素
- 業務需要一種業務架構
- 業務應該指定需求，架構師/分析師應該指定需求的系統化實現。
- 管理層需要選定一種方法并為其提供持續的支持
- 我們可以根據系統支持業務的能力來評定它的好壞
我們怎樣才能達到這樣的目標呢？ IT業界歷史上殘酷的現實是，你不可能總是可以找到最好的人，所以需要讓缺少經驗和能力的人來完成工作。我們還有希望實現產出好系統的夢想嗎？ 我相信有。
如果有清晰表述的良好業務架構，那么對于獲取需求就有了堅實的基礎。如果有構建在那種業務架構上的堅實的應用程序架構，那么項目的規范就能夠以可控和漸進的方式完成。
如果創建了合理的架構實踐和指南，并且明確表述了高級管理層支持的企業愿景，那么其他的事情就會落到實處，并且不會過分依賴于項目團隊的經驗和技能，這只是因為已經定義了堅實的框架，他們可以在其中工作。這并非是完美的方法，但這是我們所面對的現實情況。
我們可以提供這些“可能的”部分，而不需要花費多年時間嗎？
如果我們能夠找到正確的人來為業務建模，那么他就會很快把模型建立起來。不管是什么樣的業務部門（政府、制造業、軍隊等等），由兩位建模人員組成的團隊共同協作，就能夠很快地捕獲到活動和信息的模型。在中型和大型企業的環境中，六個月的項目就應該足以滿足需求。
根據高級管理層的愿景和方向的不同，對應用程序架構的調查可能還需要兩到三個月。所需要的時間期限是主觀的，并且嚴重依賴于組織的文化以及企業忙于處理遺留應用程序的程度。
意識到上述討論的問題，可以讓我們獲得更好的、更具有持續性的開發項目。另外，還有一種好處就是可以把業務從多年來實現得很差、冗余的系統中解放出來。
上述的應用程序架構包含了所有當前在企業中使用的應用程序，還有這些應用程序如何幫助或者阻礙業務的真實需求的評估。當檢查這些系統時，如果能夠更關注于業務需求，那么我們就有更大的機會基于功能和數據對其進行整合。減少應用程序的數量，不僅能夠降低運營成本，而且通過提供更可靠和及時的數據，會為企業帶來更大的好處，并且開發環境的響應更及時，從而滿足業務變更所帶來的挑戰。
Michael
我關于這個問題的回答是“是的，IT能做得更好，但是光憑IT自身不行”。IT需要在以下方面把業務部門涉及進來：
- 做所有與技術解決方案相關的決定
- 根據業務策略檢查自身的能力
- 合并開發和運維的費用
- 評價生產出來的技術系統
這樣的動作能夠讓業務對他們的需求和選擇負責。
當技術架構師提出一些可選的要實現解決方案的建議時，客戶和利益相關者需要知道，如果他們選擇了費用最低但是沒有考慮到將來的解決方案，那么他們就需要對這個決定負責，而不是由IT來負責。我已經看到過很多這樣的情況，在開發時費用最低的解決方案，在維護時會耗費大量的金錢。我們應該如何來平衡呢？ 很容易，業務和IT需要把成本作為選擇技術解決方案的目標。而不能由某個部門單獨來決定項目或者開發成本的目標。
當IT檢查技術能力的時候，經常會發現平臺陳舊，如果不報廢的話，可能再也得不到廠商的支持。這樣的平臺能夠對業務策略目標和目的起到應有的作用嗎？ 答案是，很可能不會。那么，IT需要公開說明，現在的系統已經無法支持策略性的業務需求，我們可以說明一下，擁有現存的解決方案需要付出大量的維護成本，那已經占據了IT預算的主要部分，而沒給策略性開發留下多少。
當開發出新的解決方案、產品或者系統時，它需要經過將來使用它的業務用戶的審查。傳統的用戶接受測試只會檢查業務功能。與之相比，業務審查需要檢查IT產品在所有異常或者非標準的業務情況下的響應，比方說，可伸縮性需要在真實的環境中演示，而不是在專門的測試系統中。如果系統通過了審查，它會存活得很好；如果沒有，可能就要對一些業務需求進行修訂。在任意情況下，IT都需要和業務部門一起重新設置業務的期望，并以合作和積極的方式來確定改進的方向，而不是忙于正式環境中的報告和缺陷。
IT能夠如何更多地讓業務參與進來呢？ 可能我并不是最早這么說的： a) 支持和改進業務中業務架構師所提出的想法， b) 支持和改進跨業務和技術的企業架構、由業務和技術架構師共同制定的想法，c) 設置定期的會議，可以讓在相同業務領域中工作的業務和技術團隊的業務架構師來交換意見，d) 在IT部門中創建總監級別的結構，它會直接與業務管理層協同工作，作為了解所有想要讓IT做的業務需求的管道，e) 創建跨項目的分析小組，他的責任是要分析低級和中級的業務運營過程，并基于技術能力得出優化建議，也就是讓IT更積極。
我發現，在技術治理中還有一種IT可以改進的方面。我實際上指的是，技術治理包括所有架構、開發、數據/信息和管理的治理領域。這種治理不僅僅是關于什么是什么，而且還涉及到在開發和測試中所能夠使用的技術。這種治理涉及到的方面包括對開發在架構上和設計上的控制，開發和測試的工具和方法論，項目管理方法，以及現存和“正在開發”的系統、產品和解決方案之間的協作。治理手段需要覆蓋IT在端到端業務開發所涉及的內容，確定解決方案所有權的目的，以及在IT和業務之間的SLA中所定義的責任。治理無法用管理來替代。治理要說的是，當管理層要執行治理策略時，應該做什么事情，以及事情應該怎樣做。如果治理策略是由IT管理層來維護的，那么讓具有獨特權力的治理人員來指導IT整體上的功能，就有可能獲得針對業務合理的靈活性。
留言列表
