雲端運算：當您已經從入門的開始的位置

SOA、SaaS 和雲端運算的相關議題和所製造的機會，事實上增加了商務與 IT 之間的溝通隔閡，部分是因為新興的架構和技術所致。 尋找將這些新模型所呈現的技術機會與組織的需要相連結的相關指引。

Ric Merrifield 和 Dennis Stevens

比較來修復中 mid-flight 飛機的主要業務變更是很好的比較複雜性、 風險和中斷，方面與增加的焦點放在服務導向架構 (SOA)，與相關的機會軟體為-a-服務 (SaaS) 和計算比較可以開始看起來像毛利 understatement 的定域機組。  在就實際上大多數組織現今遇到衝突發生的兩個重要的但 oftentimes 競爭的目標：

如組織成人，通常透過自然的成長和擷取的混合不同部門]、 [部門]、 [群組，] 及 [公司會變得像筒倉的多個獨立而，導致龐大的努力及燃料混淆的重複時嘗試向客戶、 合作夥伴和員工中說明的所有項目。  大部分的組織今天搜尋更大的透明度，其呈現更一致的努力及訊息的所有項目從任務，客戶，其價值論點，它們進行每日的活動的方式來組織內。

新技術會跳出每日]、 [主要] 會將會很少，] 和 [許多人辨識出示定域機組的機會運算是這些主要的班次，很多組織都煩才能履行承諾，運算的競爭者之前的定域機組的段。

如您所預期，組織是否飛彈筒倉 ’d 和跨不同的群組中缺少可視性，機會 maximization 會變得更複雜。  您是否先統一，然後將有機會在最大化吗？ There isn’t time for that in many cases. The right answer right now is to continue to aggressively pursue both goals, but with an eye on intelligent prioritization. Unfortunately, that’s a lot easier said than done today – most organizations lack a view of themselves, a “lens” that enables them to efficiently and objectively prioritize on the unification side, which makes the opportunity maximization efforts almost doomed from the start. Why is this?  There is a gigantic communication divide that spans the various organizational groups, including the information technology (IT) department. At the heart of this communication divide is something that has been called ‘the “how” trap’ and that is discussed in greater length in Section 1 of this white paper.

Now back to SOA, SaaS, and cloud computing. The issues and opportunities surrounding SOA, SaaS, and cloud computing effectively amplify the conversational divide between business and IT, in part because of the newness of the architecture and the technology. The business is going to look for ways to offer new capabilities and services to both new and existing customers that will be great new sources of revenue, and create further competitive differentiation. At the same time, many will consider migrating legacy technologies to cloud services to give new and existing customers more options in such areas as security, speed, access, and personalization. The business is likely to provide the IT department with detailed “requirements” that include significant customizations to packaged or already custom software. As we explain in the body of this white paper, if an organization hasn’t yet gotten itself out of ‘the “how” trap’, IT will typically create overly customized, more-expensive-than-they need to be services which will erode the potential profitability of these new models and ultimately slow the organizations efforts to achieve its strategic goals. 

但是正如那里需要會更清楚地查看更客觀的 articulation 的需求和組織的優先順序，也需要有清楚的瞭解如何這些新的模型 (SOA，SaaS，定域機組的運算，並) 將補充現有傳統的 IT 解決方案和架構 (回至 mid-flight 中修正 [平面])。  連結技術的機會提出這些新的模型，來組織的需求是很重要的也就是本白皮書中所提供的指引。

在區段 1，我們討論更多關於取得超出 ‘ 「 如何 」 設陷 ’ 透過功能模型和熱對應。  區段 2，然後提供指引，以在商務需求和專案優先順序排列的熱度對應的角色。 在我們進入什麼 SOA、 SaaS 和計算平均數，] 和 [機會]，及風險種類的定域機組的區段 3，它們呈現給 IT 和業務。  區段 4 包含定域機組應該要顯示基本的裝載的方案的優點是商務運算的案例研究。 結論區段所建議如果您考慮定域機組運算，只是技術解決方案/機會您會希望太 Low 值的成功新增企業。 直到套用您透過 rigor 取得的分析的 objectivity 和專業領域的商業功能您都不明確連結策略和組織的戰術技術風險會明顯。 我們關閉使用某些特定的想法下, 一個步驟，可供這個討論區的資源上。

我們相信這份白皮書提供清楚的指南作為第一步，幫助組織自己喜歡的繼續將焦點集中在統一，並在一個大有 [機會] maximization 多化目標，並 disciplined 比在過去有經驗的方式。

取得超出 ‘ 「 如何 」 設陷 ’ 功能模型與熱度對應

