業務架構：這與概念架構有何不同？

Question

我聽到很多關於業務架構的知識，想知道這與概念架構有何不同？提前謝謝了。

Answer 1

軟件架構和EA世界中的所有概念通常都很難確定，這些答案是根據維基百科和我自己的理解，但是您的里程可能會有所不同。

術語「Business Architecture」不適用於軟件。這是一個更全面的業務視圖，包括業務流程，治理和信息。公司的企業架構師可能會對此負責，其中描述的一些流程可能是軟件工件或由軟件系統支持，但總的來說，這是一個更高層次的以業務爲中心的視圖。業務架構將被一家公司的高管用來幫助他們制定與其公司系統運營相關的高層決策和計劃。

術語「Conceptual Architecture」（以軟件術語）是指軟件系統的邏輯和其他更高級別的體系結構視圖。這將是您可以在軟件體系結構文檔中找到的建築文檔類型。 「概念架構」應該足夠高，以便非技術用戶可以理解。

Answer 2

架構可以被認爲是一致的相關抽象集合。設計中有不同的組合。一套描述業務環境。另一個可能描述數據上下文。

當人們不小心避免混淆抽象集時，面向對象的設計經常崩潰。 （見「高內聚/低耦合」）。因爲它們不是孤立的;你的代碼將反映每個方面。

Answer 3

業務架構是企業架構的一部分。技術架構涵蓋基礎設施和應用領域。但它們都是整個「事物」的一部分。業務架構描述定義和指導業務的人員，流程/方法和標準/技術（無需具體參考表面上提供提高生產力的「技術」）。有業務標準，度量和度量標準可以用來做出業務決策，包括做什麼，什麼時候做，什麼時候做什麼。其中大部分可能（也可能有時）在沒有自動支持的情況下執行（筆/紙，思想/原因，面對面討論）。

自動化（技術基礎設施，系統/應用程序/數據庫） - 如果我能夠如此徹底地提及「IT」，理想地支持業務。但是，如果沒有技術架構和方法來顯示它如何映射到所需的業務功能（由業務架構描述），您怎麼知道是否和如何？該映射是通過業務和技術架構之間的概念架構「層」完成的。

概念架構將業務架構（包括計劃，流程流程，組織結構圖，活動描述，法規，處罰等）融入一套基本的業務戰略和信息需求，原則，約束條件和假設，可以與技術架構/ IT計劃（投資組合/應用程序）和運營要求，原則，約束和假設進行比較。它本質上是一組概念，將業務應該與IT應該做的事情聯繫起來。概念架構之上是「業務」。同樣，在IT的「低於」它，概念架構必須反映IT看到它的真相。是的，這是一個政治敏感的東西！

概念性體系結構允許規劃人員爲企業最有用的工作提供建議。對於具有許多移動部件的複雜現代化而言，這可能非常有用 - 至少可以確定優先次序並確定快速勝出。從業務POV，它還可以在考慮業務變化時提供自動化支持的評估。但是，架構師必須認真協調其信息與IT領導力，以最大限度地減少誤解。