【银行架构day1】一个银行的信息系统架构是什么样子

 

这是《银行信息化丛书》读书笔记2。做企业架构意义很大,架构的治理更重要,因为要让架构发挥作用。企业架构开发、治理内容很多,框架理论体系就要很长的学习周期和实际经验。本篇是作者的实践总结,比较精简的讲解如何运作架构治理。

架构治理主要内容,就是要进行架构开发,以及所有的IT项目的实施都要遵循此架构。只要实施架构治理,能解决IT的大部分问题。快速满足业务要求、大幅提高IT的复用性,使繁多的系统变得简单,保障系统的质量以及知识的传承。重视技术、管理出色的企业必定会在技术管理领域进行架构治理,可以使业务与IT融合,避免IT各个项目团队各自为战。

 

目录

企业架构

系统架构

架构治理定义

架构治理框架

架构实施的治理

架构成熟度与架构能力框架

 

企业架构

架构分企业架构与系统架构两个层次。对于企业架构开发,作者主要采用了Togaf框架及其开发方法。主流的框架还包括Zachman(书中采用的)、FEA等。 Togaf在网上可下载,有7百页,在实践中大部分可以裁剪掉。本篇可视为Togaf的最佳实践,看完本篇就明白怎么进行企业架构开发、治理。

企业架构包括了业务架构、IT架构,关系如下:


【银行架构day1】一个银行的信息系统架构是什么样子_第1张图片

对于技术人员来说,业务架构可能不太好理解。这是业务架构实例图,来自一个成功的财务系统项目的案例。业务部门清晰的画出了成本中心组(组织机构)、所有的的业务流程(图中是一个)、财务的愿景、中长期的规划。

 

组织架构
【银行架构day1】一个银行的信息系统架构是什么样子_第2张图片

 

业务流程

【银行架构day1】一个银行的信息系统架构是什么样子_第3张图片

 

业务愿景

 

【银行架构day1】一个银行的信息系统架构是什么样子_第4张图片

 

业务规划

 

【银行架构day1】一个银行的信息系统架构是什么样子_第5张图片

业务架构的重要性是显然的,技术只不过是业务的信息化工具而已。在很多业务领域,作者经历的项目组经常遇见业务组织架构混论的情况,比如不同层次的在机构数下私自设立机构,机构的用途也不一样,导致后续的数据统计、流程紊乱。

在业务架构开发方面,会面临如下情况

1.  有成熟的组织与流程,但用户整理不出来。

2.  用户没有很好的管理组织与业务流程。

3.  组织架构与流程是不稳定的,在不停的变化。

无论哪种情况,如果要做企业架构,首先要做的是业务咨询,帮助用户一起做业务架构。有的企业跳过业务架构,直接做IT架构,无源之水,丧失了企业架构的基本目的。

 

应用架构。比较好容易理解,我们来看下一个大银行的顶层应用架构,比较清晰的划分了大的应用领域范围。实践中,还需要继续细化每个领域到功能模块。应用架构还需要包括公共的应用组件、功能模块的协作关系、功能模块之间的集成或者接口关系。

 

数据架构。主要包括数据模型、数据分布、数据交换技术规范、数据分布等。在下一篇中,还会详细讲解数据架构。这是一个银行的数据分布的例子。

 

 

技术架构 就是我们用的开发语言、开发框架; 各个应用的集成框架;所用到的各种基础软件,包括OS、数据库、缓存、应用服务器、页面服务器、负载等;基础硬件,包括服务器、网络、存储等,以及各种通用技术组件,包括身份验证、安全、权限、消息队列等等。以上要作为标准和规范,要求各系统执行。

 

系统架构

我们完成了企业架构后,就很容易开发具体的系统架构。对系统架构师的能力要求也会降低很多。这也是企业架构的意义。

系统架构是指对实现功能需求、非功能需求的信息系统在设计宏观层面的技术决策,其决策的结果是把信息系统划分为一个或多个结构或视图,包括逻辑、物理、开发、运行、数据等方面。以指导概要设计与详细设计的开展。