Before we leap into these opportunities in technology and architecture let’s first call out a reality that exists in many organizations; the business side of the house isn’t interested in the specifics of the technology (even though they know more and more about it every day), yet they set specific strategies that translate into specific tactics, and quite often those require technology. However when the discussion about the specific role of technology in supporting the tactics and strategies of the organization, much like a patient describing a pain to a doctor, the business will often include details that may or may not be relevant to the specific problem/opportunity. In the case of the doctor/patient relationship this typically works itself out because the doctor is trained to filter out what is and isn’t likely to be relevant to what the patient really needs. By contrast, in the business/information technology (IT) conversation, because the IT people aren’t experts in the business, they aren’t as able to see which details aren’t relevant and as such will often do many things that the business asks for that don’t translate into much value. 這 isn’t 因為人們 aren’t 智慧或他們 aren’t 硬式處理，因為它們通常逐字 don’t 說話相同的語言，它 ’s。

如何設陷

At the root of this conversational divide, is something that has been called ‘the “how” trap’ and it affects us all. People often become so attached to “how” they do something (like sending a fax), that there description of their work often masks “what” they are doing (communicating the status of something is more likely to be “what” is being done, and the fax is the “how”). The “whats” that make up an organization are what we also call business capabilities (this is examined in greater depth in an article we co-authored with Jack Calhoun in the Harvard Business Review called The Next Revolution in Productivity). We have found that identifying the various business capabilities in an organization to be an excellent first step in getting to a far clearer, more objective view of the work that makes up the organization, and this work is fast and most people enjoy it. From there adding pieces of information about the areas that are most and least valuable, performance, and maturity can lead to highly objective and efficient discussions about work prioritization, especially when business value is an element of the conversation. This is a first step that we recommend for most organizations. 而不是 embarking 上一個月長對應的整個組織，我們建議組織開始在區域或部門的層級，具體的這種方法與不同之處，較小，和補強、 其他方法可能使用如重新設計，處理程序]、 [lean，] 及 [名稱到六個 sigma 幾個。

有關 SOA、 SaaS 或定域機組運算技術或偶數的架構以開頭的任何對話太低希望成功。  重要的第一步的兩個 IT 和業務是以離開 ‘ 「 如何 」 設陷 ’ 和好消息是它 doesn’t 花很長的時間。

大部分的我們在此的車有 「 為什麼我們將這種方式嗎？ 」 的交談，也就是人取得附加到 「 如何 」 他們取得最愛的目的地時很少重要完成結果或取得有時間上的目標 「 如何 」 的結果。  它不 ’s 的人都笨，它只是 ’s 我們通常覆蓋 「 如何 」 我們執行動作的方式開始遮罩實際 「 什麼 」 目標，讓它更難以認為的任何其他方法，就可以達成目標。

Nowhere is ‘the “how” trap’ more common than in the workplace, and examples are the best way to illustrate that. If you are trying to collect business requirements for a specific part of an organization, and not knowing anything at all about the organization you decide to walk up to a person at the fax machine sending a fax and ask them “what” they are doing. The response you are most likely to get is “I am sending a fax” and in that situation most people are likely to have follow up questions like “Is sending a fax a necessary part of the work you do?  Do you have to send a fax to successfully complete your work?” and the answers are most likely to be “yes” which will lead the person to capture “send fax” as a requirement.  

But it isn’t. The requirement, “what” they are doing, in this case is something more along the lines of “communicate status” or “confirm order” and “how” they are doing it is with the fax machine. So if you then go back to the person having disentangled the “what” from the “how” and ask if it matters “how” it gets accomplished, the worker will typically see that it doesn’t matter, and which has already transformed the conversation about requirements. The “whats” that make up the requirements of the organization are what we call its business capabilities and capturing the business capabilities is an effective and efficient way to get people out of ‘the “how” trap’ and that is an important first step in getting to the thermal diagrams we call heat maps.

值效能圖

那麼何謂出的第一步 ‘ 「 如何 」 設陷 ’？ 大型組織所組成的商務的功能和經過一段時間的千分位的商業功能的庫存應該但現在需要更多的圖形，組織應該識別兩件事之一：

識別具有最大的商務值的商務功能 所定義的三個平均加權測試 (和所有三個這些測試 – 範例，商業功能 「 支付員工 」 失敗時是必要，它已成功地執行，並且相容，但失敗的所有三項測試)：

• 它不會影響的品牌或方面為什麼客戶、 合作夥伴和員工與您的商務組織的身分識別。  這是其中一個人建立關聯與貴公司的事嗎？  (可以是/不正確高/媒體/低或 1-5)
• 沒有這個工作連結，直接到組織的關鍵效能指標的效能 (是/否)
• 改善這個特定的商業功能的效能 (是/否) 有值

**識別具有最低的商業價值的商業功能。**雖然這看起來可能 ； 令人驚訝，這是許多剪下彙總，及外包的成本最高的機會出現的位置。  即使這並不是主要的任務在我們建議某些的工作一開始，因為使用任何新的方法的前，或可方法會包含一些課程中學會，並取得工作的低值區域中學習到的經驗是組織的更高的值區比多較低風險。

因此查看工時及區域離開 「 如何 」 動詞命令和工作，從具有建立保險報價幫助保險公司下方圖形說明的 「 如何 」 的動詞命令的識別。

為一個另外，請注意在與 「 無 」-右到左的對應動詞命令 「 自動化 」，是因為自動化兩者都不是 「 如何 」 動詞命令也沒有 「 什麼 」 動詞是第二個 「 如何 」 動詞命令的描述，以及應小心這些討論區。

從這裡下, 一個步驟就是引號的商務的工時所構成的保險建立的 「 whats 」 功能的檢視的文件：

這本身 isn’t 移至 「 哇 」 多人為的組織中，但當您詢問有關商業價值，每個區塊，包括父系 「 建立報價單 () 」 的一個保險的引號的工作的人員，並再也要求每個執行的方式，您可以色彩每個商務] 功能，紅色色階 ([粉紅] 和 [紅色]) 是您注意的旗標 (高的價值和效能不佳在這種情況下) 而綠色的網底建議相反 (低的值，已順利執行)。

