怎麼理解框架、架構和企業架構？

http://ea.zhoujingen.cn/110.html

 

作軟件產品近二十多年了，「架構「真是一個重要而模糊的詞，因範圍太廣，內容太深而很差理解。而要了解企業架構，那必然要先了解架構，因此今天我和你們來聊聊「架構」。

IEEE 1471架構

        IT 這個行業中的詞彙許多都來源於傳統行業，例如「精益」」架構「」。「架構」這個詞也來源於建築學。在建築建造出來或者產品加工出來以前，設計人員用圖紙來描述本身的設計意圖。如今你要給軟件畫個圖紙，這個圖紙會有哪些要素組成？

        在IEEE 1471中是這樣描述架構元素及其關係的：

若是想要更多瞭解，你們能夠本身上網查找一下這個圖的講解，在此我就很少說了。     

架構和框架

        架構常常和框架有點關聯，容易混淆，因此在講架構時必定得說說框架。

框架的使用：

• 在軟件架構中能夠不採用任何框架，可是沒有使用框架的軟件架構經常是不可想象的。這意味着，咱們放棄了前人積累的知識財富。
• 企業級應用中要考慮的因素太多，不使用框架幾乎不可能使項目成功。
• 使用框架，意味着接受框架設計者的想象和思想，意味着使用固定的編程模式，意味着編寫指定格式的類型，意味着無條件的接受框架提供的服務，意味着你將受限於框架的能力。一種正確的作法是，在使用任何框架前，應該先了解該框架對軟件開發的種種約束，根據組織和項目的實際狀況，權衡利弊後再作決策。
• 除非你和框架設計者同樣，透徹瞭解它的創做思想以及創做細節。即使瞭解，你也可能會由於未來框架新版本的推出而產生問題。採用集成的方法來使用框架，而不是嘗試去改變它。

框架和架構的區別：

• 架構是指軟件的結構，以及結構元素之間的動態關係，而框架是架構的一個組成元素
• 從企業應用系統的角度來看，框架是編程的工具，而架構是目標
• 框架自己也具備架構，而架構能夠不考慮使用框架
• 架構對於軟件開發人員的約束是方向性的，它留有巨大的創造空間，而來自框架的約束是具體的、普遍的
• 框架爲軟件開發人員提供了豐富的服務，而架構只會對結構元素提出各類服務要求

BAPO之架構

        由於我以前作過好幾年的管理軟件以及開發平臺，因此接着我說下在軟件產品線工程方法中如何對架構進行說明的。

IEEE 1471是對通用架構的描述，FEF是一個產品線評估框架，裏面有對架構的評估。Family Evaluation Framework (FEF) 是歐洲工業界和學術界通過六年時間從衆多項目整理出來的一個評估框架，以下圖，該評估框架有5個級別， 覆蓋了軟件工程的四個評估維度（商業、架構、流程和組織），每一個維度有三到四個方面，本篇將介紹一下架構維度，這是咱們業務和開發人員最應該關注的維度。

三個方面 

BAPO對架構着重從如下三個方面考慮：

1. Asset reuse level : 重用資產
2. Reference architecture: 參考架構，做爲應用架構的基礎架構
3. Variability management: 可變性管理

Level 1: 獨立開發（Independent Development）

整體說明：只有針對單個系統的架構。

• Asset reuse level : 沒有或者毫無系統性的重用
• Reference architecture: 沒有軟件產品線架構
• Variability management: 無論理可變性

Level 2: 標準基礎設施（Standardised Infrastructure）

整體說明：重用集中在第三方基礎設施。沒有正式的可重用領域資產。

• Asset reuse level : 使用通用的第三方基礎設施。
• Reference architecture: 產品線架構基於第三方基礎設施，主要致力於使用這些基礎設施
• Variability management: 有時會受到第三方基礎設置提供的可變性限制，大部分可變性仍是由應用架構提供

Level 3: 軟件平臺(Software Platform)

整體說明：捕獲了領域通用性並在平臺中實現，全部應用能夠共用一個參考架構，經過配置平臺能夠適用與多個不一樣的產品，可是對可變性管理仍是沒有很好的支持。

• Asset reuse level : 定義了多個通用資產，在平臺和架構下進行有計劃的重用。
• Reference architecture: 參考架構做爲應用架構起點
• Variability management: 參考架構決定了核心資產支持應用開發須要進行哪些配置，有明確的應用生產計劃。

Level 4: 可變性（Variant Products）

整體說明：在產品線中明確提出可變性管理，可以很好的進行進行領域共性和可變性管理

• Asset reuse level : 應用開發能夠進行明確的可變性管理
• Reference architecture: 參考架構支持可變性管理，明確的代表使用參考架構如何支持應用架構的變化
• Variability management: 應用工程的可變性進行很好的統一管理

