作為IT架構(gòu)師，很可能經(jīng)常會(huì)發(fā)現(xiàn)自己處于進(jìn)退維谷的境地—前有業(yè)務(wù)目標(biāo)，后有IT系統(tǒng)。這兩方面都具有規(guī)模大、不易改變和靈活性差的特點(diǎn)，制定業(yè)務(wù)目標(biāo)的人員和開(kāi)發(fā)系統(tǒng)的人員不一定了解彼此的工作內(nèi)容和成果。
　　業(yè)務(wù)人員使用一種語(yǔ)言來(lái)表達(dá)他們希望實(shí)現(xiàn)的業(yè)務(wù)目標(biāo)，而開(kāi)發(fā)人員則使用另一種語(yǔ)言來(lái)表述技術(shù)要求。而這就是我們?yōu)榱藢?shí)現(xiàn)高效率而需要著手處理的問(wèn)題:理解這兩種語(yǔ)言并執(zhí)行必要的轉(zhuǎn)換，以便 IT 能反映業(yè)務(wù)的需求，并能在適當(dāng)?shù)臅r(shí)候?qū)I(yè)務(wù)目標(biāo)進(jìn)行更改，使其與 IT 的能力相適應(yīng)。這并不是一個(gè)容易完成的工作，但這正是您能夠獲得很大利益的原因。
　　一個(gè)詞:用例
　　在業(yè)務(wù)用例中，參與者是干系人，而系統(tǒng)則是業(yè)務(wù)本身。
　　用電影《畢業(yè)生》中的方式，我只想對(duì)你說(shuō)一個(gè)詞:用例。很多年來(lái)，我們都將用例用于對(duì)應(yīng)用程序進(jìn)行建?！，F(xiàn)在，在面向服務(wù)的體系結(jié)構(gòu) (SOA) 中，我們也使用這個(gè)概念來(lái)對(duì)業(yè)務(wù)進(jìn)行建模。
　　在Alistair Cockburn的《Writing Effective Use Cases》一書(shū)中，他將用例定義為“系統(tǒng)干系人之間就系統(tǒng)的行為達(dá)成的協(xié)定”。用例必須適合所定義的系統(tǒng)范圍，能夠代表此情況下使用系統(tǒng)的主要參與者的觀點(diǎn)，且能夠在一致的抽象層次上表示參與者的系統(tǒng)使用情況。
　　例如，股票交易Web站點(diǎn)的一個(gè)用例是“購(gòu)買股票”，允許用戶通過(guò)此站點(diǎn)購(gòu)買股票。該用例描述了客戶進(jìn)行何種操作以及站點(diǎn)如何響應(yīng)，而暫時(shí)忽略了站點(diǎn)將如何實(shí)際實(shí)現(xiàn)此行為。
　　可以將用例用于對(duì)服務(wù)進(jìn)行建模;我將此稱為服務(wù)用例。當(dāng)用例描述服務(wù)時(shí)，參與者就是服務(wù)使用者，而系統(tǒng)則為服務(wù)提供者。與任何用例一樣，此時(shí)的重點(diǎn)是服務(wù)提供者提供何種行為，而不是如何實(shí)現(xiàn)該行為。
　　還可以將用例用于對(duì)業(yè)務(wù)進(jìn)行建模。在業(yè)務(wù)用例中，參與者是干系人——業(yè)務(wù)用戶（如客戶或員工，甚至股東或政府監(jiān)管人員），而系統(tǒng)則是業(yè)務(wù)本身（生產(chǎn)產(chǎn)品并將其銷售給客戶的公司）。業(yè)務(wù)如何開(kāi)展？客戶希望業(yè)務(wù)如何開(kāi)展？他們?cè)敢鉃楹畏N服務(wù)或產(chǎn)品付費(fèi)？員工需要業(yè)務(wù)如何開(kāi)展才能完成各自的工作？關(guān)鍵在于，這些干系人如何與公司進(jìn)行交互，這些都是業(yè)務(wù)用例。
　　獲得了業(yè)務(wù)用例后，則可以隨后將其鏈接起來(lái)，以形成業(yè)務(wù)流程—公司可以執(zhí)行的過(guò)程。這些流程本身就是業(yè)務(wù)用例，而復(fù)雜的業(yè)務(wù)用例可以被視為業(yè)務(wù)流程。簡(jiǎn)單地講，這些流程顯示了公司要做什么以及如何做。如前面所述，流程以及每個(gè)流程中的步驟都對(duì)服務(wù)進(jìn)行建模。
　　通過(guò)用例將公司或公司的一部分建模為由服務(wù)組成的業(yè)務(wù)流程后，隨后的目標(biāo)就是盡可能多地實(shí)現(xiàn)流程和服務(wù)的自動(dòng)化。實(shí)現(xiàn)這種自動(dòng)化的應(yīng)用程序是采用面向服務(wù)的體系結(jié)構(gòu)的應(yīng)用程序，而現(xiàn)在正在進(jìn)行 SOA 實(shí)踐。
　　記錄流程
　　如果客戶不了解業(yè)務(wù)，架構(gòu)師有效定義系統(tǒng)要求的幾率都很小。
 　　筆者在與客戶討論新程序或開(kāi)發(fā)工作時(shí)，會(huì)立即了解業(yè)務(wù)干系人是否出席或派代表出席。然后，我會(huì)希望得到記錄良好的業(yè)務(wù)流程和數(shù)據(jù)要求。除非相關(guān)工作是一片“處女地”，否則一定會(huì)對(duì)新應(yīng)用程序或功能支持的原有的業(yè)務(wù)流程和將來(lái)的業(yè)務(wù)流程有良好的理解。不管采用哪一種方式，如果客戶不了解業(yè)務(wù)，架構(gòu)師有效定義系統(tǒng)要求的幾率就很小。