This is where the conversation starts to get significantly more objective and interesting. Now you can objectively ask which “child” business capabilities will cause the parent to perform better, and in this case, where the parent has a yellow “Fill” color that indicates medium business value, just because the child “Create Certificate” is high value and the lowest performing, you may be able to ignore that problem because the parent isn’t very valuable. This is where the big impact of doing a business capabilities analysis comes in, which opens the door to more objective business prioritization, which then leads into the maximization of an opportunity such as cloud computing. But we are now getting ahead of ourselves.

如何使用熱度對應為輸入優先順序排列討論區

在我們的修復中 mid-flight 飛機的類比，我們反白的 ’s 不切實際一次修正所有項目，而您仍在進行的所有工作。 我們必須著重於最重要的問題，以最大化我們的結果。 只有我們已排定優先權問題後，我們應該開發和範圍的解決方案。

在區段 1，我們討論取得超出 ‘ 「 如何 」 設陷 ’ 使用功能模型和熱對應。 熱量分佈圖呈現您的業務方面的 「 內容 」 執行及顯示商業價值，以及每個商業功能的效能。 在開發這些熱度對應的重要層面，是商業和技術人員應該有提供。 讓我們已經開始交談。 我們要如何在我們的優先順序排列討論區使用熱對應？

優先順序排列

排列優先順序是一大挑戰。 大圖片、 共用時進行優先權決策的全面性檢視，實際上會呈現熱量分佈圖。 當按優先順序排列您的努力與投資有考量的數字。 大部分的考量可分為三個類別之一：

• 增進效能
• 降低成本
• 地址業務風險

