中文字幕在线观看网站,国产成人免费观看,色狠狠色狠狠综合天天

　　作者 Bruce Laidlaw and Michael Poulin 譯者侯伯薇

　　軟件產(chǎn)業(yè)目前的狀態(tài)很混亂，開發(fā)成本越來越高，質(zhì)量卻越來越差。云計算所給出的承諾和具體實現(xiàn)還有相當(dāng)大的差距：最近，在Batler小組的討論會中舉行了一場題為“業(yè)務(wù)流程管理和面向服務(wù)的架構(gòu)”的座談，得出的結(jié)論認(rèn)為，只有公有云才是真正能夠節(jié)省成本的方法，但是它還不夠透明，中型和大型企業(yè)暫時還無法考慮把它作為節(jié)省IT成本的解決方案。當(dāng)前在行業(yè)中有很多這樣的宣傳性的說法，但是它們能夠解決真正的問題嗎？真正的問題又是什么呢？

　　對于意識到軟件開發(fā)生產(chǎn)力缺乏的開發(fā)者，以及當(dāng)前各家公司雇傭的大量技能較差的開發(fā)者，業(yè)界已經(jīng)為他們發(fā)明了各種各樣的方法和工具，這使得業(yè)界的大環(huán)境中充滿了有很多需要學(xué)習(xí)的零散知識。人們真正想要得到什么呢？系統(tǒng)只是一種工具，用來幫助業(yè)務(wù)完成必須完成的任務(wù)嗎？或者系統(tǒng)不僅僅是工具？想要達(dá)到軟件的“天堂”，我們只需要選擇正確的工具和正確的方法嗎？為什么軟件開發(fā)看起來這么困難呢？

　　Bruce Laidlaw和Michael Poulin是兩位擁有超過30年經(jīng)驗的IT專家，他們對IT的過去和現(xiàn)在做了比較，做出相關(guān)的結(jié)論，目的是要確定我們要做些什么才能繼續(xù)前進(jìn)。Bruce曾經(jīng)有過使用行業(yè)中幾乎所有方法和技術(shù)的經(jīng)歷，并在各個級別上參與過，他所參與過的項目從開發(fā)費用幾千美元到三億美元的都有，甚至還有初始階段就耗費了20億美元的。他的經(jīng)驗涵蓋了小家電公司、私營公司、英國政府、美國國家級、省級、地方級的機(jī)構(gòu)，并且涉及到各個行業(yè)領(lǐng)域。Michael主要在大型軟件開發(fā)公司工作，另外還在大西洋兩岸的幾家主要財政機(jī)構(gòu)的IT部門工作過。他專注于在跨功能和企業(yè)的層級上架設(shè)業(yè)務(wù)和和技術(shù)之間的橋梁，并為幾家全球性的標(biāo)準(zhǔn)制定機(jī)構(gòu)工作。他的行業(yè)背景很豐富，包括多年數(shù)學(xué)算法開發(fā)、高級軟件設(shè)計和測試、分布式計算、面向服務(wù)以及開發(fā)治理等等。

　　Bruce和Michael在以下幾個方面對他們的經(jīng)驗進(jìn)行了提煉：

軟件產(chǎn)業(yè)的狀態(tài)
業(yè)務(wù)需求
架構(gòu)師是業(yè)務(wù)和技術(shù)的粘合劑
在IT中我們?nèi)绾巫鍪?/li>
架構(gòu)是保證交付的敏捷工具

　　他們從各自的角度對這些觀點進(jìn)行了討論，目的是要明確做我們這行所要知道的知識，以及為了推動IT發(fā)展所要做的工作。

　　軟件產(chǎn)業(yè)的狀態(tài)

　　想要知道如何推動軟件產(chǎn)業(yè)，我們需要知道它當(dāng)前的狀態(tài)，以及曾經(jīng)的歷史。

　　Bruce

　　自從有了軟件產(chǎn)業(yè)，不管使用的方法和工具如何，我們都能夠創(chuàng)造出設(shè)計良好、構(gòu)建合理的軟件。然而，同時也存在很多編寫得很糟糕的軟件，即便現(xiàn)在也是一樣。不幸的是，從過去到現(xiàn)在，大多數(shù)軟件系統(tǒng)都可以被歸到設(shè)計糟糕、編寫糟糕的那一類中。并且，我們不得不承認(rèn)，當(dāng)前開發(fā)的一些軟件也可以歸為糟糕的那類。

　　想要得出更客觀的觀點，我們需要跳出局外，并提出這樣的問題：和30年前相比，企業(yè)使用購買或者構(gòu)建的軟件，得到了什么好處嗎？我認(rèn)為總體上的回答是沒有得到什么好處。以下是我所看到的當(dāng)前軟件產(chǎn)業(yè)的特征：

高成本：多年前只會耗費幾萬元的項目，現(xiàn)在要耗費幾百萬元。即便以現(xiàn)在的貨幣價值衡量，之前那些項目的成本也只是現(xiàn)在的一小部分。
低質(zhì)量：現(xiàn)在的軟件質(zhì)量顯然并不比多年前好到哪去，盡管測試和“方法論”方面的“進(jìn)展”試圖改變這種情況。
耐久性：有一種說法認(rèn)為，軟件系統(tǒng)只會持續(xù)五到六年，然后就會被替換掉，然而那只是一種神話，大多數(shù)企業(yè)仍然在使用二、三十年前開發(fā)的軟件。
技術(shù)：在業(yè)界有人認(rèn)為，和30年前相比，技術(shù)上已經(jīng)有了很大進(jìn)展。如果說的是硬件，那是毋庸置疑的，計算機(jī)越來越小、越來越快；然而對于軟件來說，肯定不是那樣。事實上，我們會看到，在總體上生產(chǎn)力正在下降。一些針對業(yè)務(wù)的革命性方法讓工作可以同時進(jìn)行，從而減輕了這種情況。但是軟件并不是藝術(shù)品，只是工具，盡管有些不同的特點，但還是工具。

　　Michael

　　在過去的幾十年間，軟件在各個方面都有了發(fā)展：從核電站的應(yīng)用到影響了商業(yè)的社交化用戶論壇。比方說，30年前，我們需要為后花園制定藍(lán)圖而編寫程序嗎？我看沒人會那么做，也沒有什么必要，因為我們不認(rèn)為那是軟件技術(shù)的職責(zé)所在——園藝這樣的工作沒那么嚴(yán)肅，不需要考慮在上面使用昂貴的計算機(jī)資源。現(xiàn)在，軟件無處不在，完成了各種不同的工作，任何單獨的例子都無法完整地描述它。

　　盡管如此，如果我們比較一下就會發(fā)現(xiàn)，以對財務(wù)行業(yè)建模為例，有了軟件系統(tǒng)之后，管理成本大大增加，同樣還消耗了更多資金。有些人把問題的原因歸于架構(gòu)/設(shè)計和管理結(jié)構(gòu)，我們正是使用這些方法來管理各種各樣的軟件開發(fā)項目的。然而，這些結(jié)構(gòu)中的大多數(shù)都應(yīng)該會提高軟件產(chǎn)品的質(zhì)量。那么，在這樣的情況下，為什么我們看到的結(jié)果卻恰恰相反呢？我相信對此會有多種不同的解釋，而我也不想自稱能夠涵蓋主要的內(nèi)容。我只是會指出一些我所能夠想到的方面：