　　筆者個(gè)人非常贊同開(kāi)發(fā)業(yè)務(wù)場(chǎng)景來(lái)記錄業(yè)務(wù)流程，業(yè)務(wù)場(chǎng)景允許在整個(gè)業(yè)務(wù)問(wèn)題的上下文中標(biāo)識(shí)系統(tǒng)要求。
　　確定了將來(lái)的業(yè)務(wù)需求后，如果能維護(hù)一份功能和非功能行式項(xiàng)目要求的列表，也很有好處。我極力贊同使用工具來(lái)管理要求;為了達(dá)成此目的，我建議使用 IBM Rational RequisitePro。
　　通過(guò)使用根據(jù)業(yè)務(wù)場(chǎng)景確定的初始要求集，我們就可以開(kāi)始定義系統(tǒng)行為的過(guò)程了。為此，可以召開(kāi)聯(lián)合應(yīng)用程序開(kāi)發(fā)（JAD）會(huì)議，以便根據(jù)一系列初始行式項(xiàng)目要求來(lái)充實(shí)將來(lái)的系統(tǒng)。通過(guò)JAD會(huì)議，架構(gòu)師可以與干系人一起確定期望的系統(tǒng)行為，并以此為基礎(chǔ)記錄用例和場(chǎng)景。通過(guò)對(duì)用例和場(chǎng)景進(jìn)行細(xì)化，可以幫助定義最終的一系列功能和非功能要求。
　正確功能的正確解決方案
　　如果我所做的只是將價(jià)格信息發(fā)布到網(wǎng)上，我可以到最近的小學(xué)里找個(gè)人來(lái)編寫(xiě)HTML。如果我要做的是嘗試采用多種語(yǔ)言跨越國(guó)界擴(kuò)展我的供應(yīng)鏈，并確?？梢匀旌虻卦L問(wèn)，那么我的功能和容量就必須更為可靠。
　　開(kāi)發(fā)和設(shè)計(jì)解決方案的體系結(jié)構(gòu)時(shí)需要考慮的最重要的事項(xiàng)之一就是所需的對(duì)應(yīng)功能和容量級(jí)別。
　　經(jīng)驗(yàn)豐富的專業(yè)人員可以幫助客戶將業(yè)務(wù)需求轉(zhuǎn)換為業(yè)務(wù)意圖。業(yè)務(wù)意圖更為模糊，但更與“基本需求”和“投資回報(bào)”一致。
　　筆者相信業(yè)務(wù)需求和IT 功能存在重疊。正是由于這個(gè)模糊不清的界線使得體系結(jié)構(gòu)設(shè)計(jì)成為了一個(gè)困難而費(fèi)時(shí)的過(guò)程。不管是采用瀑布式還是迭代方法，規(guī)劃和需求分析階段始終都很單調(diào)乏味。客戶很少知道他們需要什么，經(jīng)驗(yàn)豐富的專業(yè)人員有責(zé)任幫助客戶將業(yè)務(wù)需求轉(zhuǎn)換為IT功能。
　　這并不能通過(guò)只使用良好的工具和方法來(lái)實(shí)現(xiàn)，因?yàn)槊總€(gè)項(xiàng)目都是獨(dú)特的。盡管兩家公司相似，但他們都會(huì)告訴你各自的業(yè)務(wù)具有獨(dú)特性，并將這些不同之處視為他們的競(jìng)爭(zhēng)優(yōu)勢(shì)。很多時(shí)候，文化、地域和地理位置對(duì)業(yè)務(wù)需求的影響決定著IT解決方案。政府法律法規(guī)和標(biāo)準(zhǔn)可能要求技術(shù)人員根據(jù)部署解決方案的場(chǎng)合對(duì)相同的業(yè)務(wù)需求采用不同的方法來(lái)設(shè)計(jì)。
　　捕獲和交付構(gòu)件的技術(shù)，包括用例、場(chǎng)景文檔、Rational Unified Process (RUP)—應(yīng)當(dāng)在參與的客戶中一致地實(shí)現(xiàn)。如果在項(xiàng)目進(jìn)行中，客戶改變了主意（業(yè)務(wù)需求）和決定，例如系統(tǒng)不需要24x7的可用性，而只需要8x7的可用性即可，因?yàn)樗麄儾幌Ｍ袚?dān)24x7解決方案所帶來(lái)的高成本，仍然可以很好地使用這些構(gòu)件。 [NextPage]
　　管理不確定性和易變性

 　　由于這是一個(gè)與人相關(guān)的問(wèn)題，將組織的業(yè)務(wù)需求轉(zhuǎn)換為 IT 要求的挑戰(zhàn)并不能僅靠使用工具或方法得以解決。
