某公司企業架構設計原則

1 架構管理原則

1.1 統一架構原則

描述	公司統一開展總體架構規劃和管控。
理由	1.統一的總體架構有利于避免資訊系統的分散、異構、難以管控等問題。2.統一的總體架構有利于業務和資訊化規劃的實作和落地。3.統一的總體架構有利于優化IT治理工作。
影響	1.研發機關應按公司總體架構維護相一緻的技術架構體系。2.根據公司業務和資訊化戰略，綜合短期成果和長期影響，定期開展總體架構維護。3.統籌安排、集中管理總體架構規劃。

1.2 統一管控原則

描述	推動業務與資訊化融合，實作柔性、完整的總體架構落地。
理由	1.推動總體架構在全公司的整體運用、決策制定、全面指導和品質保障。2.推動跨業務領域的資訊技術共享和應用。3.強化業務部門與資訊部門間的協作。4.推動業務部門與資訊部的互動，實作完整、迅速的總體架構落地。
影響	1.推動業務目标與系統架構設計相一緻。2.推動架構設計過程的有效溝通。3.運用架構管控流程，規範化架構評審和資産維護過程。4.明确架構管控組織的管理角色和職責。5.制定架構評估名額，定期檢查架構執行效率、遵從度和一緻性。6.建構架構資産，支撐架構決策和評審的執行。

1.3 架構遵從原則

描述	推動系統架構的分級評審，保證系統架構設計與總體架構規範相一緻。
理由	1.對所有建立和在建項目進行系統架構評審，保證設計與總體架構一緻。2.對所有已建應用完善或重建項目進行系統架構評審，保證設計與總體架構一緻。3.提升系統架構的業務符合性、設計标準性、架構一緻性和技術完備性。
影響	1.建立系統架構評審流程，保證系統建設與總體架構一緻。2.推動項目管控與架構評審的高效整合，提升系統架構設計品質。

1.4 架構收斂原則

描述	為保持技術方案的靈活性和健壯性，對同一類業務或技術場景，總體架構可提供多個備選技術方案。
理由	1.在總體架構中，減少支撐同一類場景的備選技術方案的數量至兩個或一個，以降低架構管控的複雜性和技術多樣性。2.選擇實施難度小、複雜性低、非功能性限制低的技術方案作為推薦技術方案。
影響	有效控制總體架構的靈活性，備選方案收斂性直接影響資訊化成本的變化。

1.5 融合共享原則

描述	以業務和資訊化發展戰略為導向，推動業務應用的融合內建。
理由	1.避免備援系統林立，降低資訊化運維成本。2.推動業務應用的深度內建，為智能分析決策奠定基礎。3.避免在資訊化建設中建立資料或應用孤島。4.避免業務應用的重複建設。
影響	1.由公司全局着眼，考慮業務應用的融合內建。2.形成一套公司标準化的應用內建設計方法。 3.建立配套的流程和資料管控機制，以降低由企業級應用內建而産生的流程和資料管理複雜性。4.建構企業級的共享應用群群組件庫。

1.6 服務架構原則

描述	利用SOA概念設計業務服務和IT服務。
原因	1.通過業界标準促進業務和IT的融合。2.需要通過靈活、可重用和标準化的IT架構支撐業務的快速變化。3.需要先進的設計理念。
影響	1.由公司全局着眼，考慮業務應用的融合內建。2.形成一套公司标準化的應用內建設計方法。 3.建立配套的流程和資料管控機制，以降低由企業級應用內建而産生的流程和資料管理複雜性。4.建構企業級的共享應用群群組件庫。

2 業務架構原則

2.1戰略契合原則

描述	業務架構設計應與企業發展戰略相契合
理由	1.業務架構涵蓋的業務能力應有效推進企業戰略發展。2.避免與企業戰略發展相悖的業務能力出現在業務架構中。
影響	1.業務架構指導了應用架構的建設，應確定資訊化建設方向與企業戰略目标一緻。2.資訊化建設的優先級順序收到企業戰略發展影響，需要在業務架構中有所展現。

2.2 流程重構原則

描述	業務流程重構先行。
理由	1.不建議對陳舊、無效的業務流程進行資訊化改造。2.業務流程按效率最優的原則進行優化和重組。3.業務流程重構以降低全面擁有成本為目标。
影響	1.業務部門與系統建設方應就優化後的業務流程達成共識。2.業務流程重構與新技術應用并舉。3.業務流程重構應與業務目标保持一緻。4.組織架構變更将觸發業務流程重組及業務架構調整。

