按：俗话说普通程序员写代码、二逼程序员做设计、牛逼程序员搞架构。系统架构有三个层次：企业架构、业务架构、解决方案。如果将其比譬成一个大房子，那对应的是屋顶、地砖和床。屋顶是骨架、从企业层面要去考虑的，譬如组织是一个大的技术部、还是拆成不同业务线独立作战务架构是地砖，这是技术角度对业务架构与规划。解决方案是大床，直接需求的载体。

大部分人只要求一张床，偶尔踩踩地砖，几乎不看屋顶。巴菲特说“反过来想，反过来想！” 学会逆向思维，先看屋顶、再踩地砖、最后想床。

开发人员对于架构这个词一定不陌生，但是我们说的架构只是产品开发中的技术相关架构，真正要做好一个产品，在技术架构之上还有其他一些架构，本篇介绍一下三类主要的架构：解决方案架构、业务架构和企业架构。有时候我们把视野拓宽一些，多锻炼自己的大局观，对自己的思维和技能都会有很大的提高。在《TOGAF 或非 TOGAF：在 RUP 之上扩展企业架构》中对比几个不同的架构框架，让我对什么是架构更清晰了。我觉得不错，所以给大家分享一下。

解决方案架构

解决方案架构是“技术性的”，它们的范围内包括各种技术元素，如软件、数据和 IT 基础架构，这些领域都是由技术人员来处理 。

业务架构

业务架构在 90 年代作为单独的领域出现了，业务架构包含过程及信息、组织和绩效等方面内容

企业架构领域

企业架构领域原则上的关注点是企业范围内的业务需求的识别、规范，及优先级划分，EA 路线图可能比单路线解决方案包含更多内容（如图 3 所示），这可能会形成多个、同时的实现。

EA 环境是全局性的，其视点是组织化的，而解决方案架构是具体到实现的。EA 主要用于企业分析、计划和架构治理。

注意：来自解决方案架构规程中的一些主题（低层次的）不含在 EA 的范围内，而许多附加的（大部分是更高层次的）主题加入了。还要注意的是关键的业务架构主题完整地包含于 EA 规程之中了。

=>更多文章请参考：《中国互联网业务研发体系架构指南》

=>更多TOP权威案例及行业标准资料请关注微信公众号：

来源：软件真理与光