第一次，如何可以在熱度對應會告訴我們，投資以改善效能的位置嗎？ 檢閱父功能。 識別這些最有價值的商業功能，但 underperforming。 這會顯示值效能間隔的投資會導致組織更佳的效能。 這包括識別潛在新商業功能的例如定域機組的運算。 這些是您填滿 (值)] 和 [框線 (效能) 都是紅色的網底的熱量分佈圖中的作用。  釐清一個次要的點，實際上 doesn’t 無論它是 [填滿色彩相對於。 框線的色彩，但我們會被一致此處為避免混淆，這份文件中。 在作用區顯示最重要的效能差異。 這些區域需要注意並改善效能的投資，而且通常應該只有 10-20%的清單。 非常快速的地藉由 「 接聽 」 擁有者與工作的業者我們有客觀地優先順序我們的父商務功能，只有這些重要幾個商業功能的清單。

現在我們需要範圍我們的需求。 考慮優先順序清單上找出 「 子系 」 商務 capability(ies) 在最需要注意的每個 「 父代 」 商業功能更深層的外觀。  最簡單的用語，這是有關原因 – 哪一個子/子系有/有父代的效能上最大的影響？ 我們在這裡的焦點將會對效能。 為什麼呢？ 大多數的商業功能可分類中的三種方法之一：

• 加值型
• 控制
• 支援

通常，只將加值投稿至值直接 (和它們通常是 「 」 的原因效能其父代的)。 控制和支援功能都需要確保執行較高層次的加值型的商業功能。 在任何這些類型的 「 子系 」 商業功能的效能不佳，可能會導致 「 父代 」 層級的效能不佳。   為一個另外 – 一樣重要，因為尋找效能，原因大部分的組織必須啟動在判斷提示層級 (其中有 isn’t 確實 「 原因 」 的效能的絕對方式)，但我們的經驗中過多的良好的知識和經驗，在組織中 (等候取得解除鎖定與這類的鏡頭相同)，因為初始的判斷提示是非常正確。

使用數值效能熱度圖

熱量分佈圖也顯示的區域，我們可以在其中新增透過剪下彙總及外包的成本值。 最好的方法就是商務功能，以最低的商業價值的識別。 這些是功能熱量分佈圖上有綠色填滿 (值)。 如果這些執行良好或不 – 它們是低值，所以無法核心，所以請考慮將其外包給人可以更，執行這讓這核心能力，以便讓您可以專注於什麼是對您的組織最有價值的人。 如果這些執行良好或甚至 over-performing，查看改善效率、 削減成本 – 和縮小到什麼 ’s 最重要。 而且，請考慮合併彙算的服務。 有真正需要有多個系統和 「 支付員工 」 部門嗎？  這是更容易看到一旦我們克服 ‘ 「 如何 」 設陷 ’ 並說明我們做方面的用途和結果的 「 什麼 」。 因為我們已經判定這是必要，但較小的商業價值的實作詳細資料會比較不重要的 – 逐字 doesn’t 無論它人不會 (或多少人這麼)，發生的地方技術為何，或處理程序是，只要它符合效能目標 (包括相容性)。

熱量分佈圖提供一個架構，以及處理風險。 我們更詳細地進一步 3 節中討論的。

我們已使用 「 什麼 」 鏡頭，來通知您的組織需求呈現使用熱量分佈圖排定優先順序，並在範圍的問題的方法。 下一個步驟是要考慮新或未來狀態 「 如何 」。 這需要對話、 條例的分析和解決問題。 結果現在是主要的問題，並達到未來狀態的開發案的清單。 這份計劃可能涉及程序改進、 訓練或技術。 我們下一個單元呈現方式 SOA，定域機組運算和 SaaS 提供新的工具，可提供通常優越的解決方案。

請務必了解是不同的問題和解決方案。 這聽起來很簡單，但可以亂討論區的過程。 本單元中，我們有所描述一個由上而下分析。 我們在這一節中所述的問題的優先順序的清單會變成主要的輸入在解決方案的優先順序。 當我們辨識其他計劃已在播放中或之下的考量，這就更為重要。

我們如何優先順序的開發案您現有的清單？ 熱量分佈圖可協助我們與相關的問題與解決方案。 識別商業功能的每個方案的目的是要改善。 它不會解決作用點吗？ 請記住這些是通常需要改進效能的區域。 剪如果 「 」 開發案的焦點成本剪下，我們可能想要更仔細的是 – 檢查，因此，就例如成本剪下良好時成本下要提供足夠的價值來左右對齊的投資，並使受干擾嗎？  我們確定我們 aren’t 剪下成本不足的一個高值商業功能，而且如果是，都是我們確定，’s 智慧呢？ 另一個可能會解決 (方面商業價值) 的綠色的商業功能。 我們正在尋找此處降低成本。 如果焦點在計劃的效能改進我們可能要重新瀏覽我們的商務案例。 我們真的需要有能力在五分鐘，而不是一天的 「 支付員工 」 嗎吗？ 有當然更重要的區域，以改善效能。

熱量分佈圖提供重要的優先順序排列討論意見。 我們可以識別並按照優先順序排列這些商業功能，效能、 成本，或風險問題，並需要注意的。 進一步幫助商業功能的分析，問題的範圍。 現在，我們知道我們注意把焦點放的位置 (及在何處不到)，並且可以考慮如何使用 SOA、 SaaS 和計算傳遞優越的解決方案的定域機組。

執行摘要中我們會討論有關的統一及機會 maximization 競爭的目標。  我們的經驗中使用熱度對應會是更戰術或細微層級的磁碟機對話內容的方法，以便統一和機會 maximization 之間的取捨，請評估中清楚且客觀的詞彙，而不是繼續在沒有東西因此客觀的交談的一些更個別議程，更主觀排序。

識別方面什麼是傳遞給達成商務策略所需最小的範圍，可以大幅提升您的 SOA Saas，商務報酬並盡最大努力定域機組。

SOA、 SaaS 及 [企業的運算機會，] 以及 [風險] 雲霧

第一個 let’s 看看這些條款的表示。 SOA 或服務導向架構是架構的樣式或的業務的思考方式和 IT 根據鬆散結合、 黑箱元件 orchestrated 傳遞的服務定義完善的層級。  SOA 是架構，它不是技術 – 許多不同種類的技術可以支援 SOA 架構，就像許多種類的建築材料可以滿足一棟建築物架構的需求。

SaaS 或軟體-為-a-服務，只是指透過網際網路所提供的軟體啟用服務。  SaaS 是一種傳遞完成 SOA 架構願景的技術解決方案。 訂閱為基礎 (操作成本) 上 SaaS 提供先期的資本投資的軟體授權，並將它與一般基礎結構。

運算的形式賜予的定域機組是直接透過網際網路的電腦技術的使用。  定域機組運算啟用使用者和開發人員可以利用不知情或 IT 基礎結構，這些資源的控制權的運算資源。  資源是虛擬化，並提供從網際網路傳送。

此模型的消耗做為服務的軟體可由供應商中傳遞給客戶，以許多不同的方式 ； 內廠商自己的內部 IT 環境，在一個虛擬化裝載在定域機組環境等的環境。  SaaS 不需要透過定域機組，才能視為 SaaS (雖然定域機組會讓商業概念的許多 SaaS 廠商，讓他們將重點放在建置到應用程式與建置及維護 IT 基礎結構的商業價值) 中傳遞。

SOA、 SaaS 和雲霧運算的優點

SOA]、 [SaaS，] 與 [雲霧電腦可讓您以四種方式支援企業的 IT 群組：

1. 改善效率和磁碟機的焦點-SOA 是我們在第一次機會位置，在大多數的情況下，技術實作可以會討論有關為企業的思考的相同層級。 瞭解並建置更準確的說什麼企業需要可量化、 可測量區塊中會導致獲利的傳遞。 提供透過 SaaS 和計算可協助的定域機組的 SOA 上組織焦點放在什麼 ’s 最重要的 empowering IT 管理，才能有效地將服務和值傳遞給客戶 (內部和外部的組織)。 雖然大部分的組織 expend 大量的資源，在建置和管理他們自己的技術基礎結構的組織運用定域機組中計算 don’t 必須部署、 管理，及技術基礎結構的縮放比例著重寶貴的財務，開發和 IT 資源。
2. 提高靈活度-服務時所設計，並有效地實作有高層級的互通性。 這表示它們可以撰寫與其他服務來提供新的服務。 整合現有的服務，從外部的提供者，或同時使先前隔離的平台，可以傳送新的解決方案。 能夠在過去聯盟隔離的平台，並撰寫新的服務運用現有的服務讓 IT 管理與開發小組在企業和客戶需求的變更快速回應]。 這會導致能夠採取更快上市的了解。 基礎結構可以快速配置來滿足不斷增加的流量 / 採用要求透過簡單的要求。 這提供複雜的操作程序沒有不著痕跡地向上及向下擴充能力，以及能夠不必花向下升級服務。 這是更可縮放比傳統的上場所解決方案涉及獲得]、 [安裝]、 [測試] 和 [硬體、 軟體、 網路，及儲存基礎結構。
3. 提供更佳的效能和可用性的則為 True 的定域機組的平台提供全球、 地理位置分散式資料中心、 資源和大幅超過擴充性、 效能、 可用性、 備援、 最佳作法和安全性中任何的組織的平台可以合理地完成自己的資源。 只在使用定域機組可以讓企業在焦點放在什麼是最重要的定域機組運算的提供者可以提供最佳品種的服務管理和個別的公司無法傳遞的高可用性解決方案。
4. 說明組織餘額的彈性和控制-加持定域機組的平台，應該選取應用程式 – 最佳的部署模型的組織是否自己定域機組的提供者或 2; 的組合所裝載的伺服器上裝載幫助開發人員和服務管理員來組合上場所和定域機組的資源，以解決商務問題。

這些技術的優點提供企業的新機會。 先，公司可能計劃，以保護，並以改善或透過傳統系統擴充服務內容相關資訊，透過聯盟成長營收。 就例如金融服務公司一直都能夠取得新的客戶，因為它能夠呈現的最佳品種解決方案無法使用在市場中合併的解決方案。 它們是可以進行這項目，不是藉由撰寫全新的系統，但聯盟 SaaS 實作透過現有的應用程式。 第二個，公司可能會改善其企業靈活度，透過組合目標服務內容相關資訊，或快速地加入 [透過合作關係] 與 [交互操作性的新功能。 最後，公司可以逐漸降低 IT 成本移動相當昂貴的功能和定域機組的環境，並排除多餘的實作的企業內的功能。

SOA、 SaaS 和雲霧運算風險

除了新的機會新技術和架構方法將相關的有效地設計、 建置，和傳遞服務的相關風險。

1. 商業風險 – 統一和機會 maximization 之間的衝突反白顯示的界限的有效識別和服務盡最大努力的焦點的重要性。 無法取得或開發每個服務的特定商業優點上有一個焦點可以實際上會增加而不提供預期的商業利益成本。 就例如建置或取得提供一個廣泛範圍的人力的資源管理能力的 SaaS 方案不會有價值除非沒有下執行的功能或新的服務所傳送的明顯的成本改進。 方案可協助保護和成長營收、 改善企業靈活度，或降低 IT 成本，除非它可能不是企業在焦點的右邊的區域上。 熱量分佈圖提供經證實的方式來使用組織，以降低企業風險。
2. 設計風險 – 設計 don’t 履行承諾，鬆散結合、 黑箱元件 orchestrated 傳遞明確定義的層級的服務的服務將會限制可以達成企業最終的優點。 建置 don’t 配合商務模型的服務將會限制 IT 商務的對齊方式。 無法依照支援互通性、 自主權，鬆散的結合性和 Composability 的設計原則會限制敏捷性、 可用性及效能潛在的服務。 請考慮如何緊密相連的商業功能是給其他人。 愈高的層級 interconnectedness 在商業或技術實作等級更困難就會建立獨立的服務。  而且，了解是否有明顯的相容性需求，公開為服務的商業功能。 就例如存取 PCI 資料的服務可能會被設計來改善遵守隱私權法規 – 但如果這 isn’t 視為然後公開這些服務可能有問題的層級。  產生的熱量分佈圖的一部份應該評估與功能相關的商業和技術風險。
3. 開發風險-有新的技能，並順利建置服務相關聯的開發程序。 若要取得商業和技術的優點，SOA、 SaaS 及定域機組的運算開發小組必須有分析、 設計，和開發適當的技術。 有一些新的工具、 新的部署模式和新的實作風險，必須了解並降低。 確保適當的訓練，環境和合作關係會建立早期建立適當的能力和基礎結構所需降低開發風險。
4. 傳遞風險-Finally，實作 SaaS 和計算需要大量的投資在基礎結構、 新的技術處理序和新的開發技術的定域機組。 計算可以大幅減少同時減少相關的風險的初始成本運用的定域機組。

一個雲霧運算個案研究

既然我們已經討論有關模型，商務功能，並熱度對應和如何幫助他們可以幫助決策的優先順序與相關來統一及機會 maximization 現在我們要逐步執行一些實際的公司，實現某些定域機組運算沿著什麼我們談的相關區段 3 中的策略的優點的細節。

在我們案例] 研究，我們會有實際的公司有數千名員工提供了幫助企業和增強其內容的公用磁區客戶的軟體開發服務的印度基礎。  我們會呼叫此公司 Contoso，和加上如果有些時候會變成重要了解實際的公司及人員名稱引號，讓我們知道，我們可以將之方法，看看它們是否能輕鬆地共用他們的實際名稱。

大小寫摘要

在這種情況下 Contoso 選擇透過 Microsoft ® 資料中心在網際網路上傳送它的應用程式使用 Microsoft Windows Azure ™ 平台。  值得注意此時雖然運算解決方案的定域機組的其他技術選項我們無法說話其他解決方案是否會傳遞相同 Contoso 在此特定的情況下所達成的成功與否。

好處

• 簡化應用程式部署
• 有彈性、 符合成本效益的延展性
• 降低成本
• 快速、 廉價的開發
• 增強的業界特定 (在此案例的政府) 服務

概況

Contoso 系統 headquartered Pune，印度，並在亞洲、 歐洲和北美地區的作業，提供廣泛的客戶在電信、 生命 sciences、 資料的基礎結構和政府磁區的軟體產品開發服務。 超過 6000 的員工與 Contoso 系統提供了幫助加強他們的產品，同時降低整體成本其客戶的服務。

Contoso 系統 ’ 的主要功能，是 e 政府的方案中提供區域和區域的政府機關以及機構提供服務，以及與市民和以電子方式是透過一組四個 Web 應用程式在公司呼叫其電子控管套件的企業互動的能力。 套件會形成公用服務，一致的解決方案，和包含抱怨解析度、 道路和基礎結構、 census 和選舉管理系統。

Grievance Redressal 系統允許註冊和追蹤事件報告任何政府部門的市民。 使用 [道路和基礎結構的應用程式的市民可以報告與道路和基礎結構，相關的問題識別與線上對應工具的特定位置。 已註冊的醫院、 醫生和其他授權的人員可以使用 Census 部門應用程式註冊 births 和 deaths。 選舉 Office 應用程式互動，以維持最新的 Voter 清單和說明的授權單位管理並排程選舉 Census 部門。

Contoso 系統開發電子控管套件使用 Microsoft ® ASP.NET 和 Microsoft SQL Server ® 資料庫管理軟體，以用戶端為主的軟體應用程式裝載在客戶自己 ’s 資料中心提供不同的元件。 但是，公司找到它的能力，來提升其電子控管方案已通常限於本機政府的技術功能。

印度，許多本機和地區政府缺少 IT 基礎結構需要完全部署 Contoso 系統 e 政府應用程式如場所軟體解決方案。 即使其中政府或機構具有可用來開發高效能的伺服器環境將資金，它們可能缺乏技術專業知識，以適當管理網路、 備援和其他可以新增額外的成本的基礎結構問題。 此外，它們可能不希望技術容量或需要而讓您專注於傳遞政府服務的專業知識。

Contoso 系統就知道其解決方案會加強這些政府 ’ 能夠提供服務。 公司需要將其電子控管套件傳送到本機的政府，而不需要進行大量投資，在新的 IT 基礎結構和人員的方法。 它想要提供客戶一方法，來調整解決方案，向上或向下，新增或移除元件應用程式容量，或所需的資料儲存 — 快速、 輕鬆地，並有效地成本。

公司想要提供 didn’t 已經有高效能的基礎結構來測試該的解決方案的方法的潛在客戶和它想要提供它們只是用於它們所的使用，支付，如使用它們的方式。 在此同時 Contoso 系統開發其電子控管套件已經有進行重大的投資 ； 它需要新的傳遞模式，可以有效地，發展而不必大幅 re-engineer 方案]。

解決方案

Contoso 系統決定要發展這種解決方案會裝載在資料中心透過網際網路上的其電子控管套件-有時稱為應用程式傳遞系統定域為 「 機組 」 運算。  公司選擇 Windows Azure ™ 平台、 一個網際網路比例定域機組服務裝載在 Microsoft 資料中心的可靠的高可用性和擴充性，以符合使用需求中的平台。

Contoso 系統使用 Windows Azure 定域機組服務作業系統、 開發、 服務裝載，以及 Windows Azure] 平台的服務管理環境提供其 Web 應用程式的要求上計算和儲存容量。  它會以服務使用 Microsoft SQL Azure ™ 資料庫來儲存和管理應用程式的資料和應用程式使用者可以儲存檔案，並在 Windows Azure 平台使用 Blob 存放裝置功能的影像。 與即時的服務，它們可以搜尋使用 Bing ™，資訊，並找出與企業的 Bing 對應的位置。

