引言
注意：有關觀點與展望 專欄的一般性介紹，請參閱第 1 部分。
作為 IT 架構師，您可能經常會發現自己處于進退維谷的境地，前有您的業務目標，后有您的 IT 系統。這兩方面都具有規模大、不易改變和靈活性差的特點。制定業務目標的人員和開發系統的人員不一定了解彼此的工作內容和成果。似乎是這樣，業務人員使用一種語言來表達他們希望實現的業務目標，而開發人員則使用另一種語言來表述技術要求。
而這就是我們為了實現高效率而需要著手處理的問題：理解這兩種語言并執行必要的轉換，以便 IT 能反映業務的需求，并能在適當的時候對業務目標進行更改，使其與 IT 的能力相適應。這并不是一個容易完成的工作，但這正是您能夠獲得很大利益的原因。
由于這部分工作可能會非常困難而棘手，因此，我們向 IBM 體系結構專家隊伍尋求指導。本月我們邀請這些專家分享他們用來將業務需求表述為明晰簡潔的技術要求的方法，以便 IT 團隊能成功地實現。
我們在此提供的內容談不上全面。本文的全部內容都是在討論如何將業務需求轉換為技術要求，但關于這個主題還有很多可說。每位 IT 架構師對此問題的答案的關注點都或多或少有自己的特別之處，沒有任何答案能滿足所有人的愿望。不過，我們的專家將為您指明有用的方向，以拋磚引玉，我們相信這可以幫助您找到本月的問題的最恰當答案。
再次感謝我們的供稿編輯 Holt Adams，您將在下面讀到他對本月討論的問題的看法。
歡迎每月閱讀 developerWorks IT 體系結構方面的精彩內容：如何將業務需求轉換為 IT 要求這一主題是本月要討論的話題。
我們也歡迎您就本專欄未來的發展方向給出您的意見和建議。您有需要我們的專家團隊回答的問題嗎？請將您的問題發布到我們的 IT 體系結構討論論壇�；蛘�，通過以下郵件地址與我聯系：pdreyfus@us.ibm.com。
Paul Dreyfus，編輯
developerWorks SOA and Web services
pdreyfus@us.ibm.com
另：為了顯得沒有偏袒，讓討論自然地展開，我們本月按照姓名的字母降序對供稿人的回答進行排列。（仔細閱讀過第一期專欄的讀者會發現該期的供稿人是按照從 A 到 Z 的順序排列的。）
一個詞：用例（哦，兩個字）
用電影畢業生 (The Graduate) 中的方式來說，我只想對你說一個詞：用例。（哦，那是兩個字。）很多年來，我們都將用例用于對應用程序進行建�！，F在，在面向服務的體系結構 (SOA) 中，我們也使用這個概念來對業務進行建模。
在 Alistair Cockburn 的 Writing Effective Use Cases 一書中，他將用例定義為“系統干系人之間就系統的行為達成的協定”。用例必須適合所定義的系統范圍，能夠代表此情況下使用系統的主要參與者的觀點，且能夠在一致的抽象層次上表示參與者的系統使用情況。
例如，股票交易 Web 站點的一個用例是“購買股票”，允許用戶通過此站點購買股票。該用例描述了客戶進行何種操作以及站點如何響應，而暫時忽略了站點將如何實際實現此行為。
 |