　　業(yè)務(wù)需求和IT要求有很大部分都是重合的;即對(duì)于某些人而言業(yè)務(wù)需求指的是“我已更改的或新的業(yè)務(wù)流程是什么樣的？”而對(duì)其他人而言，則指的是“我如何借助對(duì)應(yīng)的關(guān)鍵成功因素實(shí)現(xiàn)一系列業(yè)務(wù)目標(biāo)？”還有些人覺(jué)得，這可能只意味著為一系列業(yè)務(wù)干系人提供功能，如新設(shè)備或新頁(yè)面，或者僅是新的自動(dòng)化業(yè)務(wù)規(guī)則執(zhí)行而已。
　　重要的事實(shí)是:業(yè)務(wù)需求和IT要求之間是否存在差別？這可能會(huì)引出一通長(zhǎng)篇大論，但我的觀點(diǎn)是，缺乏術(shù)語(yǔ)以及用來(lái)討論這個(gè)問(wèn)題的共同語(yǔ)言本身就是一個(gè)問(wèn)題。
　　我們的挑戰(zhàn)是業(yè)務(wù)需求和要求通常僅得到了部分理解，而且通常具有易變性。很多開(kāi)發(fā)方法都在通過(guò)引入迭代開(kāi)發(fā)、工具以及其他技術(shù)來(lái)適應(yīng)這個(gè)不確定性和易變性。但這些方法僅解決了這個(gè)問(wèn)題的一部分，因?yàn)檫@個(gè)不確定性和易變性僅是此問(wèn)題的一部分而已。在假定特定方法是最優(yōu)的方法之前，要求流程必須了解要進(jìn)行的項(xiàng)目的類型。
　　項(xiàng)目類型因大小、范圍、組織關(guān)心的重點(diǎn)、文化、對(duì)解決方案的認(rèn)識(shí)、當(dāng)前環(huán)境以及其他因素的不同而有所差異。各種項(xiàng)目類型要求我們對(duì)每個(gè)項(xiàng)目采用不同的方式來(lái)處理將組織的需求轉(zhuǎn)換為 IT 要求的問(wèn)題。不同的類型項(xiàng)目要求在開(kāi)發(fā)方法、工具以及應(yīng)如何管理要求方面采取不同的處理方式。
　　由于這是一個(gè)與人相關(guān)的問(wèn)題，將組織的業(yè)務(wù)需求轉(zhuǎn)換為 IT 要求的挑戰(zhàn)并不能僅靠使用工具或方法得以解決。認(rèn)為可以通過(guò)改善工具或創(chuàng)建新開(kāi)發(fā)流程、方法或技術(shù)來(lái)完全解決此問(wèn)題的想法是錯(cuò)誤的。
　　經(jīng)驗(yàn)豐富的專業(yè)人員知道將組織的業(yè)務(wù)需求轉(zhuǎn)換為 IT 要求的過(guò)程中必須根據(jù)一系列因素進(jìn)行調(diào)整。這些因素包括:對(duì)業(yè)務(wù)需求了解多少？對(duì)IT要求了解多少？最終的解決方案的概貌如何？
　　這些因素在項(xiàng)目進(jìn)行期間會(huì)不斷地發(fā)生變化。這正是采用敏捷編程、IBM bbbbbb Services 方法、RUP或其他流程的技術(shù)人員不能盲目認(rèn)為其采用的方法就是正確的方法的眾多原因之一。
　　沒(méi)有捷徑，立即動(dòng)手，不要等待
　　如果無(wú)法足夠詳細(xì)而清晰地將干系人的需求用書(shū)面形式表述出來(lái)，則您就沒(méi)有完成捕獲項(xiàng)目要求的任務(wù)。
　　IT架構(gòu)師在項(xiàng)目的生命周期的初始階段扮演的主要角色之一是捕獲關(guān)于干系人的需求的信息。IT架構(gòu)師必須聽(tīng)取客戶和干系人的看法，理解他們的業(yè)務(wù)需求，并系統(tǒng)地以增量方式形成IT解決方案的結(jié)構(gòu)更為詳細(xì)的結(jié)構(gòu)。這個(gè)過(guò)程通常不僅是靠通過(guò)經(jīng)驗(yàn)積累就能完成的，而且必須為一種有所控制的方法。
　　生活中的兩個(gè)事實(shí)也可應(yīng)用到 IT 解決方案的開(kāi)發(fā)中: 幾乎沒(méi)有真正的捷徑;最好現(xiàn)在就動(dòng)手，而不要等待。
　　筆者和客戶一起工作時(shí)，我常常發(fā)現(xiàn)在構(gòu)建 IT 解決方案中為軟件開(kāi)發(fā)項(xiàng)目記錄的需求級(jí)別非常少。這種定義缺乏的原因是由于將業(yè)務(wù)需求細(xì)化為可操作的 IT 要求是一項(xiàng)很困難的工作，需要經(jīng)驗(yàn)豐富的人員（這就是為什么 IT 架構(gòu)師是極其寶貴的資源的一個(gè)原因），將業(yè)務(wù)需求細(xì)化為 IT 要求是一項(xiàng)艱巨的任務(wù)，需要將精力放在細(xì)節(jié)上，而且是一個(gè)迭代的過(guò)程。
 　　此處要指出的是，必須花大量的時(shí)間來(lái)詳細(xì)說(shuō)明解決方案的需求。統(tǒng)計(jì)數(shù)據(jù)表明，在前期花的時(shí)間越多，在開(kāi)發(fā)過(guò)程的后期階段花的時(shí)間就越少，從而可以縮短開(kāi)發(fā)周期。
