伊利諾伊州
芝加哥
正如 Cap Gemini Ernst & Young (CGEY) 的解決方案設計師經理在芝加哥加速開發中心所聲稱的
Ashvin Vellody 的工作圍繞著使企業軟件系統相互對話
我們開發的大型項目
需要以不同的行業規范類型提供給客戶
Ashvin 解釋道
CGEY 使用了世界上遵循 CMM
和 ISO
的開發工具來提供任何類型的軟件項目—自定義編碼的 J
EE 產品
PeopleSoft 打包實施
集成項目或任何可能的情況
在我們的中心
我們提供方法
工具和人員以可預知的方式快速提供復雜系統
加速開發中心是 CGEY 交付方法學中的一個重要組件
它不僅提供專業環境中的基礎架構
過程和人員
有助於滿足合約中客戶的嚴格最終期限
還為其設計人員提供工具和技術
通過更高的生產率支持加速交付
Ashvin 說
由於環境很靈活
所以人們來到中心工作
您可以在利用我們的工具和環境的同時配置自己的項目小組工作空間
諸如此類的微小改變會帶來生產率顯而易見的提升
並可提供卓越的工作空間
還有一個完整的工具小組坐鎮後方
幫助多個項目成功地完成交付
中心大部分的時間和資源都投入到構建系統間的連接
這就意味著為自定義構建的連接器進行編碼
或使用即取即用的集成解決方案
或通常兩者兼有
但對於所有進行中的編碼和軟件工作來說
Ashvin 的大部分時間都投入到了不涉及削減代碼的任務
諸如計劃
建模
設計
甚至協議之類的任務—軟件集成後的
軟知識
不同對象的不同集成需要 開始一個項目時
Ashvin 多項任務中的首要任務之一是
當新的集成系統完成時評估它的首要業務目標
以及什麼類型的對象使用它—系統將首先服務內部用戶
其它業務
還是服務終端客戶？
企業到企業 (B
B) 系統與企業到消費者 (B
C) 系統完全不同
Ashvin 解釋說
B
C 系統就是我們通常說的
深入接觸
系統
它直接與終端客戶交互
因此它必須是面向用戶的
界面外觀應該十分友好
這就意味著格外注意用戶界面
B
C 系統還提供對大量人員的服務
它的事務處理量不會很大
但會有大量人員利用這些服務
Ashvin 將此系統與 B
B 系統進行了比較
後者通常意味著簡化復雜的商務處理
如自動化庫存和訂購
通常基於紙張（至少一部分）的過程
以及或許涉及到的舊的原有系統
界面外觀的問題在 B
B 集成項目中並不總是很重要
但由於目標是簡化做事的舊方法
因此涉及到的過程更加復雜
Ashvin 說
例如
我最近項目的客戶是一家電信公司
該公司希望更好地處理客戶的呼叫
使其呼叫中心的操作與後端計費系統之間的過程更加自動化
因此我們緊張忙碌了
個月
對 CRM 前端
後端計費系統進行了評估
並將一些體系結構部署到位
該項目用來簡化商務過程
並且處理兩個系統（原有計費系統和更現代化的 CRM）間的復雜事務
原有系統Spaghetti 代碼金蘋果以及大的飛躍 根據 Ashvin 的說法
CGEY 已經看到了公司整個客戶群集成項目的增長
這些集成中的大部分分為兩大類—客戶或者擴展原有系統
或者自動化過程
努力爭取提高生產率
有時二者都需要
由於目前預算緊縮的現實
各公司正試圖一絲不漏地發掘原有系統的全部生產力
舊的應用程序並不總是在頭腦中用現代的體系結構構建
並且將新舊應用程序相混合幾乎是瘋狂的
Ashvin 說
我們所面臨的集成原有系統的挑戰是雙重的
首先
我們必須從系統中抽取出 spaghetti 代碼和邏輯
而系統在過去的
年中可能已被反復構建或修改過多次
了解系統的人不總是可以接受改變
他們也可能不願意共享知識
另一個挑戰是識別所謂的項目
金成果
—新的做事方法的前提或全部意義
Ashvin 針對其最近的電信公司計費系統的項目指出
計費十分復雜
一個過程可能涉及
個不同的領域
一些部門可能每星期更新一次原有計費系統
其它部門可能每日更新
不論怎樣
這些過程一段時間後都一起進入了 spaghetti 代碼集
我們必須從該代碼集抽取邏輯
確定誰擁有這些數據
以及數據如何以一種簡單的
黃金標准
的方式在各部門間共享—為解決此問題
我們奔波了兩個半月
當公司試圖大幅提高生產率而集成系統時
其它的集成難題出現了
Ashvin 主持的一個有關汽車金融問題的現有項目就是一個很好的例子
Ashvin 解釋說
該項目旨在根據汽車購買經驗以及取得信貸審批來自動化客戶和經銷商交互的方式
這是三個汽車制造商的經銷商協作努力的結果
假設一位客戶想要購買一輛通用汽車公司的卡車或一輛福特轎車
不論情況怎樣
通過此項目
經銷商可以迅速地對貸款應用程序
信貸審批及 APR 等級等事物做出反應
該項目還可以確保三大汽車制造商的任何一個後端系統能夠以一致的格式接收信息
並一致地向任何經銷商發回信息
這樣的項目通過自動化過程減少了書面工作和低效率的過程
從而獲得了生產力的巨大飛躍
要確保經銷商和汽車制造商都使用類似的數據
類似的格式
並通過類似的過程使用數據—獲得生產力的飛躍—需要清楚的了解 B
B 集成問題
了解 BB 系統 汽車行業是面臨集成挑戰這一大趨勢的行業之一
要幫助廠家和公司構建交互式 B
B 系統
一些行業提出了他們自己的標准—如汽車行業的 STAR 標准
Ashvin 說
STAR 是特定於汽車零售行業的
符合 SOAP 的最出色的 XML 模式
例如
另一個縱向標准用於商業采購供應空間—那就是 ebXML 標准
這些縱向標准說明了系統如何定義數據
需要什麼數據
什麼數據是可選的
以及應該如何管理消息
其它行業正在采用諸如 RosettaNet 一類的通用標准
根據客戶端狀況
一個或多個這種標准的要求可以支配適用於設計人員的集成方法
其它 B
B 集成方法包括通常所說的 私有交易
其中行業中的某個大公司有足夠的慣性要求其供應商僅采用一個基礎架構
私有交易由一個具有金融和行業影響力的主要參與者建立
這就是我作為企業與你交流的方式
Ashvin 解釋說
圖集成體系結構 Ashvin 將沃爾瑪作為實踐中一個私有交易的實例
沃爾瑪說
其所有的供應商都必須使用這種電子交易系統來與沃爾瑪進行交易
然後供應商必須實施特定的一年或一段時間
並准備好通過沃爾瑪的交易系統進行交易
這一切僅通過邀請來實現
並且進行集成相對比較容易
但是 Ashvin 很快解釋了沃爾瑪工作的內部系統決定了集成過程
而不是單一的外部方法（如 ebXML）
解決 B
B 集成難題的另一方面是了解貿易合作伙伴管理 (TPM)
TPM 是 B
B 過程的集合
它明確地解決了供應商和廠商交易過程中的工作流和交互問題
TPM 還提供一致的方法與商務處理通信
Ashvin 說
TPM 設計用於解決公司的銷售和供應鏈問題
例如
作為公司怎樣在供應鏈中管理所有不同的貿易合作伙伴？怎樣維護他們？怎樣與他們進行交易？與他們進行調解的過程怎樣？TPM 是 B
B 集成中的一個重要部分
建模的重要性 不論您集成了行業標准
開放標准
還是受限於私有交易的體系結構
作為設計人員最終您必須開始定義數據
創建對象
並且開發出管理其余項目的模型
這是我最無法忍受的事情
Ashvin 說
集成項目的一大難題是確定真實的記錄和實體存在何處
例如
一家電話公司有十個不同的部門與名為
客戶
的抽象對象交互
每個部門組織客戶的方式不同
識別客戶的方式也不同
對這些不同的部門采用一個通用的定義很難
Ashvin 最近的電信公司計費系統項目證實了建模是十分復雜的工作
在知道了客戶的地址和位置的前提下我們才能為他們建模
這對所有的部門都適用
在計劃過程中所有的商業用戶也都適用
但是沒有人了解直到我們開始實施它才能起作用
如果您僅通過一個人居住的位置來識別他/她
那麼如果他們換了地方該怎麼辦？你打算獲得多條記錄
然後通過兩個不同的位置識別那個人？這是關於人們的電力計費的系統
因此系統中的問題將影響到人們的日常生活
Ashvin 的小組最終構建了一個變通方法
經過一夜的努力解決了地址/位置的難題
這種現實世界的實例說明了在實施開始前和整個實施過程中
完全在系統模型上工作非常重要
建模應該是優先考慮的問題
並且應該從盡可能多的角度對工作流和過程檢查給予預期時間
Ashvin 建議
對於一個歷時
年的復雜項目來說
在編寫代碼前應該花費大約
個月的時間來為工作流和過程建模
商務過程管理 新的商務過程管理 (BPM) 工具有助於公司組織模型以及商務過程在應用程序中工作
Ashvin 解釋道
BPM 是一層說明
它位於集成代碼之上
BPM 為商務用戶提供調整模型和改變工作流的功能
BPM 工具是十分圖形化的
並且探查代碼更改在底層透明地進行—或者至少應該透明地進行
BPM 出現的時間尚短
但這些工具為商務用戶提供了用圖形化方式處理事務的能力
例如改變購買訂單的工作流
一個商務用戶—並且從事此行的人應該非常具有商業頭腦—可以改變 PO 過程
因此能夠通過在 BPM 工具中改變圖形模型在不同的部門中共享 PO
Ashvin 指出
只需使用即取即用的解決方案（如 webMethods 或 SeeBeyond）就可以很好地連接代碼
但是應用程序會發展或改變
因此商務用戶需要能夠管理那些改變並相應地改變商務過程
這就是增加的 BPM 對集成設計師的增值所在
它允許工作流為商務用戶
按訂單生產
改變准備就緒 設計人員應該意識到
From:http://tw.wingwit.com/Article/program/Java/JSP/201311/19622.html
