这是《银行信息化丛书》读书笔记2。做企业架构意义很大，架构的治理更重要，因为要让架构发挥作用。企业架构开发、治理内容很多，框架理论体系就要很长的学习周期和实际经验。本篇是作者的实践总结，比较精简的讲解如何运作架构治理。
架构治理主要内容，就是要进行架构开发，以及所有的IT项目的实施都要遵循此架构。只要实施架构治理，能解决IT的大部分问题。快速满足业务要求、大幅提高IT的复用性，使繁多的系统变得简单，保障系统的质量以及知识的传承。重视技术、管理出色的企业必定会在技术管理领域进行架构治理，可以使业务与IT融合，避免IT各个项目团队各自为战。
目录
企业架构
系统架构
架构治理定义
架构治理框架
架构实施的治理
架构成熟度与架构能力框架
企业架构
架构分企业架构与系统架构两个层次。对于企业架构开发，作者主要采用了Togaf框架及其开发方法。主流的框架还包括Zachman（书中采用的）、FEA等。 Togaf在网上可下载，有7百页，在实践中大部分可以裁剪掉。本篇可视为Togaf的最佳实践，看完本篇就明白怎么进行企业架构开发、治理。
企业架构包括了业务架构、IT架构，关系如下：
对于技术人员来说，业务架构可能不太好理解。这是业务架构实例图，来自一个成功的财务系统项目的案例。业务部门清晰的画出了成本中心组（组织机构）、所有的的业务流程（图中是一个）、财务的愿景、中长期的规划。
组织架构
业务流程
业务愿景
业务规划
业务架构的重要性是显然的，技术只不过是业务的信息化工具而已。在很多业务领域，作者经历的项目组经常遇见业务组织架构混论的情况，比如不同层次的在机构数下私自设立机构，机构的用途也不一样，导致后续的数据统计、流程紊乱。
在业务架构开发方面，会面临如下情况
1. 有成熟的组织与流程，但用户整理不出来。
2. 用户没有很好的管理组织与业务流程。
3. 组织架构与流程是不稳定的，在不停的变化。
无论哪种情况，如果要做企业架构，首先要做的是业务咨询，帮助用户一起做业务架构。有的企业跳过业务架构，直接做IT架构，无源之水，丧失了企业架构的基本目的。
应用架构。比较好容易理解，我们来看下一个大银行的顶层应用架构，比较清晰的划分了大的应用领域范围。实践中，还需要继续细化每个领域到功能模块。应用架构还需要包括公共的应用组件、功能模块的协作关系、功能模块之间的集成或者接口关系。
数据架构。主要包括数据模型、数据分布、数据交换技术规范、数据分布等。在下一篇中，还会详细讲解数据架构。这是一个银行的数据分布的例子。
技术架构。 就是我们用的开发语言、开发框架； 各个应用的集成框架；所用到的各种基础软件，包括OS、数据库、缓存、应用服务器、页面服务器、负载等；基础硬件，包括服务器、网络、存储等，以及各种通用技术组件，包括身份验证、安全、权限、消息队列等等。以上要作为标准和规范，要求各系统执行。
系统架构
我们完成了企业架构后，就很容易开发具体的系统架构。对系统架构师的能力要求也会降低很多。这也是企业架构的意义。
系统架构是指对实现功能需求、非功能需求的信息系统在设计宏观层面的技术决策，其决策的结果是把信息系统划分为一个或多个结构或视图，包括逻辑、物理、开发、运行、数据等方面。以指导概要设计与详细设计的开展。
其中开发视图都是标准的，可以直接照抄企业架构；物理视图中的机器配置是标准的，根据应用需要，配置服务器数量。逻辑架构的设计着重考虑功能需求，其关注点主要是行为或职责的划分，最终，将不同的职责分配给逻辑层、功能模块等不同粒度的逻辑单元，并描述这些逻辑单元之间的关系。体现为分层、模块的划分决定和不同逻辑单元之间的交互接口和交互机制。在具体实践中，使用visio、ppt描述不同的逻辑单元等。动态方面，会更多的采用UML序列图。
下面是一个物理视图和开发视图的案例。
对架构开发的总结
业务架构最重要，重要的话说三遍。做完业务架构，再做应用架构，最后才是数据架构和技术架构，这两个架构是用来支持应用架构的。顺序绝对不能错。有了企业架构，系统架构就像高速公路上跑的汽车一样，只有一条通途大道，不会走错。
架构的治理
架构治理是实施架构过程中保持各方利益最大化的制度安排，是一种激励、监督、制衡机制。实施对架构组件与架构活动的管理与控制，以确保组织内的架构的有效引进，实施，和演进。并以确保符合内部和外部标准和监管义务。架构治理的目标，是要让架构与业务目标保持一致性（《IT架构治理》，刘云峰2014）。我们在通俗的说，搞IT是很困难的，要获得领导、用户、IT组织内的认同，要让各个不同板凳屁股取得一致，架构治理就是干这个的。在IT内部，就是让各个项目组不要重复建设，采用统一、标准的技术路线。
以下是作者总结架构治理的框架。架构治理的基础是 组织、流程、工具、预算等。进行架构治理的组织必须获得相应预算，才能做架构开发工作，标准的应用组件、技术组件开发，以及做一些迁移的工作。活动内容是架构实施与标准建设。标准建设的目的让系统遵循架构要求，但要尽可能的让系统开发的时候，使用标准的组件，自动符合标准要求。
关于架构的实施。有很多企业隔很多年做一次大的企业架构规划，另外有的企业只在系统设计的时候，检查系统设计是否符合标准与规范。这两个都是架构治理的重大误区。我们都知道做IT系统，7分业务，3分技术。合理的做法是一年一规划，三年大规划。架构的治理应该贯穿整个系统的生命周期。尤其是项目任务的管理。需要在每年规划的时候，考虑全年的所有任务。在每次任务立项的时候，需要架构治理组织进行初步的评估，包括是否符合应用架构、技术可行性等。原因很简单，如果都立项了，在设计评审进行管控，如果走了弯路，一切都晚了。比如和其他系统重复建设了，结果需求、设计工作都白做了。甚至系统都开发了大半了。
再另外补充两个内容。架构治理成熟度与架构师能力框架
架构治理总结
一个企业每年都需结合年度任务，开发企业架构。开发企业架构工作量比较大，但无论是否能做得很细致，都比不做好。在系统生命周期中，管好任务比管好设计更加重要。架构治理组织要在立项审批阶段掌握一定的话语权。
=>更多文章请参考：《中国互联网业务研发体系架构指南》https://blog.csdn.net/Ture010Love/article/details/104381157
=>更多行业权威架构案例、领域标准及技术趋势请关注微信公众号 '软件真理与光'：
国家级软件工程
博客专家
发布了172 篇原创文章 · 获赞 388 · 访问量 18万+
私信
关注
标签：架构,系统,银行,业务,day1,开发,治理,企业 来源： https://blog.csdn.net/Ture010Love/article/details/104356461
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。