一般軟件項目的規(guī)模和復(fù)雜度已經(jīng)超出了軟件開發(fā)者的平均技能水平。例如，和多年前一樣，人們?nèi)匀粚浖椖砍钟袃煞N觀點： a) 我們需要交付能夠工作的東西； b) 我們盡自己最大的努力交付。然而，在很多情況下，“能夠工作的東西”和“最大的努力”并不是業(yè)務(wù)所需要的。IT項目需要更加專業(yè)化、為成功而付出的努力，這樣，就需要架構(gòu)設(shè)計工作和對業(yè)務(wù)的分析工作能夠更好地彌補(bǔ)需求和技能之間的差距。
對簡單性提出的建議讓解決方案過于簡單了，而資源的限制則是主要的驅(qū)動因素。任何要做出的進(jìn)一步改變都會導(dǎo)致原始的、雜亂的、意大利面式的代碼，他們把所有一切都耦合在一起，并導(dǎo)致接下來的項目成本居高不下。
能夠編寫程序的軟件工程師被批量地生產(chǎn)出來，他們知道如何編寫代碼，但是缺乏對企業(yè)中IT角色的總體概念，另外，對于為什么要編寫被要求編寫的內(nèi)容也缺乏理解。
和批量生產(chǎn)程序員相關(guān)，人們還嘗試以制造業(yè)或者生產(chǎn)線的方式來管理他們的工作。然而，即便是最簡單的編程工作也要比生產(chǎn)線上的操作要復(fù)雜得多，但是人們依然故我。這種說法看起來與流行的精益開發(fā)和管理方法背道而馳，那是一種在IT領(lǐng)域?qū)嵭械姆椒ǎ鹪从谌毡镜闹圃鞓I(yè)。事實上，在軟件行業(yè)采用精益思想已經(jīng)改變了最初的精益生產(chǎn)的概念，而且應(yīng)用這些原則所能夠得到的好處還有待驗證。
軟件開發(fā)方法之前的目的是要滿足各位利益相關(guān)者的利益，而現(xiàn)在是要符合企業(yè)的需求。在很多情況下，人們會使用敏捷方法來安撫失望的利益相關(guān)者，另外，他還讓業(yè)務(wù)人員用愿望來代替業(yè)務(wù)需求。
在某種程度上，先進(jìn)的代碼編寫工具也導(dǎo)致了軟件質(zhì)量的下降。好工具值很多錢，如果你不是一個完美主義者，那么你會向CFO演示之前失敗的情況，只是為了證明需要花費這筆錢。同時，便宜一些的工具更原始，這讓程序員更可能只編寫簡單的代碼。簡單的代碼不總是正確的代碼（盡管正確的代碼總是很簡單），但是它非常適合交付“可以工作的東西”。也就是說，這樣的工具讓人們認(rèn)為低質(zhì)量的開發(fā)是“標(biāo)準(zhǔn)方法”。
海外外包也讓軟件的質(zhì)量倒退了十年。為了盲目地追求海外外包的“經(jīng)濟(jì)效益”，業(yè)務(wù)和IT的決策者把IT轉(zhuǎn)移到技術(shù)文化不成熟、對業(yè)務(wù)價值和IT在公司中的角色有不同理解（業(yè)務(wù)環(huán)境中文化也不同）的地區(qū)。盡管情況慢慢地在改善，但是本地開發(fā)者需要對海外團(tuán)隊提交的交付物進(jìn)行“改進(jìn)”，這使得外包的成本大大增加。
“我們會在明天把今天搞砸的部分修復(fù)。” 這種退化的項目管理哲學(xué)為人們在一些開發(fā)方法學(xué)中找到理論上的借口，他們堅持只實現(xiàn)給定的需求，而不關(guān)心將來的變更。如果業(yè)務(wù)部門允許自己被這種“低成本”的項目愚弄，那么他們就需要為擁有這樣的項目而付出沉重的代價（通常更高）。

　　理解自己企業(yè)中的業(yè)務(wù)

　　如果你在任意規(guī)模的一家公司的IT部門工作，那么你就需要定期問自己以下兩個問題： ““我在做什么？”和“為什么我要做這些工作？” 你的答案可能類似于“我做這些是為了我的薪水，所以我會做能夠讓公司支付薪水的工作。”，這么說沒什么不對，也沒有人會質(zhì)疑你。盡管公司需要熱心人，但并非所有人都會是那樣。然而，如果你為一位雇主工作，且答案是“我想要創(chuàng)造出最棒的解決方案或者最整潔的代碼”，那么我們就需要談?wù)撘幌铝耍驗檫@種動機(jī)通常會產(chǎn)生浪費。理想的方法應(yīng)該這樣： “我想要創(chuàng)造出對業(yè)務(wù)有意義的代碼，并且能夠在不重寫代碼的前提下支持業(yè)務(wù)增長。“ 如果開發(fā)系統(tǒng)的人們不理解業(yè)務(wù)，也不努力去學(xué)習(xí)，那么你可能無法實現(xiàn)系統(tǒng)，也可能實現(xiàn)的系統(tǒng)會阻礙業(yè)務(wù)的發(fā)展。

　　Bruce

　　誰最了解你的業(yè)務(wù)？

　　大多數(shù)情況下，最了解業(yè)務(wù)的總體作用和愿景的是那些高級經(jīng)理。那種愿景不會經(jīng)常表現(xiàn)在企業(yè)的低級架構(gòu)中。低級別的人員能夠更好地把握業(yè)務(wù)的過程以及目前業(yè)務(wù)是如何組織來完成它的愿景，但是他們無法理解為什么過程是那樣，或者什么時候應(yīng)該對其做出改變。和小型企業(yè)相比，大型企業(yè)中尤其是這樣，但是，試圖理解業(yè)務(wù)是一項持久的挑戰(zhàn)。

　　有些方法學(xué)首先要讓業(yè)務(wù)分析師了解“當(dāng)前的系統(tǒng)”，那可能是手工的過程，也可能是自動的，或者是二者混合的形式。誠然，通過了解當(dāng)前系統(tǒng)，業(yè)務(wù)分析師能夠獲得一些關(guān)于業(yè)務(wù)的信息，但是更可能無法獲得，他們所能夠獲得的是你的業(yè)務(wù)當(dāng)前的運作方式，那和它應(yīng)該如何運作可能沒有任何聯(lián)系。一旦我們知道新系統(tǒng)的樣子，并且需要對變換做個計劃，這種映射當(dāng)前系統(tǒng)的活動的作用就體現(xiàn)出來了，但是為了達(dá)到分析和需求的目的，這還有很多缺陷，并且可能會浪費大量的時間和金錢，并且從開始就可能為項目設(shè)定了錯誤的方向。

　　誰能擔(dān)當(dāng)業(yè)務(wù)分析師的角色，捕獲業(yè)務(wù)知識呢？他們需要接受什么樣的培訓(xùn)呢？想要有效地完成這項工作，他們需要擁有什么樣的技能呢？為了把工作做好，他們需要是行業(yè)領(lǐng)域的專家嗎？

　　在“過去”的日子里，新的IT從業(yè)者會經(jīng)歷一系列的成長步驟，比方說像下面這樣：

初級程序員
程序員
高級程序員
程序員分析師
分析師程序員
分析師
業(yè)務(wù)分析師

　　我們知道，新的從業(yè)者可能已經(jīng)擁有一些技術(shù)方面的技能：某種喜歡的語言或者數(shù)據(jù)庫技術(shù)等等，但是在有效地應(yīng)用這些技能方面，他們的能力還很“初級”。培訓(xùn)中能夠讓他們提升級別的部分就在于，讓他們開始看模式，并了解業(yè)務(wù)人員是如何工作的。什么是總賬？什么是庫存系統(tǒng)？這兩個系統(tǒng)如何交互？通過這種在指導(dǎo)下的成長，他的計算機(jī)技能會得到鍛煉，對業(yè)務(wù)的理解會更敏銳，知識也會不斷增長。當(dāng)一個人達(dá)到業(yè)務(wù)分析師階段時，他們不僅能夠完全理解一般的業(yè)務(wù)工作，而且能夠理解技術(shù)和系統(tǒng)如何為這些業(yè)務(wù)提供支持。