　　有很多方法可用于將業(yè)務(wù)需求細(xì)化為較高抽象級(jí)要求，然后再將此類要求細(xì)化為技術(shù) IT 要求。建模是從干系人捕獲初始功能要求集的一個(gè)主要方法。通過(guò)創(chuàng)建用例、建模過(guò)程流和形成統(tǒng)一建模語(yǔ)言（Unified Modeling Language，UML）交互關(guān)系圖，您可以開(kāi)始將業(yè)務(wù)要求細(xì)化為更為詳細(xì)的定義，系統(tǒng)必須支持或啟用所定義的這些功能。在復(fù)雜環(huán)境中會(huì)使用包括以下內(nèi)容的更為復(fù)雜的方法:組件業(yè)務(wù)建?；蛘呙嫦蚍?wù)的模型體系結(jié)構(gòu)。
　　這些方法可以確保 IT 要求與業(yè)務(wù)目標(biāo)一致，從而讓公司能夠真正實(shí)現(xiàn) SOA 的價(jià)值主張。
　　從需求進(jìn)行轉(zhuǎn)換來(lái)選擇要用于構(gòu)造解決方案的技術(shù)或產(chǎn)品可能成為一個(gè)挑戰(zhàn)。架構(gòu)師從過(guò)去項(xiàng)目中獲得的經(jīng)驗(yàn)將影響這些決策，但架構(gòu)師還必須忠實(shí)地對(duì)每個(gè)要求（對(duì)滿足需求極為重要的 IT 功能）進(jìn)行評(píng)估。確定了 IT 功能后，架構(gòu)師可以將這些功能映射為體系結(jié)構(gòu)組件（然后映射到技術(shù)和產(chǎn)品），從而以增量的方式向他們的解決方案結(jié)構(gòu)添加更為詳細(xì)的定義。