架构设计内容分享(一百六十七)：架构先行还是流程先行？
目录
问题提出
流程先行还是架构先行？
案例分析
面向流程软件开发的致命缺陷
价值思考
架构的核心价值是构建能力的细腰
延展思考
架构是组织与流程的再设计
总结
流程管理与架构设计需要相辅相成
问题提出
流程先行还是架构先行？
虽然架构理念近年来颇受关注，但因为实践上较为复杂，导致人们对架构的价值产生一些负面看法，甚至有这样一个问题：是否可将流程建设作为架构设计的替代手段。
这种观点是否正确？或者，如何在流程与架构两者间做好取舍？
回答这个问题前须弄清楚：流程与架构究竟是不是一回事？它们到底有没有区别？
对于这个问题，目前存在的看法包括：
1：有区别，这是两种不同的思想方法，不具备可比性，都可以用来做业务分析与优化。
2：有区别，架构是面向要素与关系的，流程是面向过程的，两者思想方法不同，作用也不同，前者可以指导管理优化与IT实现，后者不考虑IT，但可作为IT的业务侧需求。
3：没有本质区别，架构做顶层设计，流程做底层设计，流程是架构的落地手段。
4：流程我明白是啥，架构是啥我不太清楚，听起来高大上，但从实践看似乎没啥用。
5：没有区别，看你的观点了，你完全可以把流程作为架构来用，我们单位就是【某央企IT负责人】。
在上述看法中，第4种较典型，属于多数，体现了流程与架构市场的竞争态势，前者有较成熟的市场基础，后者目前还是阳春白雪。看法2相对看法1更专业些，但有彻底认知的还是很少，这也导致了看法4的流行。看法5存在于部分企业，是管理上的权宜选择，看法3只存在于咨询方，是项目实施的一种方法。
但是，对流程与架构的区分绝不只在于商业和管理理念的博弈上，如果止步于此，就是对专业精神和行为理性的放弃，须从技术的底层逻辑和管理的根本价值上明确区分，否者，我们就只能生活在混沌中。
案例分析
面向流程软件开发的致命缺陷
举个现实中的例子：
某企业IT部技术力量较强，有10多名软件开发人员，在多年的信息化建设中开发了大量的内部管理软件，这些软件从投资决策到方案设计来自不同时期且完全独立，因此造成一些混乱，不同的软件有时会在业务应用场景上存在交叉和紧密关联，导致一个软件发生修改时，会因为业务规则的优化导致相关其它软件发生同步修改，使得近年IT系统的维护成本与难度直线上升。
这种状态是目前国内很多企业信息化方面的现状，也正是这种状态导致了架构方法日益受到关注。
如下此企业生产相关软件梳理形成的组件清单局部示例：
一级组件：采购过程管理
二级组件：安全库存管理、下场监制验收、到货登记、到货检验、入库登记、计划预警与催货、退换货、采购过程查询。
一级组件：生产过程管理
二级组件：生产主计划制定、工单排产、生产准备、生产任务协调、过程质量检验、出入库管理、生产资源管理、生产过程监控。
看到这个示例时，我眼前一亮：这是个非常典型的示例，可以据此回答架构与流程的很多重要问题。
第一：上述软件组件清单并非架构视角，而是流程视角
采购管理软件和生产管理软件完全从业务流程运行场景视角出发，提出功能需求并进行软件开发，所开发的功能恰好与各自业务场景中的流程环节相对应，具有局部的良好适应性（局部设计与验证），但在组织整体上就带来了混乱（需要整体设计与验证）。
第二：这直接导致了一个典型的架构问题，功能交叉重叠，运维升级困难
比如采购过程中存在检验、生产过程中也存在检验，就检验来说，需要按照产品技术要求和质量控制规范订立统一检验规则，同时按照规则根据不同的检验结果进行后续处理，检验与后续处理规则的制定由质量管理部门统一制定，但在软件实现上分散在不同的模块，同时质量数据也相应分散在不同的地方，当采购模块在升级改造过程中对业务规则和数据规范进行调整时，就直接影响了生产模块。
与此类似的还有出入库管理，包括出入库的仓储管理归属与同一个部门，出入库管理规则是一致的，但软件功能分散在不同系统，由此导致和质量领域相同的问题。
第三：为扭转不利现状，必须从架构视角对软件进行重构
解决上述问题须将软件开发从流程视角切换到架构视角。
从架构视角，须跳出具体的流程场景定义出共享的业务能力，也就是专业化可重用的业务组件，以此映射为可重用的应用组件。
从上述两个流程场景中，定义出如下业务组件：
计划分析：采购策略、计划策略（缺失）、生产计划分析制定、工单排产
计划监控：可覆盖生产采购两个方面，分为采购类型计划的制定与监控和生产类型计划的制定与监控。
生产控制：生产准备、生产任务协调
生产资源管理：设备工器具管理
质量过程控制：到货检验、生产过程检验、外包下场监制验收（基于标准的检验类型进行参数化改造形成）。
仓储物流管理：出入库管理、到货等级、退换货。
对于上述组件，质量控制与仓储物流是共享的能力，需要重点设计，包括内部作业规范、数据标准、控制参数。特别是控制参数，通过不同的业务参数，可适应不同的业务场景要求。
这样的设计方法，就是架构方法，也是架构的核心价值所在。
价值思考
架构的核心价值是构建能力的细腰
有人认为，架构的核心价值是模型化（包括元素和关系），但模型化是架构的手段和表现形式，不是价值所在。
架构的核心价值在商业层面：建立能力细腰，适应商业多变。
做产品管理的都熟悉一个概念，就是建立产品与技术平台的细腰，细腰里定义了产品CBB组件和技术CBB组件，通过参数化可调的CBB组件，向下对接整合不同的技术要素，向上适应产品线的灵活扩展。
架构同样如此，通过构建业务能力细腰中的标准化组件，向下整合不同的能力要素（过程、方法、规范、标准、人员、软件、物理、数据…），向上适应不同的业务场景（不同外部需求对能力单元的区别性调用）。
这样的能力细腰定义完成，就形成了组织的可持续积累发展的核心能力资产，就能以低成本高质量的柔性组合满足灵活的商业需求。
延展思考
架构是组织与流程的再设计
流程面向过程协同与价值输出，架构面向共享能力识别与专业化建设发展。
在4A架构中，从业务架构到应用架构，是业务能力的识别定义到数字化实现。
流程架构这个名词，其实是不合逻辑的说法。
上世纪八九十年代兴起的BPR，口号是业务流程再造，其逻辑是打破部门强，将分散的业务活动整合到端到端流程中，现在进入架构了时代，就进入了下一个循环：将流程中的共享能力抽象出来进行专业化管理。
通过专业化的业务能力组件定义、建设、管理和数字化应用，在实现组织能力资产积累管理的基础上端到端地服务于客户价值的实现。
相对于BRP的流程再设计，架构是“组织+流程”的再设计。
经过再设计，组织能力单元具有了标准化和参数化可适应特征，流程具有了柔性化敏捷可重构特征。
如果我们没有这种思想，认为只要定义了要素和关系，就形成了架构，那么架构设计将难以体现业务价值要求，就成了庸俗的架构，将落入形式主义的窠臼，成为不懂IT的中层对不懂IT的高层讲解什么是IT的形式主义工具。
总结
流程管理与架构设计需要相辅相成
流程管理的目标是面向价值创造过程，架构设计的目标是面向能力积累建设。
架构是解构，流程是重组，在组织设计中两者方向相反但相辅相成的两种方法和作用力。
从再设计视角看，架构中的能力组件也是流程中的构件，构件的价值是将共享流程分离出来，通过标准化再设计使其达到可灵活适应性重用的状态。
因此，架构中有流程，流程中也有架构。
通过架构，实现流程的标准化和柔性化，通过流程，对架构提出来自多场景的能力需求。
两者必须相互结合，无法相互替代，也不能将流程简单的作为架构的细化落地手段，这样做，实际上是没有清晰定位架构的价值，并回避了架构设计的困难。