什么是架构？

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

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

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

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

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

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

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

    从几何学的角度出发，不在同一个平面上的四个点才能有“架”。在这个条件下，大于四个点，并且大于四个平面组合的型才能形成“架构”。   
    IT领域的各类架构都像生活里其它架构一样，都是从需求开始，需求积累到一定程度，就要对需求进行梳理，这个梳理需求的工具就是架构；把需求转换为有型的流处理，处理的形态就是架构的体现。对一个领域的业务，比如软件产品设计、网络工程实施部署和管理、银行业务、保险业务、ERP制造工作流管理、ERP物流流程管理等等，都属于各自领域的业务范围。对某种业务范围需求的梳理就是业务架构。
    做一个比喻，有了架构，就像盖房屋，业务流程就是屋樑或支柱，屋樑支柱在什么地方摆放，也是架构已经设计好的位置，屋樑摆放是横的，支柱摆放是竖立的。否则，没有架构，屋樑支柱的摆放起不了支撑的作用。 

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