企業架構如何實施的簡介(深度好文)


 IT不僅是開展業務的手段,而且正在迅速演變為業務,IT績效會直接影響企業的盈利能力,但很多企業並沒有適時或充分的讓IT組織參與業務的規划和決策過程,沒有給予在規划和IT決策過程中考慮的安全性、可擴展性、集成問題等IT問題足夠的重視。

復雜性驅動改變

        傳統的應用集成方式存在諸多弊端,僅僅依靠在兩個數據庫中傳遞數據或者相互之間調用接口的模式很難解決企業的整體集成問題。無論是在理論上或是實際中,這樣的集成方式注定意味着項目的失敗。

        僅僅從技術角度去思考集成系統只能是說是技術實現手段,但要真正發揮 IT 的價值,技術人員必須從技術架構視角提升到業務架構視角,從企業架構規划開始考慮 IT 和架構的融合,不僅解決集成問題,更能能從根本上改善 IT 帶來的價值。

        企業架構是承接企業業務戰略規划與信息化建設之間的橋梁,是企業信息化的核心。企業架構中 97%是業務,3%是 IT 技術,那么企業架構到底是由哪幾部分組成的呢?現在又有哪些企業架構方法?我們又應該選擇哪個企業架構方法?選擇之后又該具體如何去做呢? 

        下面我簡要說明一下企業架構實施落地的幾個步驟。

企業架構理念和知識工具的導入

        IT系統如果不能滿足商業需求,那將是大大的浪費,而業務過程沒有相應的IT支持,效率很難提高。企業架構的目標是通過IT投資獲取最大的商業價值,它是一種高層次的企業視野,聚焦與組織的IT架構和業務架構之間。首先我們給客戶進行三到四天的企業架構培訓,快速准確的導入企業架構理念和知識工具,讓架構工作組所有人員對企業架構有一個統一的認識,保證架構工作開展前的准備工作有效。

        那架構工作組需要包含哪些人呢?不同企業架構工作組成員組成可能不一樣:

        架構實施范圍不同也會造成工作組成員的不同,例如僅對車間管理進行EA設計,那所涉及的成員和整個企業的EA設計是不一樣的。

架構現狀分析

        很多企業沒有進行過統一的企業架構,即使有的話,也是各種架構獨立存在,不能達到統一規划,加上各子業務部門自己進行信息化工作造成了企業應用豎井,導致集成性差而不能有高效的信息化,以及變更能力差而IT不能跟上業務的腳步等眾多IT和業務不能對齊的問題。

    如果你經常和軟件系統打交道,那么你可能會發現軟件開發過程中其實存在幾個重要的斷溝(GAP)。

1. 業務架構到技術架構的不一致

a.業務架構是一撥人做,技術架構師另一撥人做,結果做業務架構時缺少技術架構的考慮,而技術架構缺少服務於業務的意識,最終沒有為業務服務。弄到最后業務架構和技術架構並不能很好的結合起來,導致還需要很多適配或反復工作。

b.還有一種情況是,業務架構做完之后扔給技術架構來實現,但是業務架構提供的東西並不全面,不能提供技術架構的輸入,導致溝通效率極其低下。

2. 業務架構到業務需求的不一致

a. 有些公司雖然崗位分的清楚,但是方法並不清楚。業務架構是一套方法,需求分析是一套方法,甚至於沒有方法,而是靠着個人能力去做,結果導致架構和需求交付物是獨立的,業務架構的東西不能順利轉移到需求階段

b. 還有時候一個人就負責產品的業務,架構和需求一起做,這時候沒有方法的指導,其實很容易迷失在業務細節。 過早的進入業務細節對於產品來說是及其危害的,因為產品架構還未明晰時進入細節只會浪費時間導致重心偏離方向。

3. 業務架構和實現的不一致

開發產品時,開發問一句,"做這個對系統有什么價值?"結果發現需求根本無法追溯回系統的價值點上,有時連需求人員都不知道為什么做了這個功能。如果產品生命周期較長,中間換了好幾撥人來做這個產品了,那么不僅是需求文檔不能追溯,就是靠口頭講也講不清。

a. 業務架構采用的是業務語言,而技術實現采用的技術語言,兩者不是同一個語言,很難做到順利過渡,還需要再一次翻譯,有時候甚至在實現階段根本不看業務架構出來的東西