除了電子控管套件的 [四個核心] 元件 Contoso 系統將部署自己承租人佈建系統 (TPS) Windows Azure 環境中。 與 TPS，Contoso 系統將提供個別客戶 (或承租人應用程式) 的特定元件。 Contoso 系統將部署個別的 Windows Azure 專案帳戶上每個承租人應用程式自動找出與其他，每個承租人應用程式的每個承租人增強安全性和延展性。

與 Windows Azure 平台上部署方案 e 控管，本機政府現在可以支付只有他們需要在表單中的每月的訂閱，而不是事先投資上場所基礎結構中的應用程式。 Contoso 系統會使用 [TPS 管理稽核和帳單的個別 「 訂閱者 」，並與客戶能提供回應給系統管理員，如果他們想要修改其訂閱。 「 客戶 ’s 觀點它們有更多的彈性 」 說明在 Contoso 系統的資深專案管理員。 「 移，它們可以輕鬆購買額外的應用程式或停止應用程式並不需要 」。

Contoso 系統會使用 SQL Azure 儲存電子控管應用程式資料庫，並設定資料庫。 記錄檔中的詳細資訊和附加檔案上載的使用者，會儲存使用 Windows Azure 儲存體表格] 及 [Blob 存放裝置功能。 系統會使用服務匯流排功能在 Windows Azure 連接電子控管套件內的應用程式和應用程式之間共用資料。

因為 Contoso 系統開發 ASP.NET 和 SQL Server 使用其原始電子控管方案，公司開發人員就是能夠將套件移至 Windows Azure 平台，以最小的工作。 對於執行個體開發人員可使用移動現有的 SQL Server 結構描述至 SQL Azure 資料庫的 SQL 指令碼。 「 我們必須使用傳統上場所 SQL Server 軟體，因為我們可以儲存大量的時間移轉現有的應用程式，以 SQL Azure，」，顯示 Contoso 系統在技術指導人員。 「 我們可以最小化我們的學習曲線，並讓整體轉換非常平滑 」。

使用 Windows Azure] 平台 Contoso 系統可以同時降低資本支出本身和它的客戶提供本機政府其電子控管應用程式。 政府，可以快速測試和部署應用程式及小數位數向上和向下的依需要，只支付他們需要什麼它們需要時。 要開發輕鬆地，因為 Contoso 系統帶到其新的方案傳遞快速，模型市場和現在可提供更多客戶其電子控管應用程式。

