国产在线精品亚洲另类,91精品视频网站,国产精品爽爽久久久久久蜜桃网站

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

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

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

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

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

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

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

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

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

　　Bruce

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

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

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

　　Michael

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

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

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

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

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

　　Bruce

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　Michael

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

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

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

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

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

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

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

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

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

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

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

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

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

　　Bruce

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

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

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

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

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

　　Michael

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

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

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

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

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

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

　　因此，這個(gè)管道會(huì)以如下的方式運(yùn)作：

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

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

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

　　Bruce

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

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

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

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

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

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

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

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

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

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

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

　　Michael

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

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

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

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

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

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

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

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

　　不可否認(rèn)，這些原則都非常合理，可以很容易地在生產(chǎn)環(huán)境中對(duì)其加以解釋?zhuān)谀欠N環(huán)境中我們可以完整地定義和指定最終的結(jié)果。然而，當(dāng)Mary Poppendieck和Tom Poppendieck描述精益項(xiàng)目管理方法的七項(xiàng)原則時(shí)，他們?cè)诤芏嗟胤揭呀?jīng)脫離了精益生產(chǎn)的本意。

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

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

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

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

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

　　我們能做得更好嗎？

　　Bruce

　　在本次討論中我們說(shuō)的是：

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

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

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

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

　　我們可以提供這些“可能的”部分，而不需要花費(fèi)多年時(shí)間嗎？

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

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

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

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

　　Michael

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

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

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

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

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

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

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

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

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