b. 很少有開發人員清楚產品的業務架構,那么如何能夠做出好的產品來?

        其實業務架構和業務需求本身就不沖突,兩者只是處在一個事物在不同層次的東西。架構關注的是更全面、概括、組織方面的東西,而需求關注的是用戶關心的業務細節,業務需求是業務架構的進一步分析。但是很多企業在進行企業架構規划時,卻不知道如何區分這些,導致業務人員叫苦連天。

        這些差距還不是最重要的,還有更大更重要的一個差距,就是戰略與IT的差距,這個可以看之前我寫的一篇《企業信息化復雜嗎?戰略和架構的關系?

        從上面說明可以看出主要問題,現實中產品開發存在的隱性問題其實還有更多並且很嚴重的,我也都經歷過。而解決這些問題就必須做到以下幾點:

  1. 找到一個指導頂層架構的方法和框架
  2. 結構化架構交付物才有可能把架構知識轉移到架構遷移實施階段
  3. 有一個業務開發平台來集成業務架構、技術架構和開發框架

        而這個也正是企業架構的意義。為了解決IT與業務一致性問題,企業架構的導入和落地需要三個方面的支撐:指導企業架構工作的方法論、進行企業架構描述的架構語言,以及企業架構落地到應用開發的平滑過渡。

企業架構框架和方法

        有很多不同類型的企業架構框架方法,因為TOGAF通用性較強,近幾年發展也不錯,應用也逐漸廣泛, 其完整性和實用性都比較高,所以我們在咨詢中使用TOGAF為客戶進行架構規划。

        TOGAF有一個ADM架構開發方法,它是一個可靠的、行之有效的方法,是TOGAF的關鍵。

        TOGAF還提供了一個詳細的架構工件模型,包括交付物、交付物的工件和架構構建塊,可以給予我們更多指導。

        雖然TOGAF9已經提供了內容框架,但框架本身並沒有告訴你太多如何具體去做架構的細節,大多時候我們要借鑒已有的一些模型或者方法,例如PCF、SCOR、CBM等。

 企業架構語言

        企業架構是頂層設計,所以我們不能沿用開發階段的UML等語言來描述,也不能簡單的使用Viso隨便拖放一些圖例,在咨詢中,我們給企業導入企業架構語言ArchiMate,當然每個企業也可在此基礎上擴展自己的模型。

        我們以某保險公司為例,看看使用ArchiMate做出的一個分層視圖:

        這是應用組件視圖:

 業務開發平台

        這個在咨詢過程中只做建議,更多需要結合企業的開發能力而定如何實施。

過程交付物示例和簡要說明

        企業架構適用於大型企業,也同樣試用去中小型企業,關鍵點不在於組織大小,而是系統是否復雜,企業是否需要敏捷,是否需要使用IT來幫助你構建企業未來的能力。

        基於不同規模的企業,業務復雜度自然不一樣,所以咨詢過程也是都不一樣的,但是一些方法和步驟還是相同的,下面我們簡單來看看其中一些過程交付物和簡要說明,以便對未接觸過企業架構的推動者有一個初步的認識。

在企業架構預備階段,核心之一是確定企業的范圍:

以及確定各架構原則

願景階段需確定企業核心能力

並在核心能力上進行熱點分析

以及改進分析

還需要確定績效衡量指標

在業務架構階段的流程設計時,制定統一的流程層級和流程分類十分重要

在業務架構階段,核心是要做高階流程分析

 經過業務流程分析之后,再次分析形成業務組件

分析to-be架構與as-is架構的差距,並形成業務組件差距分析

信息系統架構主要做實體模型以及應用組件設計

技術架構除了部署設計之外

還有技術架構選型,

之外還有一個重要的是需要進行核心技術梳理

架構完成之后,開始進入項目組合管理

到這一步,一個充分支持業務的架構才算初見雛形。

不要誇大IT的作用

     IT信息化是幫助企業運營的,而運營執行的是戰略,從這個先后順序來看,那就是IT是在戰略規划之后,而且這是由兩撥不通技能要求的團隊來完成。我們不能把IT太高估了,他們並不是無所不能的,我倒不是說軟件企業沒有這種能力,只是術業有專攻,企業不能把一個管理上的問題直接簡單轉換成一個IT問題來解決,否則得到的解決方案也一定是一個IT方案,而不是解決管理的方案。我認為管理問題還是通過管理的方式來解決更好些,該做企業戰略咨詢的還得做咨詢,該自己思考業務的還得自己規划,IT相對這些來說,更向是一個戰略執行的工具而已,不能本末倒置,IT工作的輸出絕對不會是戰略,否則容易出漏子的。 戰略管理一定要由富有經驗的企業戰略專家團隊來完成,而IT系統完成也一定需要專業的團隊來完成,軟件開發商不能幫你做這些事,你需要能對企業IT信息化做整體規划的人。


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2020 ITdaan.com