这篇文章上次修改于 332 天前,可能其部分内容已经发生变化,如有疑问可询问作者。 #### C信息系统架构解读 阶段c主要描述与设计一个组织的信息类型以及处理这些信息的应用系统上。氛围数据架构和应用架构 * 通常,两者均需开发 - 单情况并不总是如此。这取决于项目范围和约束。 IT2.0=it+dt 面向业务架构---双轮驱动。一个是数据架构,走dt路线,一个是应用架构,走it路线。实现业务能力的支撑(it)和赋能(dt),支撑讲究端到端覆盖,赋能讲究数据驱动,融合创新。这两者是一个协同的关系。 是先研究数据流如何支撑,还是先去规划系统如何集成串联,实现对整个业务流程的端到端覆盖。 一个叫数据流贯通。一个叫端到端覆盖。数据架构明确了贯通的内容,应用架构体现贯通的管道。数据流希望通过系统之间的集成串联,反复揉导数据流当中去,为什么要走应用整个管道呢?总归不能走excel,走纸质表单。数据上网,数据上行,是数据架构赋能业务的基本定位。 两者一个强调内容,一个强调管道。内容在管道中共享贯通,管道体现在支撑数据流转。最终共同反哺业务。 * 开发顺序可任意或并行。 - 理论上,应先开发数据架构。 - 从现实考虑,先开发应用架构或许更有效。 如果我们是稳态业务,那么应用架构为先,先塑造应用架构。 如果业务类型属于敏态。那么我们数据架构为先。 《1 如:一个企业是建筑行业的企业,他们每年有数千万个羡慕动态化的施工和开展,每个项目都需要项目管理信息。当我们构建项目管理和流程之后,是先确定数据架构还是应用架构? 整个企业的业务属于敏态,动态变化较多,那么先确定数据架构,先把项目中的人财物,及其相关的有哪些基础数据动态衍生什么数据,统计监控数据找出来,先把数据架构和确定数据内容。然后数据内容如何融入到,作为集团企业最多项目作业,统筹监管整个数据流。基于数据管控,实现经营管控。这个时候再把应用架构做出规划来。 《2 如果是传统企业,它的业务性质是稳态,属于静态的。我们可以去自上而下的研究如何推动管理机械化,先定应用架构。再看我们可以沉淀出什么数据来。 最终两者要保持同步,和业务架构一致。 * 为了确保两者之间的一致性,需要采用迭代开发方式 一致性体现在三个点: 《1 业务划分决定两者划分 数据要分类,应用也要分类。业务也需要分类。业务怎么分的类,分为几大能力类型,那么数据就怎么划分,应用就怎么归类。 《2 业务构成决定两者构成 数据构成,和应用构成,受制于业务构成。这个数据是谁的责任,就看这个数据从业务源头上来自哪个业务源头生产。 按照生产关系判定数据的责任划分。 应用归属哪个业务去开展信息化建设,看这个应用归属,服务的业务是哪个业务口,为哪个业务口做服务建设。 《3 业务交互决定两者交互 业务交互决定数据和应用交互,是一个共享交互关系。业务上交互的方向,就是数据共享的方向。 业务上交互的方向,就是应用集成的方向,财务部门统计成本提供给另外一个部门使用。成本数据是需要有财务部门提供给其他业务部门。这个就定了方向。数据共享的关系就不能让其他部门给财务部门提供成本数据了。否则就反了。 ![应用架构](https://pic.baidu-google.com/api/pics/application_arch.jpg) 应用架构分为三个步骤: 1. 找划分 2. 找构成 3. 找交互 ![交互示例](https://pic.baidu-google.com/api/pics/jiaohushili_20231225.jpg) ![数据架构](https://pic.baidu-google.com/api/pics/shujujiagou_20231225.jpg) ![数据架构主题域示例](https://pic.baidu-google.com/api/pics/zhutiyushili_20231225.jpg) 从数据流的方向上,和业务保持一致 ![关系视图,又称数据概念试图](https://pic.baidu-google.com/api/pics/guanxishitu_20231225.jpg "关系视图,又称数据概念试图,又成实体关系试图") 里面的箭头关系必须和业务保持一致。对于交互(箭头):应该是一个能力主线,对应一个共享视图,不能放在一起画一个,否则会造成关联关系的复杂性,难以呈现。 每个能力主线,独立规划它的应用架构和数据架构。 应用集成和数据共享按照能力主线分组,每个个能力主线一组,分别进行规划 * 信息系统架构是IT系统的基本组织形式,体现在如下方面: - 主要的信息类型以及处理这些信息的应用系统; - 信息与应用系统之间以及与环境之间的关系; - 治理信息系统 架构设计和严谨的原则。 * 信息系统架构解释了IT系统满足企业业务目标的方式方法。 #### D技术架构解读 在信息系统总架构确定之后,整个企业新时期的信息化应进入上什么样的平台化的环境,就是技术架构。 平台类型: 企业架构在技术架构体系当中有一个基本性的指南xx,从用技术路线形成统一标准,到用技术平台形成统一标准。我们对整个信息技术的治理,要用平台的方式,实现统一而集约的改进。 * 技术架构是IT系统的基本组织形式,体现在如下方面 - 技术架构的软件、硬件及通信技术 - 软件、硬件、通信技术之间以及他们与环境的关系 - 治理技术架构设计和演进的原则 ![技术架构](https://pic.baidu-google.com/api/pics/jishujiagou_20231225.jpg) 技术架构要赋能数据共享,赋能应用集成,寻求公共技术。每一个平台将会对外提供一系列的服务组件,他就是我们技术标准的单元。我们有了这些技术平台,上面是如何实现共享集成交互贯通的。 ![技术框架试图](https://pic.baidu-google.com/api/pics/jishukuangjiashitu_20231225.jpg) 左开发,右安全,上门户,下云化。---走向信息化的环境的平台保障机制。 以前随着系统功能增多,系统会越来越慢。所以技术架构希望我们走向---“建的出、撑得住”的技术环境。有充分的性能保障,适应业务连续性的需求。 所以为了建的出,撑得住,要做技术架构的规划和平台改造。老系统装新功能,装着装着就臃肿了,各方面性能跟不善用户评价的需要,这叫建的出,撑不住。 门户,一般走向以用户为中心的,个性化聚合的方式,实现所谓的身份聚合、功能聚合、信息聚合、应用聚合。 技术架构告诉我们走平台化的道路,所有的应用在平台化的环境当中,健康而稳定的运行。随着业务需求规模化的扩充,在弹性扩展过程中能保证性能上稳定可靠的展现 总结:ABCD---完成之后,我们的**创建** 就完成了。创建完成之后,我们第一个用途就是用它做发展规划,请见E
没有评论