其中开发视图都是标准的,可以直接照抄企业架构;物理视图中的机器配置是标准的,根据应用需要,配置服务器数量。逻辑架构的设计着重考虑功能需求,其关注点主要是行为或职责的划分,最终,将不同的职责分配给逻辑层、功能模块等不同粒度的逻辑单元,并描述这些逻辑单元之间的关系。体现为分层、模块的划分决定和不同逻辑单元之间的交互接口和交互机制。在具体实践中,使用visio、ppt描述不同的逻辑单元等。动态方面,会更多的采用UML序列图。

下面是一个物理视图和开发视图的案例。

【银行架构day1】一个银行的信息系统架构是什么样子_第6张图片

【银行架构day1】一个银行的信息系统架构是什么样子_第7张图片

对架构开发的总结

业务架构最重要,重要的话说三遍。做完业务架构,再做应用架构,最后才是数据架构和技术架构,这两个架构是用来支持应用架构的。顺序绝对不能错。有了企业架构,系统架构就像高速公路上跑的汽车一样,只有一条通途大道,不会走错。

 

 

架构的治理

架构治理是实施架构过程中保持各方利益最大化的制度安排,是一种激励、监督、制衡机制。实施对架构组件与架构活动的管理与控制,以确保组织内的架构的有效引进,实施,和演进。并以确保符合内部和外部标准和监管义务。架构治理的目标,是要让架构与业务目标保持一致性(《IT架构治理》,刘云峰2014)。我们在通俗的说,搞IT是很困难的,要获得领导、用户、IT组织内的认同,要让各个不同板凳屁股取得一致,架构治理就是干这个的。在IT内部,就是让各个项目组不要重复建设,采用统一、标准的技术路线。

以下是作者总结架构治理的框架。架构治理的基础是 组织、流程、工具、预算等。进行架构治理的组织必须获得相应预算,才能做架构开发工作,标准的应用组件、技术组件开发,以及做一些迁移的工作。活动内容是架构实施与标准建设。标准建设的目的让系统遵循架构要求,但要尽可能的让系统开发的时候,使用标准的组件,自动符合标准要求。

【银行架构day1】一个银行的信息系统架构是什么样子_第8张图片
 

关于架构的实施。有很多企业隔很多年做一次大的企业架构规划,另外有的企业只在系统设计的时候,检查系统设计是否符合标准与规范。这两个都是架构治理的重大误区。我们都知道做IT系统,7分业务,3分技术。合理的做法是一年一规划,三年大规划。架构的治理应该贯穿整个系统的生命周期。尤其是项目任务的管理。需要在每年规划的时候,考虑全年的所有任务。在每次任务立项的时候,需要架构治理组织进行初步的评估,包括是否符合应用架构、技术可行性等。原因很简单,如果都立项了,在设计评审进行管控,如果走了弯路,一切都晚了。比如和其他系统重复建设了,结果需求、设计工作都白做了。甚至系统都开发了大半了。

【银行架构day1】一个银行的信息系统架构是什么样子_第9张图片

再另外补充两个内容。架构治理成熟度与架构师能力框架

 

【银行架构day1】一个银行的信息系统架构是什么样子_第10张图片

 

【银行架构day1】一个银行的信息系统架构是什么样子_第11张图片

架构治理总结

一个企业每年都需结合年度任务,开发企业架构。开发企业架构工作量比较大,但无论是否能做得很细致,都比不做好。在系统生命周期中,管好任务比管好设计更加重要。架构治理组织要在立项审批阶段掌握一定的话语权。

 


=>更多文章请参考《中国互联网业务研发体系架构指南》https://blog.csdn.net/Ture010Love/article/details/104381157

=>更多行业权威架构案例、领域标准及技术趋势请关注微信公众号 '软件真理与光':

公众号:关注更多实时动态 更多权威内容关注公众号:软件真理与光

你可能感兴趣的:(业务技术)