Level 5: 可配置（Configuring）

整體說明：參考架構佔主導，只有少許的應用架構，更多的是使用建模、腳本、工具和配置從參考架構自動生成產品。

• Asset reuse level: 系統的規劃和重用資產庫
• Reference architecture: 參考架構徹底決定了應用架構，能夠經過自動配置後生成應用
• Variability management: 變量徹底集成在架構中，變量被描述爲模型，經過有語義的語言進行管理

架構定義氾濫和統一

        愈來愈多的人發現，表述一個系統架構的方法不僅一種，一個系統中也可能有不少種不一樣的架構，並且對於什麼在架構上意義重大的見解也會隨着系統的生命週期而變化，因此會出現不少詞彙：軟件架構（softwarearchitectures）、系統架構（system architectures）、企業架構（enterprisearchitectures）、信息架構（Information）、應用架構（Application）、IT架構（ITarchitectures）、業務架構（Business architectures）、技術架構（Technologyarchitectures）、應用架構（Solution Architectures）、基礎架構（InfrastructureArchitectures）、領域架構（DomainArchitectures）等。

    其中對於從軟件開發出身的人來講，要着重關注一下業務架構，因此我這裏說下業務架構體系：業務架構體系是針對企事業信息管理系統中具備體系的、廣泛性的問題而提供的通用解決方案，更確切的說，是基於業務導向和戰略驅動的架構來理解、分析、設計、構建、集成、擴展、運行和管理信息系統，好比業務架構體系認爲一個信息系統必須由組織機構、業務流程、業務信息、業務功能、和業務語義等層次構成。

    這些架構有的還存在各自的社區力量，不一樣架構之間可能還存在一些爭鬥，因此想要統一很難，而咱們須要作的就是先對對以上這些架構詞彙所表明的知識進行學習，在掌握了基本概念之上再結合本身的實踐和思考去逐步清晰架構的概念，整理出本身的理解。

我對架構的理解

     雖然架構的定義難以統一，但做爲架構師來講，咱們仍是但願能在某些角度上達成相對統一的理解。《企業應用架構模式》認爲架構定義自己很難統一，可是可以統一的內容有兩點：

1. 最高層次的系統分解
2. 系統中不易改變的決定

    如下爲我認爲對架構還不錯的一些簡單說明，可供參考：

• 架構是一個約定，一個規則，一個你們都懂得遵照的共識
• 架構是一種主觀上的東西，是專家級項目開發人員對系統設計的一些可共享的理解
• 架構一般指產品組成部分的大粒度的組成部分的設計，架構師在特定方法下，在經驗和直接下進行系統、企業或者軟件的分解，造成大粒度的組成元素。
• 一個架構是系統的基本結構，它由多個組件以及它們彼此間的關係而組成，而且在必定環境和原則下進行設計和演變

• 架構是針對某種特定目標系統的具備體系性的、廣泛性的問題而提供的通用的解決方案。
• 架構每每是對複雜系統的一種共性的體系抽象。
• 架構讓咱們可以正確、合理地理解、設計和構建複雜的系統
• 複雜系統集成的關鍵，是基於架構（或體系）的集成，而不是基於部件（或組件）的集成。
• 架構是藍圖，是從總體到部分的最高層次的劃分。架
• 構設計是聲明性（declarative）的，而不考慮具體實現。架構是設計，可是設計不必定是架構。架構設計忽略元素內部的詳細設計，這些元素的詳細設計將由關注詳細實現的設計人員來細化。
• 架構是關注點分離
• 架構是一種權衡

企業範圍的架構

        架構是爲軟件產品服務的，而軟件產品是由IT技術人員開發的，因此以前咱們談到的架構基本上是這樣的：

        IT 專家們已經習慣於在信息系統開發和維護項目中處理應用、數據、技術和其餘解決方案架構形式。全部解決方案架構領域被看做是「技術性的」，由於它們的範圍內包括各類技術元素，例如，軟件、數據和 IT 基礎架構。這些領域都是由技術人員來處理 —— 也就是那些具備系統工程、軟件工程或 IT 管理背景的人。

        隨着IT技術的發展，以及信息化水平的提升，在 90 年代業務架構做爲單獨的領域出現了，當時許多組織接受了業務架構師角色，也對業務架構框架中應該包含的組件的內容有了通常的共識：過程及信息、組織和績效是相關聯的。

後來你們基本接受在企業範圍內的架構包括業務架構和解決方案架構兩部分：

這兩部分上接戰略，下接項目實施，今後企業架構成爲了企業的重要組成部分。

 IT架構還能夠再細分爲：應用架構、數據架構和技術架構