　　然而，在軟件中沒有“過去的美好時光”。曾經(jīng)有很多問題，現(xiàn)在仍然會有同樣的問題。并非所有公司都有前瞻力和耐心，能夠管理他們的IT員工的成長過程，并且所有正常的人性弱點都會阻礙讓正確的人做正確的工作。

　　然而，當(dāng)他們那么做時，就會起到非常好的作用。

　　現(xiàn)在，上面的七個級別只剩下兩個了，兩個相互沒有關(guān)聯(lián)、規(guī)則不同的級別，也就是“程序員”和“業(yè)務(wù)分析師”，各種“程序員”之間已經(jīng)沒有區(qū)別，不管擁有一年經(jīng)驗還是二十年經(jīng)驗。對于“業(yè)務(wù)分析師”也一樣，你或者是，或者不是，與經(jīng)驗無關(guān)。這樣的缺點在于，經(jīng)常會由一些初級的人員負(fù)責(zé)控制昂貴項目的產(chǎn)出。

　　另外還有一個事實，盡管能夠勝任的架構(gòu)師對于組件是必要的，但分析師卻并非充分條件。有些人擁有二十年的經(jīng)驗，但看起來卻像是只有一年經(jīng)驗。（我認(rèn)為，在項目最初的階段中，合格的架構(gòu)師會起到業(yè)務(wù)分析師的作用，然而業(yè)界已經(jīng)把“業(yè)務(wù)分析師”從架構(gòu)師小組中剔除，也不需要他們擁有做架構(gòu)師所需要的經(jīng)驗和深度。因此，我寧愿把他們稱之為“主管業(yè)務(wù)分析師”，這里的主管意味著他們本質(zhì)上也是架構(gòu)師。）

　　那么，好的業(yè)務(wù)分析師或者架構(gòu)師有哪些特征呢？以下是我的觀點：

他們已經(jīng)做過很多行業(yè)領(lǐng)域的項目
他們確實親自構(gòu)建和成功地實現(xiàn)了系統(tǒng)
他們能夠?qū)Ω拍钸M(jìn)行思考，能夠快速識別一種業(yè)務(wù)與其他業(yè)務(wù)之間的相似點和模式。
他們都能夠快速地學(xué)習(xí)，并且能夠與人清晰地溝通，在很短時間內(nèi)了解你的業(yè)務(wù)是什么；可能比你的員工還要好。
當(dāng)你解釋業(yè)務(wù)是什么、需要什么的時候，他們能夠很快把握重點。

　　最后，我要提出一個問題：誰知道你的業(yè)務(wù)需求？是客戶、業(yè)務(wù)用戶或者擁有者，還是應(yīng)該準(zhǔn)確表達(dá)系統(tǒng)需求的人？他們都經(jīng)過系統(tǒng)架構(gòu)師或者分析師的培訓(xùn)嗎？不。業(yè)務(wù)用戶最擅長描述業(yè)務(wù)是什么樣的，以及想要獲得某些信息，他應(yīng)該做些什么。他們甚至能夠表達(dá)他們認(rèn)為一切是如何運轉(zhuǎn)的，但是那只是從建議的角度提出的需求。其實是（也應(yīng)該是）業(yè)務(wù)分析師/架構(gòu)師才能夠最好地把針對業(yè)務(wù)用戶的業(yè)務(wù)需求“系統(tǒng)化”。

　　當(dāng)前很多方法學(xué)都在這里出了問題，導(dǎo)致很多系統(tǒng)最終失敗了。我不止一次聽到構(gòu)建系統(tǒng)的程序員們抱怨，客戶沒有準(zhǔn)確地表述他們的需求。很遺憾，伙計們，客戶的工作不是要產(chǎn)出需求，那是你的工作，我的分析師朋友們。分析師必須擁有這樣的技能：傾聽業(yè)務(wù)的講述，然后從那些談話中挖掘真正的需求。在沒有真正分析，而且信任關(guān)系是通過管理手段構(gòu)建的情況下，如果分析師說他“明白”的時候，業(yè)務(wù)人員就會強(qiáng)迫分析師接受自己的看法。不幸的是，這樣做的風(fēng)險非常大。他們能夠得到所要求的，但是并不是所需要的。

　　Michael