2.3 業務連續原則

描述	公司的生産運作和經營管理不受資訊系統建設影響。
理由	1.随着公司資訊化的進一步普及，公司生産運作和經營管理活動對資訊系統形成一定依賴。系統設計、建設和應用過程中必須全面考慮系統可靠性。2.建立無資訊系統幹預的業務運作預案，確定極端情況下的公司業務連續性。3.建立健壯的一體化資訊平台，支撐業務活動的連續運作能力，避免系統硬體故障、自然災害、資料損壞等問題的影響。
影響	1.建立資訊化風險管理機制，預防和管理資訊系統故障可能造成的業務中斷。2.系統架構設計應考慮并解決技術方案的可複原性、備援性和可維護性等要求。

2.4 業務合規原則

描述	所有的業務規則和流程需要遵從公司和政府的相關政策、标準及法規。
理由	1.如果在應用系統中實施了有缺陷的業務規則及流程，會造成财務或實物資産的損失、及對公司聲譽的傷害。2.需要遵從政府的法規和行業标準。
影響	1.業務規則和流程的整體設計，需要法律及相關部門的稽核和準許。2業務規則和流程的變更，在應用到資訊系統之前，需要法律及相關部門的稽核和準許。

3 應用架構原則

3.1 統一設計原則

描述	業務應用采用統一設計，避免重複建設。
理由	1.企業級應用建設需保證科學重用。2.架構設計中避免重複設計、備援應用。3.設計備援将引緻高昂的資訊化成本。4.設計備援将帶來資料沖突，增加內建複雜度。
影響	1.不建議對相似的企業級業務能力進行重複建設。2.标準化企業級的資料和資訊。

3.2 功能重用原則

描述	建立應用重用已有應用功能。
理由	1.深化套裝軟體方案的實用性和可用性。2.選用已經驗證或測試的應用方案。
影響	1.帶來明顯商業優勢與成本節省。2.需要經過評估來決定是建立還是購買新應用。

3.3 應用柔性原則

描述	應用設計具備充分柔性。
理由	1.通過業務應用系統更新，靈活适應業務需求以及合理的需求變更。2.适應業務流程優化調整。3.業務應用系統靈活适應資訊技術變更。4.在降低業務流程重建風險的同時，實作業務應用的便捷、快速內建。
影響	1.初期投入相對較大。2.系統設計周期加長。3.系統生命期延長。

3.4 應用安全性原則

描述	保證應用系統的完整性、保密性以及安全性。
理由	1.避免公司的财務資産,、實物資産、聲譽以及客戶關系, 因為應用系統或資料的不當使用, 而帶來損失和傷害。2.應用系統和資料的通路需要采取授權機制。
影響	1.需要制定統一的通路控制機制并取得共識。2各種不同的應用系統，需要實施統一的管理和标準化的通路控制機制。3.中标的成熟套裝軟體及相關功能子產品也需要遵循已定義好的安全标準。

4 資料架構原則

4.1 資料資産化原則

描述	資料是公司的一類有價值的無形資産，需要對其進行統一的管理。
理由	1.資料是支撐公司業務正常運轉以及戰略決策科學制定的重要保障。2.對資料的充分利用能夠實作公司價值的提升。
影響	1.将資料上升為公司無形資産的高度，在全公司範圍内統一認識。。2.加強對公司資料的管理與管控，挖掘公司資料的潛在價值。

4.2 資料共享原則

描述	資料要能夠被合理的通路，不能被私有化。
理由	1.資料共享能夠支撐公司内部廣泛的業務協同。2.資料共享是提高決策品質和效率的基礎。3.明确資料唯一來源，減少資料備援，能夠有效降低運維成本。4.公司資料的收集、生成、轉換、彙總等處理速度取決于各部門資料的共享程度。
影響	1.基于短期和長期的考慮，建立資料共享的政策、機制、流程、标準等。2.建立全局資料模型，梳理資料資産，加強中繼資料管理，建構資料共享環境。3.限制對孤立的遺留系統投資，制定遺留系統的退役或遷移政策。4.資料共享需要全公司認識上的轉變。5.資料共享要與資料安全相統一。

4.3 資料可用性原則

描述	資料對于有權通路和利用它的使用者來說必須是可用的。可用性主要展現在可擷取和可利用兩個方面。
理由	易擷取、高品質的資料能夠支撐公司内部廣泛的業務協同，是提高公司決策品質和效率的重要保障。
影響	1.資料的通路和展示方式要能夠充分滿足公司各級機關、部門的需求。2.提高公司對資料品質的重視程度，開展有效的資料治理。

