那些不容別人批評自己的工作或偏好某一種技術的人可能會在SOA中遇到不少困難。SOA目標之一就是構建靈活、可維護性好、松耦合、與平臺無關的軟件。要構建這樣一個軟件就必須從軟件開發轉向軟件工程。簡單來說，我們必須從拖曳的工作方式轉向計劃建模的工作方式。我們必須能夠接受協作、同行審查和治理。如果開發人員不喜歡這些東西，他們要么選擇改變，要么選擇離開。否則他們將成為巨大隱患，并且一直拖后腿。
好了，現在我們來談談開發人員的分類。但是在此之前需要強調一下，這里討論的是分類，而不是個體。在小型企業里，一個開發人員可能會跨越多個分類。在大型企業中，我們可能會看到非常專業化的開發人員工作在架構中的單獨一層。最后聲明一點：討論的默認前提是存在一個架構團隊，并且各層中存在一定程度的標準與治理。
UI開發人員
如果公司有能力專門化，那么這會是非常棒的一層。這層的開發人員并不需要非常高深的技術。重要的是他們要明白可用性、UI標準和Web界面的最佳實踐。這些人可以從模擬開始，與業務部門或業務分析員合作分析各種情況，最終達到一致的結果。這些開發人員必須能用業務用語和業務部門交流，并且能明白商務用戶如何使用網絡技術進行交互。
業務過程開發人員
在這個業務過程層中有兩種截然不同的類型：一種處理業務過程建模，另一種處理業務過程與底層服務和系統的集成。在某些公司里可能會讓一個人完成這兩項任務，但是更多情況下這會是兩個人的工作，因為這兩方面需要不同的技能。負責業務過程建模的人甚至可以不是IT人士。某些公司在業務方面設有專門部門，部門中的人主要負責改善并自動化業務過程。(這種公司都是使用6Six Sigma或全員質量管理的公司。)
業務過程集成是一個技術活，它需要Web服務、REST、JMS隊列或其它類似的專業知識。負責集成的人是將業務過程與控制業務服務流程和組合業務應用(通常稱為編排)的后端技術聯系到一起的人。
業務規則開發人員
這一類型有點模糊，并不是所有架構都有一個具體的業務規則層。某些情況下，這些業務規則是在數據層中進行控制的。對于那些有非常動態的業務規則，特別是以客戶為中心并且允許終端用戶甚至顧客更新規則的公司來說，提取出一個業務規則層來是很有必要的。如果公司有一個業務規則層，并且使用某個工具來管理業務規則，那么這個公司很可能會需要一個技師來管理這一層，就像數據庫維護人員維護數據庫層一樣。在某些情況下，這份工作也可能交給數據庫維護人員來做，當然這是靈活的。
不管由誰來做，他們都必須明白這一層的含義并尋找能讓終端用戶更快地對業務變化做出反應的辦法。比如，一個貸款審批程序需要這樣的一個特定狀態的業務規則：貸款申請人需要具備多少比例的資產才有可能得到審批。這個比例值經常要根據狀態進行改動，所以必須能夠盡量快地保持更新。最佳的辦法是把IT從這個過程中剔除出去，讓某個具有授權的特定的人(或系統)按需對這個值進行更新。不管是誰負責這個業務規則，他都必須能夠與業務部門和/或業務分析員共同協作，明白變動的頻率、許可權限以及各種業務規則所帶來的影響。另外，與此相關的還有大量與創建和管理規則相關的日常支出，負責人必須能夠權衡利弊并做出決定。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