azure 權益：簡化應用程式部署

由主控其方案 Microsoft 資料中心透過網際網路上的，Contoso 系統可以將其電子控管套件部署到 don’t 有自己 [伺服器] 基礎結構的客戶，以及公司可以提供裝載的方案，而不必設定自己的基礎結構。 未來的客戶可以評估方案，而不必部署在應用程式上的場所，以及 Contoso 系統可以提供給新客戶的應用程式使用新的系統更快速大約 50%。

「 Windows Azure，與我們可以部署給新客戶的應用程式非常就輕鬆同時降低我們負擔大幅，」 指出資深專案管理員。 「 試用版執行是很容易的。 客戶可以只為試用版的使用者訂閱一個的月和的 ’s 它 」。

azure 權益：有彈性、 Cost-Effective 延展性

因為 Microsoft 資料中心提供高可用性及延展性，Contoso 系統可以升級客戶的組態輕鬆地快速，新增或移除的每個客戶 ’s 需要其電子控管解決方案的元件。 並使用大量計算能力提供透過 Windows Azure 平台，客戶必須能夠處理不同的負載，而不需完整資本投資。

而不是在尖峰負載的伺服器容量的投資，並再其他期間 underutilizing 該容量客戶可以支付只針對他們需要依它們所需的容量。 「 如果選舉隨後，我們可以新增客戶 ’s 選舉 Office 應用程式的多個執行個體，提供更多的計算能力，它們只有在該期間內支付它 」，「，說，」 為另一個的 Contoso 公司員工。