　　多年以來，IT始終沒有確定或者說是在忽略業(yè)務(wù)的角色。IT人創(chuàng)建了一種信念，他們更知道應(yīng)該為業(yè)務(wù)做什么和怎么做。即便是在集中的IT中，開發(fā)者也只把眼光放在眼前的項目上，比方說，他們的同事做了什么，而一些軟件開發(fā)方法把關(guān)注點只放在交付某些功能。當(dāng)業(yè)務(wù)和技術(shù)之間的橋梁幾近崩塌，IT就會開始談?wù)撿`活性，說業(yè)務(wù)對問題一點都不理解。

　　我是經(jīng)過了過去十年間參與面向服務(wù)的解決方案的工作，才發(fā)現(xiàn)了這個問題。我看到，盡管我告訴很多公司SOA具有強(qiáng)大的交付靈活性，但是他們還是在剛剛起步就失敗了。我知道他們之所以失敗，其中主要的原因不僅僅是IT對SOA產(chǎn)生了誤解，而且在于IT在提供以服務(wù)為中心的解決方案時，試圖讓業(yè)務(wù)以過程為中心。換句話說，IT對業(yè)務(wù)如何運轉(zhuǎn)做出響應(yīng)，而不是對業(yè)務(wù)應(yīng)該如何運轉(zhuǎn)做出響應(yīng)。

　　在很多行業(yè)中，IT已經(jīng)從工具開發(fā)者的角色轉(zhuǎn)換為解決方案開發(fā)者，那其中會包含業(yè)務(wù)解決方案的開發(fā)。然而，為了產(chǎn)出正確的解決方案，IT需要知道正確的業(yè)務(wù)任務(wù)或者業(yè)務(wù)需求。當(dāng)處理主要由低級別的運營業(yè)務(wù)團(tuán)隊提出的問題時，IT會鎖定這個級別業(yè)務(wù)人員的問題（大多數(shù)情況是那樣），然而，這個級別的人員反應(yīng)的都是過去的業(yè)務(wù)需求。事實上，低級別的運營業(yè)務(wù)過程只不過是對功能的業(yè)務(wù)實現(xiàn)，并且，隨著時間的推移，這些過程會與當(dāng)前的需求以及公司的目標(biāo)脫節(jié)。

　　想要達(dá)到業(yè)務(wù)敏捷，IT需要知道業(yè)務(wù)的發(fā)展方向，還要知道業(yè)務(wù)計劃在將來如何發(fā)展，然后再相應(yīng)地對軟件開發(fā)做出調(diào)整。在IT中對業(yè)務(wù)變更做出調(diào)整會比在業(yè)務(wù)中花費更長的時間，因為在代碼中存在很多隱藏和缺少文檔描述的依賴關(guān)系，并且還有在不關(guān)聯(lián)的應(yīng)用程序之間共享的重要程序庫，一項變更可能會產(chǎn)生很廣泛的影響，這樣，在業(yè)務(wù)用戶可以重新使用之前，都必須對程序進(jìn)行重新平衡，讓它變得足夠穩(wěn)定才行。這意味著IT需要比中層和底層業(yè)務(wù)運營單位更了解業(yè)務(wù)所期望的改變。過去十年中的經(jīng)濟(jì)動蕩使得IT無法培養(yǎng)出理解業(yè)務(wù)的軟件專家。這意味著IT再也無法依賴于在技術(shù)團(tuán)隊中所能夠正常學(xué)習(xí)到的業(yè)務(wù)知識；IT需要有一些專注的人員，他們不得不與業(yè)務(wù)一起工作。這些人員兼任了架構(gòu)師和業(yè)務(wù)/系統(tǒng)分析師的角色。

　　所以，IT架構(gòu)師和業(yè)務(wù)/系統(tǒng)分析師需要和中層到高層的業(yè)務(wù)人員緊密合作，以了解他們的意圖和方向，一方面要為現(xiàn)存的業(yè)務(wù)提供指引，另一方面要提供新的技術(shù)能力。這項工作無法在一個項目接一個項目的情況下完成；它或者要作為完整工作職責(zé)的部分完成，或者是在全局項目的范圍內(nèi)完成。也就是說，IT需要跨當(dāng)前和將來的項目，擁有一個由架構(gòu)師和業(yè)務(wù)/系統(tǒng)分析師組成的組織。在外包或者經(jīng)常有臨時工的情況下，架構(gòu)師和業(yè)務(wù)/系統(tǒng)分析師才是企業(yè)中最重要的IT財富，而不是經(jīng)理。如果你讓IT中的業(yè)務(wù)知識減少了，那么就是對IT的大腦做了損害。那樣的話，你需要和沒有大腦的IT一起工作了……

　　遵循這種邏輯，讓我再向業(yè)務(wù)更進(jìn)一步。顯然，中層和高層的業(yè)務(wù)人員沒有時間（或者沒有意愿）幫助IT解決問題。理解這樣的事實，會讓我們做出把業(yè)務(wù)架構(gòu)師的機(jī)構(gòu)和業(yè)務(wù)合并的決定。業(yè)務(wù)分析師實際上會負(fù)責(zé)對實現(xiàn)戰(zhàn)術(shù)上和戰(zhàn)略上的業(yè)務(wù)任務(wù)進(jìn)行管理，業(yè)務(wù)架構(gòu)師會和他們一起處理最高級別的業(yè)務(wù)計劃，識別業(yè)務(wù)需求，構(gòu)建業(yè)務(wù)架構(gòu)，并為了實現(xiàn)業(yè)務(wù)任務(wù)對其進(jìn)行描述。業(yè)務(wù)架構(gòu)師還會與IT管理者和技術(shù)架構(gòu)師交互。這意味著業(yè)務(wù)部門中的業(yè)務(wù)架構(gòu)師和業(yè)務(wù)分析師會負(fù)責(zé)構(gòu)思核心業(yè)務(wù)需求。最終，這些需求會在業(yè)務(wù)單位和IT之間切分。

　　根據(jù)我的經(jīng)驗，以及我的同事們的實踐，我知道在某些情況下，業(yè)務(wù)需求是從不同的低級業(yè)務(wù)過程的主觀需求中提取出來的，并且陷于其中無法自拔，最終這些業(yè)務(wù)需求會耗費掉IT所有的資源。我認(rèn)為對于這種問題只有一種緩和的解決方案，所有想要傳遞給IT的業(yè)務(wù)需求需要經(jīng)過某種形式的業(yè)務(wù)驗證，根據(jù)業(yè)務(wù)策略和部門的計劃來檢驗，并且進(jìn)行驗證的人員應(yīng)該是業(yè)務(wù)部門中的業(yè)務(wù)架構(gòu)師和業(yè)務(wù)分析師。我見證了這種方法，它很有效，當(dāng)IT推動了對業(yè)務(wù)需求的業(yè)務(wù)驗證，他們也會得到越來越多的尊重。

　　現(xiàn)代企業(yè)中架構(gòu)師的角色

　　在過去的幾年間，人們普遍認(rèn)為，在爭論之前要在語義上達(dá)成統(tǒng)一。因此，對于這個討論，我們都認(rèn)為架構(gòu)（軟件、業(yè)務(wù)、技術(shù)、硬件等）都是依據(jù)IEEE 1471標(biāo)準(zhǔn)定義（而不是描述）的。我們只能向IEEE 1471標(biāo)準(zhǔn)中添加組成架構(gòu)的元素

它們必須是基本的、能夠自給自足且連貫的
它們能夠不依賴其他元素存在（例如，不能是從其他元素衍生的）
它們應(yīng)該提供架構(gòu)元素視圖（從內(nèi)向外），而不是由視圖來提供架構(gòu)元素（由外向內(nèi)）。

　　我需要對最后一句話加以解釋。不管是誰在看，也不管是從哪里看（查看的角度如何），事物的所有視圖都會有誤解的風(fēng)險，無法真實反映該事物，因為 1) 它是主觀的；2) 它不知道事物的邊界，也無法把環(huán)境的一部分作為事物的一部分來考慮。相反，對事物的視圖是基于實際的知識獲得，那些知識是與所有外部利益相關(guān)者的興趣相關(guān)，并且會考慮如何才能夠生成持久的視圖。

　　盡管架構(gòu)的概念相對清晰，但我們還是無法認(rèn)為架構(gòu)師的角色也同樣清晰。在業(yè)界中還沒有一種標(biāo)準(zhǔn)來定義架構(gòu)師的特征，兩種主要陣營之間的意見截然不同。一種認(rèn)為架構(gòu)師是超級技工，他能夠熟練地掌握一些或者所有最新的技術(shù)。這樣的架構(gòu)師被稱為.NET架構(gòu)師或者JEE架構(gòu)師，等等。

　　另一個陣營認(rèn)為，架構(gòu)師的技術(shù)性要差一些，他應(yīng)該更關(guān)心“系統(tǒng)科學(xué)”和方法，那與自動化本身沒有任何關(guān)聯(lián)。這場討論的結(jié)果認(rèn)為架構(gòu)師應(yīng)該是后者的樣子，但是因為有多年的技術(shù)經(jīng)驗，他也應(yīng)該是很不錯的技術(shù)專家。我們在上面提到“技術(shù)性稍差”，意味著架構(gòu)師是知道為什么（why），何處（where）和何時（when）的人，例如，需要在解決方案中使用消息機(jī)制；從架構(gòu)角度來說，不管是廠商開發(fā)的消息機(jī)制還是自己開發(fā)的消息機(jī)制，都不重要（盡管從實現(xiàn)和管理的角度，那是非常重要的）。這種架構(gòu)師不會是前衛(wèi)的技術(shù)專家，但是他能夠勝任溝通業(yè)務(wù)和技術(shù)兩伙人的工作。在這種情況下，超級技工指的是軟件工程師或者技術(shù)主管，而不是架構(gòu)師。

　　Bruce

　　現(xiàn)在各種職位的稱謂已經(jīng)被濫用了，所以我在猶豫是否可以說最好的業(yè)務(wù)分析師就是系統(tǒng)架構(gòu)師，但是如果那些人是通過經(jīng)驗和技能獲得他們的技藝，那么架構(gòu)師通常是擁有經(jīng)驗和洞察力的人。在那種情況下，業(yè)務(wù)分析師的角色是由架構(gòu)師擔(dān)任的，那比創(chuàng)建架構(gòu)的優(yōu)先級高。在兩種情況下，負(fù)責(zé)業(yè)務(wù)分析工作的人都應(yīng)該符合已經(jīng)列出的條件。

　　當(dāng)業(yè)務(wù)需求已經(jīng)表述清楚時，業(yè)務(wù)團(tuán)隊中所有閱讀需求的人都應(yīng)該對其很清楚，而且那就是所要求的內(nèi)容。需求不會說明如何設(shè)計，盡管需求能夠強(qiáng)調(diào)設(shè)計中的一些方向以供考慮。例如：如果管理的愿景是為客戶提供自我服務(wù)的門戶，那么需求這樣描述就很合適了。然而，指定用戶號是20位數(shù)字和字符，其中帶有分隔符，這就不是一個業(yè)務(wù)需求，這只是某人的主意，從而可以更好地追蹤客戶，最好能夠根據(jù)經(jīng)驗來設(shè)置這些內(nèi)容。

　　如果一家企業(yè)的IT部門能夠理解一致戰(zhàn)略的的需求，從而符合業(yè)務(wù)的需求，那么它就會投資創(chuàng)建包含有業(yè)務(wù)活動模型和業(yè)務(wù)信息模型的業(yè)務(wù)架構(gòu)。這些模型與自動操作無關(guān)，而是會根據(jù)業(yè)務(wù)需要做什么、業(yè)務(wù)需要什么樣的信息來捕獲業(yè)務(wù)的本質(zhì)。如果存在這些模型，那么所有系統(tǒng)項目就有了堅定地基礎(chǔ)，并在總體的戰(zhàn)略中擁有屬于自己的位置。

　　如果沒有這種戰(zhàn)略，也沒有這些模型，那么系統(tǒng)項目就不得不在時間和預(yù)算允許的范圍內(nèi)做最大的努力。如果員工能夠了解企業(yè)的愿景，那么這種方法會生效，使得企業(yè)業(yè)務(wù)架構(gòu)會慢慢增長。不幸的是，這種情況很少發(fā)生。這種情況下所能夠期望達(dá)到的最好結(jié)果就是，對系統(tǒng)和標(biāo)準(zhǔn)來說冗余的部分之間不會有太多沖突，或者需要設(shè)置昂貴的數(shù)據(jù)整合過程來修補(bǔ)數(shù)據(jù)和過程之間的脫節(jié)。

　　總之，只有當(dāng)合格的業(yè)務(wù)分析師和架構(gòu)師能夠與企業(yè)中理解業(yè)務(wù)的遠(yuǎn)景和方向的人緊密合作，才能夠透徹地理解業(yè)務(wù)需求。通過這種合作，我們會得到連貫且有用的需求文檔，它會為你的業(yè)務(wù)服務(wù)，不僅僅是為當(dāng)前的系統(tǒng)項目，也會對將來所計劃的業(yè)務(wù)需求起到作用。

　　Michael

　　近來對架構(gòu)師的地位和角色的討論逐漸升溫。一些企業(yè)中的經(jīng)理還是無法接受，在項目中架構(gòu)師的地位要比業(yè)務(wù)分析師高。同時，企業(yè)架構(gòu)機(jī)構(gòu)和相關(guān)的架構(gòu)師越來越多地占領(lǐng)了傳統(tǒng)的業(yè)務(wù)領(lǐng)域。

　　技術(shù)架構(gòu)師已經(jīng)把結(jié)構(gòu)合理性和規(guī)范的邏輯引入到業(yè)務(wù)操作中，它是構(gòu)建在個性化很強(qiáng)的人與人的交互和關(guān)系上的。這可能對于某些業(yè)務(wù)活動很好，但并非對于所有都是那樣。自動化和形式化的機(jī)械應(yīng)用程序?qū)τ行蔚膬r值鏈方法學(xué)肯定有效，但人不是機(jī)器。忽略了價值網(wǎng)絡(luò)中無形的、面向交互的價值，使得業(yè)務(wù)和技術(shù)更難以實現(xiàn)革新，從而革新會更慢，成本會更高。

　　然而，與業(yè)務(wù)架構(gòu)師緊密合作，不僅對IT架構(gòu)師有利，而且對企業(yè)本身也有利。這樣的合作在業(yè)務(wù)和IT的邊界上生產(chǎn)力并不高，因此需要新的組織形式。業(yè)務(wù)和技術(shù)企業(yè)架構(gòu)都有責(zé)任保護(hù)整個企業(yè)，那意味著唯一符合該任務(wù)的組織形式就是跨功能、跨部門的團(tuán)隊，其中業(yè)務(wù)和技術(shù)企業(yè)架構(gòu)師能夠協(xié)同工作。和單獨的業(yè)務(wù)和IT部門以及海外企業(yè)級別的項目中的權(quán)威相比，這種團(tuán)隊的權(quán)威與之同級或者更高一些。

　　企業(yè)架構(gòu)位于組織中架構(gòu)功能層級機(jī)構(gòu)的頂端，該結(jié)構(gòu)中會依次把所有單位和部門（業(yè)務(wù)和技術(shù)部門）都包含到每個開發(fā)項目中。依照協(xié)作的業(yè)務(wù)戰(zhàn)略計劃，架構(gòu)師會定義在組織的各個層級所需要完成的任務(wù)。然后，公司的管理層會負(fù)責(zé)如何根據(jù)自身的情況來實現(xiàn)架構(gòu)上的決定和解決方案。這意味著，當(dāng)項目經(jīng)理設(shè)定項目的時候，相關(guān)的架構(gòu)師會確認(rèn)他們合適地設(shè)置了并解釋了項目的目標(biāo)和方法。

　　技術(shù)、業(yè)務(wù)和系統(tǒng)分析師都會完成自己與業(yè)務(wù)相關(guān)的工作，這是通過找到需求細(xì)節(jié)和依賴關(guān)系，并編寫相關(guān)文檔來完成的。技術(shù)、業(yè)務(wù)和系統(tǒng)分析師并不是“擁有企業(yè)洞察力的員工”，而只是專注于特定的項目需求。其他項目所做的工作，以及它們（在實現(xiàn)上）是否重疊通常不在他們的考慮范圍之內(nèi)。這樣，他們經(jīng)常會依賴于業(yè)務(wù)需求，那只是由技術(shù)、業(yè)務(wù)和系統(tǒng)分析師搜集獲得；IT有很大的風(fēng)險，可能會轉(zhuǎn)向錯誤的方向，因為他們很容易就會忽略重要的依賴關(guān)系。不幸的是，我們看到這種情況經(jīng)常會發(fā)生。

　　我堅信所有業(yè)務(wù)想法、建議、明確表述的需求和任務(wù)都是需要IT來實現(xiàn)的，而支持和集成工作在引入到IT之前，需要業(yè)務(wù)對其進(jìn)行檢驗和驗證。業(yè)務(wù)架構(gòu)師和業(yè)務(wù)部門中的業(yè)務(wù)分析師需要共同組成一個管道，對進(jìn)入到技術(shù)部門的需求進(jìn)行控制。技術(shù)架構(gòu)師會把業(yè)務(wù)需求轉(zhuǎn)換為架構(gòu)解決方案，并把它們傳遞給技術(shù)、業(yè)務(wù)和系統(tǒng)分析師來豐富細(xì)節(jié)。

　　因此，這個管道會以如下的方式運作：

業(yè)務(wù)請求者對業(yè)務(wù)需求進(jìn)行表述
業(yè)務(wù)架構(gòu)師和分析師審核需求，看它是否符合策略性業(yè)務(wù)計劃和公司的目標(biāo)。
業(yè)務(wù)架構(gòu)師和分析師會分析實現(xiàn)這個需求對周圍的業(yè)務(wù)執(zhí)行環(huán)境的影響和反作用。
如果所有人都批準(zhǔn)，那么需求會被傳遞給IT架構(gòu)師，他會根據(jù)需求來考慮IT的能力，并向業(yè)務(wù)反饋解決方案的概要。
如果IT解決方案在某種程度上影響了業(yè)務(wù)需求（例如，做了某種程度上的優(yōu)化），那么就會通過迭代的過程達(dá)到最終的意見。
大家達(dá)成共識的需求會被明確表述為核心業(yè)務(wù)需求，并傳遞給IT部門。
IT架構(gòu)師和系統(tǒng)分析師會分析其中的細(xì)節(jié)，并產(chǎn)生出業(yè)務(wù)和技術(shù)上的需求，以便在IT部門中進(jìn)行細(xì)節(jié)的設(shè)計和實現(xiàn)。

　　這是一種普遍的業(yè)務(wù)需求構(gòu)建過程，可以應(yīng)用在所有行業(yè)和企業(yè)中。這個過程非常適合業(yè)務(wù)和IT的治理，以及相關(guān)的質(zhì)量控制。我認(rèn)為，在所有營銷高峰中，實現(xiàn)得不合適的IT產(chǎn)品會造成很大的利益損失，這凸顯出用來定義真正的業(yè)務(wù)需求所付出的努力和時間是值得的。

　　構(gòu)建“好”/“壞”系統(tǒng)的過程

　　Bruce

　　假設(shè)我們已經(jīng)找到了合適的人，上述的需求也已經(jīng)獲取完畢，我們就能夠保證擁有更好的系統(tǒng)嗎？有可能會，也可能不會。

　　如果已經(jīng)獲取了良好的需求，那么和沒有獲取良好的需求的情況相比，我們更有機(jī)會創(chuàng)造出好系統(tǒng)，所以從那個角度來看，情況要好一些。但是，還是有很大的可能會失敗。

　　Dr. Paul Dorsey的一份報告強(qiáng)調(diào)了保證項目成功最主要的三種要素：

高級管理層的支持
合理可靠的方法
由已經(jīng)成功完成類似項目的人所領(lǐng)導(dǎo)的技術(shù)

　　很有趣的是，這與“過程”是什么樣的無關(guān)——換句話說，開發(fā)的風(fēng)格并不是問題。那么這種管理承諾的失敗在何處明顯體現(xiàn)了呢？

　　看起來，當(dāng)項目開始的時候，管理層通常會缺乏分析的耐心。現(xiàn)在有種流行詞叫做“分析麻痹癥”，并且經(jīng)常會為了得到“產(chǎn)出結(jié)果”而犧牲分析的時間，似乎設(shè)計根本就是在浪費時間。我曾經(jīng)和技術(shù)能力很強(qiáng)的團(tuán)隊一起工作，他們最終沒能成功交付項目，只是因為管理層沒有讓他們做該做的工作。不幸的是，IT業(yè)界讓初級的員工來做超出他們經(jīng)驗的工作，從而造成了這種形勢。作為響應(yīng)，很多方法認(rèn)為規(guī)避問題的方法就只是不做分析。問題就解決了！可能是吧。

　　在討論的最初階段，有人聲明，不管是在成功還是失敗的項目中，使用的方法都不是決定性因素。如果堅持這種看法，那么極限編程、敏捷、Rational統(tǒng)一過程等方法本身都不會讓事情走上正軌。這些方法所做的就是，試圖調(diào)節(jié)被破壞的過程，在壞形勢下獲得最好的結(jié)果；并且，這些方法的確使得情況有了一定程度的改善。不幸的是，如果通過合格的設(shè)計溝通出業(yè)務(wù)需求，開發(fā)者又能開發(fā)出什么呢？這些方法把業(yè)務(wù)人員放在開發(fā)者中間，期望隨著他們一起工作來構(gòu)建系統(tǒng)，需求就會逐漸顯現(xiàn)出來。如果業(yè)務(wù)人員非常了解企業(yè)和它的愿景，那么這會很有效，但如果不是那樣的話，就不那么有效了。人們必須了解總體上系統(tǒng)會變成什么樣子。那并不是說要在做任何工作之前把整個愿景描述清楚，愿景可以慢慢改進(jìn)，只要負(fù)責(zé)愿景的人（架構(gòu)師）能夠勝任這項工作，并且知道他的設(shè)計是要做什么。

　　問題是，什么因素讓系統(tǒng)對業(yè)務(wù)來說“好”或者“壞”呢？誰來判斷好壞，這是一種黑白分明的判斷嗎？

　　事實上，不管一個系統(tǒng)的構(gòu)想有多糟糕，至少都會完成一部分它想要做的事情。和最初就計劃好目標(biāo)相比，這可能需要更多的資金和時間，但是大多數(shù)系統(tǒng)都以某種方式達(dá)到了目的。不幸的是，構(gòu)想很差的系統(tǒng)無法確保業(yè)務(wù)能夠增長，也無法隨著時間的推移滿足業(yè)務(wù)的需求。

　　在此，我把“好”系統(tǒng)定義為能夠滿足業(yè)務(wù)需求的系統(tǒng)，它讓業(yè)務(wù)能夠隨著時間的變化靈活地改變，并且用戶會認(rèn)為系統(tǒng)能夠很好地支持業(yè)務(wù)。

　　相反，我對“壞”系統(tǒng)的定義是在某種程度上完成某些或者所有業(yè)務(wù)需求的系統(tǒng)，但是完成的方式會阻礙業(yè)務(wù)在將來的改變和發(fā)展。

　　Michael

　　我對“好的”技術(shù)系統(tǒng)的解釋與運行環(huán)境（業(yè)務(wù)和技術(shù)）緊密相關(guān)。我發(fā)現(xiàn)，在繁榮的時期，在外部業(yè)務(wù)環(huán)境中發(fā)生的業(yè)務(wù)變化要比蕭條的時期少。據(jù)此我們可以認(rèn)為，業(yè)務(wù)會為相同的技術(shù)系統(tǒng)設(shè)置不同的期望和需求。例如，在90年代末，在美國，系統(tǒng)的可伸縮性和性能是主要目標(biāo)；而現(xiàn)在，優(yōu)先級最高的是系統(tǒng)的靈活性/可擴(kuò)展性和安全性。

　　現(xiàn)在業(yè)務(wù)的靈活性需要技術(shù)解決方案足夠靈活，我們只需要對系統(tǒng)變更做最小的投資，對周圍系統(tǒng)調(diào)整作最小的投資，就能夠適應(yīng)業(yè)務(wù)的變化，并且所有工作都應(yīng)該在最短的時間內(nèi)完成（這就是我所定義的系統(tǒng)靈活性）。這與過去“實用的”實踐形成了鮮明的對比，那種實踐宣揚給定的需求必須明確地發(fā)布，不要給修改和替換留余地，好像將來不會有任何變更。

　　在IT部門實現(xiàn)業(yè)務(wù)需求的正常流程經(jīng)常會被破壞，而那并不一定是IT的過錯。IT創(chuàng)建并且繼承了很多舊的遺留系統(tǒng)，其中有大量不定和“意大利面式”代碼。如果業(yè)務(wù)想要快速推進(jìn)，那么就需要修復(fù)IT資產(chǎn)，使得它們更靈活。這項工作需要大量時間和資金，但這兩樣往往都很缺乏。云計算和外包對此不會有什么幫助，因為IT中舊的遺留系統(tǒng)中有很多公司財富——知識、邏輯和數(shù)據(jù)，并不適合外包。

　　引用Forrester研究公司的話，我們可以說“你的業(yè)務(wù)只能和你的技術(shù)以同樣的速度變化”。因此，“好”系統(tǒng)就是靈活的系統(tǒng)，當(dāng)前很有用，并且考慮到了將來的擴(kuò)展性。在“敏捷說法”中，“好”系統(tǒng)會滿足每天活動的業(yè)務(wù)需求，并且根據(jù)業(yè)務(wù)策略計劃平滑地轉(zhuǎn)換。

　　IT發(fā)明了一種又一種敏捷方法，目的就是為了構(gòu)建出好的系統(tǒng)。敏捷方法的主要部分都是基于這樣的假設(shè)：業(yè)務(wù)不能也不會以與今天不同的方式工作；這些方法不敢挑戰(zhàn)業(yè)務(wù)的工作方式，即便這種方式對于企業(yè)來說會降低生產(chǎn)力。這會導(dǎo)致這樣的趨勢：敏捷開發(fā)者主張簡單的設(shè)計，其中很少涉及未來的架構(gòu)和設(shè)計，或者根本不涉及。 實際上，開發(fā)團(tuán)隊負(fù)責(zé)依據(jù)業(yè)務(wù)需求交付軟件，而軟件的業(yè)務(wù)價值與團(tuán)隊是無關(guān)的： “如果業(yè)務(wù)想要這種方式，那么他們應(yīng)該知道那是什么，也知道為什么要那么做。”

　　我們經(jīng)常會遇到這樣的情況，敏捷團(tuán)隊承諾稍后會添加錯誤處理機(jī)制、調(diào)整、通知/警告、補(bǔ)償邏輯、事務(wù)完整性、安全性以及操作穩(wěn)定性等等，并把它們放在接下來的“時間表”中。然而，所有這些技術(shù)功能都是IT所關(guān)心的；它們是業(yè)務(wù)部門期望從技術(shù)部門立刻得到的服務(wù)質(zhì)量（QoS）特性，而不是要拖延到下次。業(yè)務(wù)邏輯很簡單： “如果軟件已經(jīng)有效地運行，（哦，真的嗎？）為什么要等待更長時間才能得到最終的發(fā)布版本，并投入更多資金呢？相反，既然IT已經(jīng)做得很好了，那么讓他們做其他任務(wù)吧。”

　　讓我們回到精益方法學(xué)，在此重新回顧一下大野耐一所描述的真正的精益生產(chǎn)原則，這非常重要：

只構(gòu)建我們需要的
如果出問題了就停下來
去除所有不產(chǎn)生價值的工作

　　不可否認(rèn)，這些原則都非常合理，可以很容易地在生產(chǎn)環(huán)境中對其加以解釋，在那種環(huán)境中我們可以完整地定義和指定最終的結(jié)果。然而，當(dāng)Mary Poppendieck和Tom Poppendieck描述精益項目管理方法的七項原則時，他們在很多地方已經(jīng)脫離了精益生產(chǎn)的本意。

　　比方說，讓我們來看一下精益方法在面向服務(wù)的情況下如何起作用，在其中精益團(tuán)隊會構(gòu)建一項SOA服務(wù)。因為人們集中關(guān)注于精益原則“消除浪費”，因此那成為團(tuán)隊的首要任務(wù)。順便說一下，消除軟件開發(fā)中的浪費是一項非常有挑戰(zhàn)的任務(wù)，要比生產(chǎn)行業(yè)中難得多，因為在所有的業(yè)務(wù)需求中都會有很多不確定的因素，而架構(gòu)的愿景無法在其中反映出來。那么，如果我們討厭并且忽略了將來的架構(gòu)設(shè)計，我們?nèi)绾尾拍芘袛喑鍪裁词抢速M，什么不是浪費呢？

　　在SOA中，所有服務(wù)都可能被用戶使用到，而最初請求服務(wù)的人（構(gòu)建服務(wù)也是基于他的需求）可能很快就會被大家忘掉。SOA服務(wù)必須為未知的用戶（或者使用精益術(shù)語，客戶）服務(wù)。每個客戶都能夠在服務(wù)中找到屬于自己的價值，而這個價值與開發(fā)團(tuán)隊所要達(dá)到的目標(biāo)可能會截然不同。這是說生產(chǎn)行業(yè)中定義的浪費無法適用于面向服務(wù)的開發(fā)嗎？或者說，沒有健壯的架構(gòu)設(shè)計，它可能無法適用于所有軟件開發(fā)中……

　　另一項精益原則——“延遲交付”，這在概念上與“消除浪費”是相互矛盾的。我們可能會延遲交付。比方說，延遲完成對產(chǎn)品的實現(xiàn)，因為我們認(rèn)為我們的任務(wù)中某些業(yè)務(wù)會發(fā)生變化。如果我們認(rèn)為會發(fā)生變化，但是又不知道會發(fā)生什么樣的變化，那么如何才能夠識別出浪費呢？對于即將發(fā)生的變更來說，一項工作可能是浪費，而另一項可能會是非常有用的特性。我想那就是面向服務(wù)的規(guī)則——“為變更而設(shè)計”——那會比延遲交付更有效。

　　還有兩項原則：“內(nèi)建質(zhì)量”和“整體優(yōu)化”，這可能與“為團(tuán)隊授權(quán)”原則矛盾。我們認(rèn)為精益團(tuán)隊?wèi)?yīng)該專注于特定的任務(wù)，那樣就很難發(fā)現(xiàn)“整體”。并且，創(chuàng)建于IT中其它不在項目范圍內(nèi)元素的完整性就更難了。這兩項原則都應(yīng)該屬于跨團(tuán)隊的架構(gòu)職能，而不是屬于開發(fā)團(tuán)隊；應(yīng)該是有了架構(gòu)之后才能夠定義浪費。

　　最后，我覺得“為團(tuán)隊授權(quán)”這條原則很有意思（而不是為管理層授權(quán)），它被添加到IT精益方法中，而最根本的原則“如果出問題就停止”卻被排除在外。這意味著在開發(fā)中只有“大晴天”，所有的執(zhí)行情況都是可以預(yù)料的嗎？沒有停止原則，為團(tuán)隊授權(quán)之后，精益項目經(jīng)理就缺少后退的機(jī)制。也就是說，他們會持續(xù)交付所有可以提供的內(nèi)容，包括浪費。這樣，結(jié)論只能是以下兩種之一：或者IT精益方法的基礎(chǔ)還不成熟，或者說它又是一種錯誤的方法。

　　我們能做得更好嗎？

　　Bruce

　　在本次討論中我們說的是：

方法不是成功的決定因素
業(yè)務(wù)需要一種業(yè)務(wù)架構(gòu)
業(yè)務(wù)應(yīng)該指定需求，架構(gòu)師/分析師應(yīng)該指定需求的系統(tǒng)化實現(xiàn)。
管理層需要選定一種方法并為其提供持續(xù)的支持
我們可以根據(jù)系統(tǒng)支持業(yè)務(wù)的能力來評定它的好壞

　　我們怎樣才能達(dá)到這樣的目標(biāo)呢？ IT業(yè)界歷史上殘酷的現(xiàn)實是，你不可能總是可以找到最好的人，所以需要讓缺少經(jīng)驗和能力的人來完成工作。我們還有希望實現(xiàn)產(chǎn)出好系統(tǒng)的夢想嗎？我相信有。

　　如果有清晰表述的良好業(yè)務(wù)架構(gòu)，那么對于獲取需求就有了堅實的基礎(chǔ)。如果有構(gòu)建在那種業(yè)務(wù)架構(gòu)上的堅實的應(yīng)用程序架構(gòu)，那么項目的規(guī)范就能夠以可控和漸進(jìn)的方式完成。

　　如果創(chuàng)建了合理的架構(gòu)實踐和指南，并且明確表述了高級管理層支持的企業(yè)愿景，那么其他的事情就會落到實處，并且不會過分依賴于項目團(tuán)隊的經(jīng)驗和技能，這只是因為已經(jīng)定義了堅實的框架，他們可以在其中工作。這并非是完美的方法，但這是我們所面對的現(xiàn)實情況。

　　我們可以提供這些“可能的”部分，而不需要花費多年時間嗎？

　　如果我們能夠找到正確的人來為業(yè)務(wù)建模，那么他就會很快把模型建立起來。不管是什么樣的業(yè)務(wù)部門（政府、制造業(yè)、軍隊等等），由兩位建模人員組成的團(tuán)隊共同協(xié)作，就能夠很快地捕獲到活動和信息的模型。在中型和大型企業(yè)的環(huán)境中，六個月的項目就應(yīng)該足以滿足需求。

　　根據(jù)高級管理層的愿景和方向的不同，對應(yīng)用程序架構(gòu)的調(diào)查可能還需要兩到三個月。所需要的時間期限是主觀的，并且嚴(yán)重依賴于組織的文化以及企業(yè)忙于處理遺留應(yīng)用程序的程度。

　　意識到上述討論的問題，可以讓我們獲得更好的、更具有持續(xù)性的開發(fā)項目。另外，還有一種好處就是可以把業(yè)務(wù)從多年來實現(xiàn)得很差、冗余的系統(tǒng)中解放出來。

　　上述的應(yīng)用程序架構(gòu)包含了所有當(dāng)前在企業(yè)中使用的應(yīng)用程序，還有這些應(yīng)用程序如何幫助或者阻礙業(yè)務(wù)的真實需求的評估。當(dāng)檢查這些系統(tǒng)時，如果能夠更關(guān)注于業(yè)務(wù)需求，那么我們就有更大的機(jī)會基于功能和數(shù)據(jù)對其進(jìn)行整合。減少應(yīng)用程序的數(shù)量，不僅能夠降低運營成本，而且通過提供更可靠和及時的數(shù)據(jù)，會為企業(yè)帶來更大的好處，并且開發(fā)環(huán)境的響應(yīng)更及時，從而滿足業(yè)務(wù)變更所帶來的挑戰(zhàn)。

　　Michael

　　我關(guān)于這個問題的回答是“是的，IT能做得更好，但是光憑IT自身不行”。IT需要在以下方面把業(yè)務(wù)部門涉及進(jìn)來：

做所有與技術(shù)解決方案相關(guān)的決定
根據(jù)業(yè)務(wù)策略檢查自身的能力
合并開發(fā)和運維的費用
評價生產(chǎn)出來的技術(shù)系統(tǒng)

　　這樣的動作能夠讓業(yè)務(wù)對他們的需求和選擇負(fù)責(zé)。

　　當(dāng)技術(shù)架構(gòu)師提出一些可選的要實現(xiàn)解決方案的建議時，客戶和利益相關(guān)者需要知道，如果他們選擇了費用最低但是沒有考慮到將來的解決方案，那么他們就需要對這個決定負(fù)責(zé)，而不是由IT來負(fù)責(zé)。我已經(jīng)看到過很多這樣的情況，在開發(fā)時費用最低的解決方案，在維護(hù)時會耗費大量的金錢。我們應(yīng)該如何來平衡呢？很容易，業(yè)務(wù)和IT需要把成本作為選擇技術(shù)解決方案的目標(biāo)。而不能由某個部門單獨來決定項目或者開發(fā)成本的目標(biāo)。

　　當(dāng)IT檢查技術(shù)能力的時候，經(jīng)常會發(fā)現(xiàn)平臺陳舊，如果不報廢的話，可能再也得不到廠商的支持。這樣的平臺能夠?qū)I(yè)務(wù)策略目標(biāo)和目的起到應(yīng)有的作用嗎？答案是，很可能不會。那么，IT需要公開說明，現(xiàn)在的系統(tǒng)已經(jīng)無法支持策略性的業(yè)務(wù)需求，我們可以說明一下，擁有現(xiàn)存的解決方案需要付出大量的維護(hù)成本，那已經(jīng)占據(jù)了IT預(yù)算的主要部分，而沒給策略性開發(fā)留下多少。

　　當(dāng)開發(fā)出新的解決方案、產(chǎn)品或者系統(tǒng)時，它需要經(jīng)過將來使用它的業(yè)務(wù)用戶的審查。傳統(tǒng)的用戶接受測試只會檢查業(yè)務(wù)功能。與之相比，業(yè)務(wù)審查需要檢查IT產(chǎn)品在所有異常或者非標(biāo)準(zhǔn)的業(yè)務(wù)情況下的響應(yīng)，比方說，可伸縮性需要在真實的環(huán)境中演示，而不是在專門的測試系統(tǒng)中。如果系統(tǒng)通過了審查，它會存活得很好；如果沒有，可能就要對一些業(yè)務(wù)需求進(jìn)行修訂。在任意情況下，IT都需要和業(yè)務(wù)部門一起重新設(shè)置業(yè)務(wù)的期望，并以合作和積極的方式來確定改進(jìn)的方向，而不是忙于正式環(huán)境中的報告和缺陷。

　　IT能夠如何更多地讓業(yè)務(wù)參與進(jìn)來呢？可能我并不是最早這么說的： a) 支持和改進(jìn)業(yè)務(wù)中業(yè)務(wù)架構(gòu)師所提出的想法， b) 支持和改進(jìn)跨業(yè)務(wù)和技術(shù)的企業(yè)架構(gòu)、由業(yè)務(wù)和技術(shù)架構(gòu)師共同制定的想法，c) 設(shè)置定期的會議，可以讓在相同業(yè)務(wù)領(lǐng)域中工作的業(yè)務(wù)和技術(shù)團(tuán)隊的業(yè)務(wù)架構(gòu)師來交換意見，d) 在IT部門中創(chuàng)建總監(jiān)級別的結(jié)構(gòu)，它會直接與業(yè)務(wù)管理層協(xié)同工作，作為了解所有想要讓IT做的業(yè)務(wù)需求的管道，e) 創(chuàng)建跨項目的分析小組，他的責(zé)任是要分析低級和中級的業(yè)務(wù)運營過程，并基于技術(shù)能力得出優(yōu)化建議，也就是讓IT更積極。

　　我發(fā)現(xiàn)，在技術(shù)治理中還有一種IT可以改進(jìn)的方面。我實際上指的是，技術(shù)治理包括所有架構(gòu)、開發(fā)、數(shù)據(jù)/信息和管理的治理領(lǐng)域。這種治理不僅僅是關(guān)于什么是什么，而且還涉及到在開發(fā)和測試中所能夠使用的技術(shù)。這種治理涉及到的方面包括對開發(fā)在架構(gòu)上和設(shè)計上的控制，開發(fā)和測試的工具和方法論，項目管理方法，以及現(xiàn)存和“正在開發(fā)”的系統(tǒng)、產(chǎn)品和解決方案之間的協(xié)作。治理手段需要覆蓋IT在端到端業(yè)務(wù)開發(fā)所涉及的內(nèi)容，確定解決方案所有權(quán)的目的，以及在IT和業(yè)務(wù)之間的SLA中所定義的責(zé)任。治理無法用管理來替代。治理要說的是，當(dāng)管理層要執(zhí)行治理策略時，應(yīng)該做什么事情，以及事情應(yīng)該怎樣做。如果治理策略是由IT管理層來維護(hù)的，那么讓具有獨特權(quán)力的治理人員來指導(dǎo)IT整體上的功能，就有可能獲得針對業(yè)務(wù)合理的靈活性。

　　查看英文原文：IT And Architecture: Inside-Out Perspectives