4.4 資料認責原則

描述	對資料要指定權威的資料擁有者、品質責任者、日常管理維護者等角色。
理由	1.資料認責機制是資料資産有效管理的基礎。2.通過資料認責能夠提高公司各部門對資料管理的參與度，更好的滿足各部門對資料的需求。
影響	1.資料認責需要公司各部門的共同參與，并在公司各部門間達成一緻。2.要建立資料品質的度量方法，形成科學的考核體系，推進資料認責的有效落實。

4.5 資料标準化原則

描述	資料要在全公司範圍内有一緻的定義，并且資料定義能夠被所有使用者擷取和了解。
理由	1.資料的标準化是資料共享的基礎。2.一些項目的解決方案需要有統一的資料定義。3.通用的資料定義能夠實作有效的溝通和對話。4.統一的資料定義是快速改善公司資料環境的有效途徑。
影響	1.建立通用的業務術語表，業務定義要在全公司範圍内一緻。2.在資料定義過程中，要引用術語表中的術語，以保證資料含義在全公司被有效的了解，不産生歧義。3.建立資料定義的仲裁機制，以協調不同部門對資料了解的差異和沖突。4.建立資料标準體系，對多種資料标準進行協調和統一。5.指定資料标準的責任者。

4.6 資料安全性原則

描述	資料要在安全等級要求下，被合理的通路、共享和釋出。
理由	1.公司資料涉及國家安全，要滿足國家監管機關對資料安全的要求。2.公司資料涉及商業機密，要求滿足公司自身發展對資料安全的要求。3.資料安全是公司資訊安全的重要組成部分，應統一管理。
影響	1.制定資料安全管理政策，劃分資料安全等級，不同安全等級應采用不同的安全通路政策及授權通路機制。2.在資料定義階段就要明确對資料安全級别的限定。

5 技術架構原則

5.1 标準化原則

描述	将技術多樣性降低到最小化，降低建設和運維成本。
理由	1.技術多樣性往往需要不同的基礎架構，進而導緻更高的建設和運維費用。通過公司整體範圍内的技術統一能夠有效降低整體建設成本和運作管理成本。2.限制技術多樣性帶來的業務優勢主要有：标準化應用組合；更好預測新技術帶來的風險和影響，以适應技術進步。
影響	1.需要據此制定資訊化建設政策、标準規範。2.執行統一的技術生命周期管理，統一技術選型和采購。3.建立技術架構藍圖，适時保持更新。4.隻在新技術能夠明顯證明有利于提升業務價值和改善營運效率的情況下才決定引入。

5.2 互操作原則

描述	推動硬體、軟體的标準化，提升資料、應用、技術的互操作能力。
理由	1.有助于保持一緻性，改善運作效率，提高使用者滿意度，保護現有IT投資。2.有利于選擇資訊化供應商，促進供應鍊整合。
影響	1.建立目标架構設計規範，并保持适時更新。2.建立內建設計規範，并保持适時更新。3.建設統一的內建平台、開發平台等應用支撐平台。

5.3 快速響應原則

描述	技術架構的設計應能快速支援業務規則及流程變革。
理由	1.提高響應業務需求變化的靈活性。2.減少應用系統變更的成本。3.通過實施參數化的可靈活配置的業務規則及流程，降低開發成本。
影響	1.設計應用系統時，應支援業務規則及流程的外部配置參數化。2.需要定義參數化的可靈活配置的業務規則及通路方式。3.可靈活配置的業務規則及可重用的基本服務将增加應用系統的前期開發成本。4.根據附加的非功能性需求來選擇成熟解決方案。

5.4 服務等級原則

描述	技術架構應能根據服務等級協定提供各種服務，滿足業務需求。
理由	提供可靠的、可重用的，以及可靈活配置的各項服務，能夠實作最佳客戶服務的業務目标。
影響	1.需要與相關部門一起，根據客戶确定的系統性能名額，确定服務等級協定的範圍并取得認可。2.需要根據各種業務需求制定并認可各種非功能性需求。3.應用系統和支撐體系架構在設計時必須要滿足非功能性需求。4.滿足特定的服務等級協定可能需要特定的硬體，軟體及設計費用。5.對不支援性能更新的第三方産品要謹慎采用。

5.5 災備原則

描述	技術架構設計時要充分考慮業務連續性需求。
原因	當災難發生時，資訊技術要支援業務的持續運作。
影響	制定災備政策、計劃和預案。