azure 權益：降低成本

Contoso 系統 e 控管方案訂閱的政府能更有效率地管理他們的成本，藉由降低作業成本避免基礎結構維護的額外負荷，並只支付他們使用什麼當他們在使用其資本投資減至最低。

指定集合的電子控管的組件中的功能，客戶可能需要花美國 在首都的成本為 $ 24,000 和約為 60000 美元在每年的維護負擔。 與 Azure，它可以完全 forego 首都，並維護費用，付只服務可能會比美國的費用 $ 10000 年。

「 Windows Azure，使用我們的客戶 don’t 要事先投資在基礎結構或裝載的服務有 」 「 資深專案管理員。 「，因為它們可以支付時它們，其預算是更容易 」。

因為 Contoso 系統可以佈建和管理 Windows Azure 平台解決方案，將增加獲利性，並降低成本約 70%，因為它為更多的客戶提供其電子控管套件。 「 藉由傳遞我們 e 控管解決方案，透過 Windows Azure 平台，我們會得到更多的商務從更多的客戶 」 「 資深專案管理員。 「 及新增，管理，及帳單客戶透過平台會提高效率降低成本 」。

azure 權益：快速、 獨立開發

因為它們可以利用現有的技術，在 Contoso 系統所花費較少的時間學習如何使用 Windows Azure] 平台的開發人員減少時間花費部署與 Windows Azure e 控管方案。  而且，因為它們並沒有設定的基礎結構，以支援部署，就可以專注於商業邏輯和該應用程式的設計。 「 沒有 Windows Azure，我們可能有花 25%更多的時間在程序開發，」 「 資深專案管理員。

