什么是架构？

passthru

浏览了CU架构设计栏目的几个有关架构的贴，我感到，几乎所有在CU发表过看法人都对架构是什么？架构师有什么责任？概念很模糊。对此，我提出个人的看法。

我想，我们先把我上面提到的两个问题放放，等到一些前提确定下来，我们再回头对这个两个问题做定义。

假设要搭建覆盖全球的一个综合应用系统，这个系统有功能点有5000万个，并且覆盖3000个业务领域范围，同时贯穿于50亿个业务种类的交易。而且，搭建这个应用系统后，对给使用这个应用系统终端的一个客户，无论这个客户在世界上哪一个主要城市，这个应用系统的响应时间要小于三秒钟。

我们可以初步估计，要搭建这个综合应用系统，经过整合的业务架构大概在3000个左右；有世界上各类计算机厂商的各类计算机平台和处理单元部件；有实现这个应用架构的各类网络结构组件和技术，包括云技术、层次和区域划分；架构中有总架构师，有各层次的分架构师；有项目主管理团队，有各层次的分项目管理团队；对3000个左右的业务，按业务分类，有首席业务专家，有相关的业务的专家群；在搭建好项目模块部件后，有相应的实施团队和相应的实施技术；等等、等等。

在这个应用场景下，从上到下描述架构，架构就是应用系统的轮廓，是一个虚拟的框架；在一个具体业务范围内，业务架构是把业务需求，按照一定的模型构造出的没有重叠的业务架构，可以付诸在硬件系统架构层硬件平台，实施于一个或多个应用子系统。架构是介于应用业务需求和实施技术之间一个脚手架。这就是架构。

在这样的应用系统搭建环境下，架构师没有业务的概念，就是制造能够方便梳理业务的架构模型，把业务专家提出来的，没有梳理过、交叉的处理业务逻辑、流程和数据，经过业务模型，形成业务架构；把成型的业务架构，在一个系统架构层面上，通过能够实现业务架构的实施团队和相关的技术，付诸实施在能够发挥应用系统运行效率的硬件平台上。

passthru

做点上述贴的补充

wang3320

我来学习下，谢谢了。

linghuchun

路过,学习学习.

passthru

我的blog：passthru.cublog.cn

passthru

   

业务架构的重要性

    我们在一个行业做项目实施有10年以上经历，比如银行业，我们会发现，银行核心系统每过三五年，就会有一次大调整，甚至推翻旧核心，重新做新的核心。这个核心更新周期，随着经济发展的速度起伏，做相应的调整。经济发展速度放缓，更新核心周期就相对长一些；经济发展速度如果加速，更新核心周期，就相对短一些。
     其它行业也有相同的更新核心的周期。
     往往我们在做新核心更新项目启动论证时，我们几乎都会有相同的结论：对旧核心布布丁丁已经到了不能实施的地步，旧的核心架构已经不能满足现有的，或将来可预见的业务需要，所以必须启动核心项目改造，用新的核心架构代替旧的核心架构。
     我们对旧核心进行分析时，我们就会发现旧核心的复杂层度已经大大超出我们能够理解接受的范围，就是说核心中的一大部分的功能点，存在重复，或部分重复功能点。如果，因为业务的需要，对一个功能点进行功能拆分，或多个已经存在的功能点进行合并，其结果，我们没有办法预见做了这个功能拆分，或合并，会对整个核心系统有什么影响？对这个风险，没有一个人敢拍着胸脯，敢承担。
     这种现象，对各行各业，对IT行业，无论是应用系统，或软件产品，都是一个结症，都有一个更新周期。圈内人对应用系统，或软件产品，已经固化了架构；圈外人有新的思想，想在找一个突破口，无论通过何种途径，有人际关系、架构、实施技术，等等。
     圈外人即使突破替代圈内人，或并列成为圈内人，过了三五年，可能被新的圈外人同样取代或并列。
     我们不禁要问，为什么会有这样的现象发生？然道在圈内的人比圈外的人智商低吗？或圈外人进入圈内后，智商被弱化了吗？
     我个人的看法，关键是有无一个能够梳理业务需求的业务架构。
     以往应用系统实施，或软件产品研发，几乎都没有一个能够梳理业务需求的业务架构。没有这个梳理业务需求的业务架构，和用这个架构梳理的过程，即使新的应用系统或软件产品“成功上线”，已经存在的大量的重复功能点，和运维期间不断积累的重复功能点，又会把应用系统，或软件产品推到一个死胡同；又把我们推到一个不得不进入的更新周期中。
     各行各业有的是比IT人员更专业的业务专家。业务专家从未梳理过多线条的业务流程功能点，特别是复杂交叉、有重复的功能点，因为每一个业务专家，由于部门分工不同，他们各自只对他们的一亩三分田的业务比较熟悉。从而，他们从未考虑过业务功能点重叠会给IT项目实施带来难题。
      ​IT人员的优势，特别是架构师，他们会采用业务架构来梳理业务需求。但是，如果IT人员若没有意识到业务架构的重要性，势必会跟随业务专家的意识，被动地拖入到周期性的更新循环当中。

passthru

补充一点：

如果采用SOA理念设计的业务架构，对一个500万左右的项目中实施，效果是惊人的。

按传统做法项目实施，项目经理计划采用20人，10个月工期，而且项目经理还不保证项目能够按期完成；采用SOA理念架构做业务架构梳理业务，在项目实施过程中，边做编码和测试，边按架构进行架构完善设计，即一方面进行业务需求的梳理；一方面又进行架构的完善、编码和测试。项目在实施过程中，仅两个主力编程，10个月后项目按期上线。在项目实施过程中，在任意时间内，业务需求都可以随时增加和调整。在运维期间，运维人员只有一个，业务需求也可以随时增加，再按业务架构，梳理到相应的架构中。

dinglang_2009

主要还是 基础架构(运维)+软件架构

pitonas

什么是架构？对此，我概念很模糊。

passthru

     架构的定义很广泛。
     我们经常说的架构是通常都是泛泛指软件架构、软件工程架构、网络拓扑架构、程序架构、软件项目业务模块架构等等，与IT有关的领域。所以，我们无形当中，就把架构定义窄义化了。

    从几何学的角度出发，不在同一个平面上的四个点才能有“架”。在这个条件下，大于四个点，并且大于四个平面组合的型才能形成“架构”。

    IT领域的各类架构都像生活里其它架构一样，都是从需求开始，需求积累到一定程度，就要对需求进行梳理，这个梳理需求的工具就是架构；把需求转换为有型的流处理，处理的形态就是架构的体现。对一个领域的业务，比如软件产品设计、网络工程实施部署和管理、银行业务、保险业务、ERP制造工作流管理、ERP物流流程管理等等，都属于各自领域的业务范围。对某种业务范围需求的梳理就是业务架构。

    做一个比喻，有了架构，就像盖房屋，业务流程就是屋樑或支柱，屋樑支柱在什么地方摆放，是架构已经设计好的位置，屋樑摆放是横的，支柱摆放是竖立的。否则，没有架构，屋樑支柱的摆放起不了支撑的作用。

    我的经验是用SOA理念设计的业务架构，并且在这个业务架构上各个功能点功能唯一；按照业务需求，通过这个业务架构设计出来的业务处理流程都是唯一的，这才是我需要的业务架构。做不到这两点的业务架构有存在这样或那样的缺陷。