本文主要是介绍系统架构的房子——论盖屋顶、铺地砖和睡大床,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
按:俗话说普通程序员写代码、二逼程序员做设计、牛逼程序员搞架构。系统架构有三个层次:企业架构、业务架构、解决方案。如果将其比譬成一个大房子,那对应的是屋顶、地砖和床。屋顶是骨架、从企业层面要去考虑的,譬如组织是一个大的技术部、还是拆成不同业务线独立作战?业务架构是地砖,这是技术角度对业务架构与规划。解决方案是大床,直接需求的载体。
大部分人只要求一张床,偶尔踩踩地砖,几乎不看屋顶。巴菲特说“反过来想,反过来想!” 学会逆向思维,先看屋顶、再踩地砖、最后想床。
开发人员对于架构这个词一定不陌生,但是我们说的架构只是产品开发中的技术相关架构,真正要做好一个产品,在技术架构之上还有其他一些架构,本篇介绍一下三类主要的架构:解决方案架构、业务架构和企业架构。有时候我们把视野拓宽一些,多锻炼自己的大局观,对自己的思维和技能都会有很大的提高。在《TOGAF 或非 TOGAF:在 RUP 之上扩展企业架构》中对比几个不同的架构框架,让我对什么是架构更清晰了。我觉得不错,所以给大家分享一下。
解决方案架构
解决方案架构是“技术性的”,它们的范围内包括各种技术元素,如软件、数据和 IT 基础架构,这些领域都是由技术人员来处理 。
业务架构
业务架构在 90 年代作为单独的领域出现了,业务架构包含过程及信息、组织和绩效等方面内容
企业架构领域
企业架构领域原则上的关注点是企业范围内的业务需求的识别、规范,及优先级划分,EA 路线图可能比单路线解决方案包含更多内容(如图 3 所示),这可能会形成多个、同时的实现。
EA 环境是全局性的,其视点是组织化的,而解决方案架构是具体到实现的。EA 主要用于企业分析、计划和架构治理。
注意:来自解决方案架构规程中的一些主题(低层次的)不含在 EA 的范围内,而许多附加的(大部分是更高层次的)主题加入了。还要注意的是关键的业务架构主题完整地包含于 EA 规程之中了。
=>更多文章请参考:《中国互联网业务研发体系架构指南》
=>更多TOP权威案例及行业标准资料请关注微信公众号:
这篇关于系统架构的房子——论盖屋顶、铺地砖和睡大床的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!