摘要

藉由訂閱 Contoso 系統 e 控管解決方案，本機政府在印度和其他地方可以提供政府服務及更有效地與 constituents 互動。 它們可以讓您方便存取服務、 授權資訊，市民和增強政府透明度和責任，同時降低成本、 簡化作業，並改善效率。

結束時，與建議

Contoso 是一個很好的範例，具有實現簡化應用程式部署，彈性的組織和降低成本，成本效益的延展性，並著重在使用 Microsoft 技術的這個執行個體的定域機組服務的開發。  如所示範 SOA、 SaaS，並計算引進新技術機會可以產生新的機會，企業的定域機組。 隨著這些新技術機會出現一組新的商業和技術風險，必須加以管理，以確保在技術和商機達成。

因為我們已經證明透過六年以上的工作，商務-透過商業功能的分析和熱度對應並訂定優先順序的需求分析貼齊至 IT 交談技術架構層級。 我們對此我們 co-authored Harvard 商務檢閱 「 [下一步大革命中生產力 」，在 2008 年 6 月發行項中 「 管理員會使用的手中活動的 [熱量分佈] 圖有太多或點大部分的資訊，他們需要設計一個新的作業模型 」。

計算已提供新的優點，在速度、 成本和擴充性這樣的定域機組。 商業功能的模型已對齊的商務策略的方向與技術幫助。  當結合一起這些承諾，以便讓組織將移至 SOA 和 SaaS，以最佳化的投資和時間上傳回值。 因此我們的特定建議的下一個步驟是真的組成兩個主要是平行的路徑：

開始商務功能分析

這是在取得熱度對應和磁碟機統一及機會 maximization 討論的第一個步驟。  它是很有可能您的組織已經採用互補的方法，例如程序再造，六標準差、 Lean，或另，所以建議您啟動使用一個的小型商務功能包含區域，使您可以了解它不同於，及補充這些其他的方法。 沒有資源可用以協助您進行這項目，超過我們 Harvard 商務檢閱文件和活頁簿 Rethink，所以請與我們連絡與您的問題與意見。

定義技術藍圖

清楚哪些 「 目前技術架構是，它多少的有清楚的服務的定義，然後看一下各種不同的技術，將補充現有傳統的解決方案在適當，但也說明路徑下的定域機組計算最佳對齊與組織的目標和客戶需求的方式組織。  如果您問題的相關技術的架構和運算的定域機組請讓我們知道。

維護藍圖

若要關閉出我們的類比有關修復 mid-flight – 即使是使用適當的工具在飛機，您會需要相當充份如何同時使飛機空氣中修正與平面。  當您透過轉換不同的方式來運用 SOA、 SaaS 與雲霧運算提供商務價值的進度將成為明顯，您將識別不同狀況特定的風險，並將變更您的值效能間隔。 值效能熱度圖是要保留目前的極低 friction 和努力有助於維護明確瞭解什麼是重要的商務和原因。  SOA，SaaS，定域機組的運算，並有適當的工具和功能分析提供清楚的地圖，可用來釐清值並與您工作相關的風險。

 

Ric Merrifield 會導致在 Microsoft 公司在台北市，華盛頓州的企業架構努力時，而是 「 [下一步大革命中生產力 」 的 co-author 6 月，Harvard 商務檢閱 2008年。  Merrifield 也是 Rethink – 剪下成本和促進創新，全文檢索按 2009年的商務宣言書籍的作者。

Dennis Stevens 是在執行長的 Synaptus，在 Norcross，GA 基礎的顧問公司，而是 「 [下一步大革命中生產力 」 的 co-author 6 月，Harvard 商務檢閱 2008年。 Stevens 也是 7 月裁切器協會報表 Rethinking Agile 企業的 co-author 和目前正在寫入值導向 Agile 採用：Addison Wesley 的比例企業的靈活度的年度結束 2010年到期。