|
可以將用例用于對服務進行建模；我將此稱為服務用例。當用例描述服務時，參與者就是服務使用者，而系統則為服務提供者。與任何用例一樣，此時的重點是服務提供者提供何種行為，而不是如何實現該行為。（有關服務用例的更多信息，請參閱我的 developerWorks 文章“通過服務模擬來簡化 SOA 開發”。）
還可以將用例用于對業務進行建模。在業務用例中，參與者是干系人——業務用戶（如客戶或員工，甚至股東或政府監管人員），而系統則是業務本身（生產產品并將其銷售給客戶的公司）。您的業務如何開展？客戶希望您的業務如何開展，他們愿意為何種服務或產品付費？員工需要業務如何開展才能完成各自的工作？關鍵在于：這些干系人如何與公司進行交互？這些都是業務用例。
獲得了業務用例后，則可以隨后將其鏈接起來，以形成業務流程——公司可以執行的過程。這些流程本身就是業務用例，而復雜的業務用例可以被視為業務流程。簡單地講，這些流程顯示了公司要做什么以及如何做。如前面所述，流程以及每個流程中的步驟都對服務進行建模。
通過用例將公司（或公司的一部分）建模為由服務組成的業務流程后，隨后的目標就是盡可能多地實現流程和服務的自動化。（無法實現自動化的就是需要人工完成的任務。）實現這種自動化的應用程序（實現流程和服務）是采用面向服務的體系結構的應用程序。而您現在正在進行 SOA 實踐。
記錄流程
當我坐下來和客戶討論新程序或開發工作時，我會立即了解業務干系人是否出席，或是否派了代表出席。然后，我會希望得到記錄良好的業務流程和數據要求。除非相關工作是一片“處女地”（即之前從沒有進行過此類工作），否則一定會對新應用程序或功能支持的原有的業務流程和將來的業務流程有良好的理解。不管采用哪一種方式，如果客戶不了解業務，架構師有效定義系統要求的幾率都很小。
我個人非常贊同開發業務場景來記錄業務流程。業務場景允許您在整個業務問題的上下文中標識系統要求。The Open Group 提供了一本非常出色的的小冊子，用于幫助了解和開發業務場景，書名為 Manager's Guide to Business Scenarios。
|
|
確定了將來的業務需求后，如果能維護一份功能和非功能行式項目要求的列表，也很有好處。您可以使用電子表格來維護此列表，但如果想要盡量保持要求的可跟蹤性和根據優先級或類別管理各種要求，則這種方法就顯得不合適。我極力贊同使用工具來管理要求；為了達成此目的，我建議使用 IBM Rational® RequisitePro®。
通過使用根據業務場景確定的初始要求集，我們就可以開始定義系統行為的過程了。為此，您可以召開聯合應用程序開發（Joint application development，JAD）會議，以便根據一系列初始行式項目要求來充實將來的系統。通過 JAD 會議，架構師可以與干系人一起確定期望的系統行為，并以此為基礎記錄用例和場景。通過對用例和場景進行細化，可以幫助定義最終的一系列功能和非功能要求。
從一開始就使用 RequisitePro
Rational RequisitePro 是一個沒有得到足夠重視的 Rational 產品，該產品用于收集、記錄和細化需求和其他業務概念。它允許業務用戶在 Word 文檔中編寫聲明，然后將其捕獲到數據庫中，并將這些聲明與用戶定義的其他屬性相關聯。這些聲明可以描述需求、策略、用戶角色、干系人以及與業務相關的任何其他內容。
使用迭代需求細化流程時，可以在相關聲明之間建立聯系。例如，需求“Portlet 顯示 X、Y 和 Z 客戶信息”，可以與另一項需求“角色 A、B 和 C 應接收所有必要的客戶信息”聯系起來。在這種情況下，第一項需求是第二項需求的細化。這樣就對一般需求和詳細需求之間的關系進行了建模。
|
|
在我個人看來，您應該在建模階段一開始就使用 RequisitePro。RequisitePro 中管理的聲明可成為建模工具（如 IBM WebSphere® Business Integration Modeler、Rational Sofware Architect (RSA) 或 Rational Software Modeler (RSM)） 的輸入。事實上，Rational Sofware Architect 和 Rational Software Modeler 都提供了將 RequisitePro 需求顯式地鏈接到用例和其他建模元素的功能。您還可以將需求鏈接到 Java™ Java 2 Platform Enterprise Edition (J2EE) 和其他類似的實現構件。通過此功能，您可以獲得各種問題的答案，如“當更改此項業務需求時，為了與其相匹配，必須對模型或實現的哪些方面進行相應的更改？”
最后，在讀過了 Simon Johnston 所提出的觀點后，我希望補充一些內容：
我最近組織了一次理解“策略”概念的工作，了解什么是策略，以及它應該如何適應 IBM 的系列工具。通過這項工作，得出了以下定義：
- 策略 是在一定業務領域內以實現特定業務目標為目的的聲明。此定義與說明和其他相關材料中強調的業務意圖是一致的。
- 聲明 是以某種人類語言表述的語句。因此策略與 RequisitePro 的適應性非常好；就某種意義而言，策略就是一種需求。
策略是通過一個細化流程制定的，該流程以高級策略聲明為基礎進行，而這些高級策略聲明通常不能直接實現；這些高級聲明將通過迭代方式細化為更為詳細的策略。然后，可以通過使用我前面描述的 RequisitePro 功能將完全細化的策略與實現工作聯系起來。Simon 所說的“連續體”與策略生命周期這個觀點是一致的。
Calvin Powers 完成了一個基于 Web 的相對不錯的演示文檔，演示了可以如何將 RequisitePro 用于捕獲和細化業務策略。請訪問 IBM Business and Technology Solutions Resource Library，并在 Demos 部分查找“Policy Provisioning using IBM Rational RequisitePro and IBM Workplace Business Controls and Reporting”。
正確功能的正確解決方案
我很喜歡 Kerrie Holley 對本月問題的重新表述：“我如何從業務意圖轉到已實現的價值或 IT 解決方案？”開發和設計解決方案的體系結構時需要考慮的最重要的事項之一就是所需的對應功能和容量級別。如果我所做的只是將價格信息發布到網上，我可以到最近的小學里找個人來編寫 HTML。不過，如果我是 Wal-Mart，而我要做的是嘗試采用多種語言跨越國界擴展我的供應鏈，并確�？梢匀旌虻卦L問，那么我的功能和容量就必須更為可靠。
經驗豐富的專業人員可以幫助客戶將業務需求轉換為業務意圖。業務意圖更為模糊，但更與“基本需求”和“投資回報”一致。確定了業務意圖之后，就可以通過創新且可重復的 IT 解決方案獲得實現的價值。
和 Kerrie 一樣，我相信業務需求和 IT 功能存在重疊。正是由于這個模糊不清的界線使得體系結構設計成為了一個困難而費時的過程。不管是采用瀑布式還是迭代方法（我們喜歡后者），規劃和需求分析階段始終都很單調乏味�？蛻艉苌僦浪麄冃枰裁矗ūM管很多人知道他們希望得到什么）。經驗豐富的專業人員有責任幫助客戶將業務需求轉換為 IT 功能。
|
|
這并不能通過只使用良好的工具和方法來實現，因為每個項目都是獨特的。方法和技術是指導方法，而工具則用于幫助實現這些方法的自動化。雖然很多項目都具有共同之處，但他們彼此完全一樣的情況卻很少。假設它們彼此相同就是假設兩個完全不同的業務彼此完全相同（雖然有一定的相似性）。我過去曾和 Home Depot 及 Lowe's 進行過大量合作。盡管這兩家公司相似，但他們都會告訴您各自的業務具有獨特性。而他們都將這些不同之處視為他們的競爭優勢。很多時候，文化、地域和地理位置對業務需求的影響決定著所建議的 IT 解決方案。政府法律法規和標準可能要求技術人員根據部署解決方案的場合對相同的業務需求采用不同的方法來設計解決方案。
捕獲和交付構件的技術——用例、場景文檔、Rational Unified Process (RUP)——應當在參與的客戶中一致地實現。如果在項目進行中，客戶改變了主意（業務需求）和決定，例如系統不需要 24x7 的可用性，而只需要 8x7 的可用性即可，因為他們不希望承擔 24x7 解決方案所帶來的高成本，您仍然可以很好地使用這些構件。