在数字化转型的大潮中，众多企业将业务与科技的深度融合视为核心发展战略。
阿里的中台战略曾被众多企业所推崇，但其实该中台在业务宣传中更多的让人GET到的是IT系统架构应该如何搭建，个人理解，其精髓应该在阿里的电商业务测的能力构成分分合合。横空出现的那段时间确实让人们眼前一亮，提供了不少业务与IT应如何共处共生的思考与探索。
其实每个企业的业务架构模式和设计方法不同，但其发展趋势都在一个整体脉搏上。如今的企业，需要基于企业级业务架构设计来实现组件化开发，是企业数字化转型的优选路径，更是弥合业务与技术之间“数字鸿沟”的有力抓手。
看看马斯克的火星计划就知道了，他更希望把复杂系统的问题尽量简单化，简单到组件规模化、标准化可控...
对于业务而言，怎么让IT系统性的、保持一致的懂他们在说什么？
这是个难题，今天我跟你聊了一段儿库存，明天我跟你聊了一段儿进货量，我说到哪儿你做到哪儿...就不能多想一想么？是的，是不能多想，因为对大多数企业IT而言，你说的就是一需求任务。
案例一：德国某汽车制造商
业务部门提出改进生产线的需求时，IT部门关注技术实现的细节，而忽视了这一改变对整个生产流程的影响。
据统计，该企业在过去三年内因为业务与IT沟通不畅导致的项目延误和预算超支高达20%。
案例二：法国某零售巨头
在推进其电子商务平台升级时，业务部门希望通过升级平台来提升用户体验和销售额，但IT部门在理解业务需求时存在偏差，导致开发出的平台功能与实际业务需求不符。
根据该企业的一项内部调查显示，约有40%的业务部门员工认为IT部门对业务需求的理解不足，导致项目效果不尽如人意。
案例三：英国某金融服务公司
业务部门提出了对风险管理系统的升级需求，但IT部门在实现过程中只关注技术层面的被动实现，而忽视了业务层面的实际需求。
据该企业的一份报告显示，由于业务与IT沟通不畅，导致风险管理系统升级项目延期了六个月，并额外增加了10%的预算。
对于IT，业务架构的认知度并不如需求分析那样明确，业务架构师的角色也远不如产品经理那样常见，大家总说BA、BA，BA到底是个啥，是Business Analysis还是Architecture，这是俩截然不同的角色。
那么，为何业务架构总给人上述犹抱琵琶半遮面、欲语还羞的感觉？
首先，业务是业务，IT是IT，业务会认为我遇到了问题，请你IT帮我把这个事儿办了就结束了，至于怎么实现我不管，我提Requirement了...IT则认为你今年赚不到钱跟我也没大关系，你挨老板骂了我也没必要听得见，也没关系，我就一IT搬砖的，你提什么我做什么，其他的事儿我也没必要操那么多心。
同时，传统的单体式或竖井式开发模式仍然占据主导地位。这种开发模式基本上没有横向视角，因此无需过分强调业务架构。通常的产品分析或需求分析便足以满足开发的需要。在这种情况下，业务架构的作用自然被淡化。
其次，业务架构的设计的复杂性与长期性。特别是对于大型企业而言，其业务错综复杂，要想梳理出一个清晰、合理的业务架构绝非易事。
从战略的分解、业务架构自身的整合与标准化，再到IT设计的过渡，每一个环节都充满了挑战。业务越复杂、越宽泛，就越难以驾驭。
这需要企业领导层的战略前瞻性、坚定性与探索中的柔韧性。为什么现在一探银行EA，大家都讲建行，显然人家是在大家都不看好EA摸索的前提下，鉴定的把一个又一个坑给填平了，走出了一条属于自己的路。
如果模式已经存在了，再复制，或许讨巧，但永远顶多也就是行业老二，唯马首是瞻。
再者，实施过程中的偏离也是导致业务架构“变虚”的原因之一。在施工过程中，由于各种客观因素的影响，实施可能会偏离原先的业务架构。如果这种偏离没有得到及时纠正或调整架构，久而久之就会造成业务架构的失真。
这恰恰是越来越多企业开始成立架构办公室的关键原因，因为架构需要长期的专家治理与需求管控，现在不仅是银行、汽车、航空，很多大型企业都已经成立了架构办，包括宁德时代在内，据我了解也成立了相关部门，这是先进性使然。这个架构办他不是做项目实施落地的，而恰恰是督导多个项目实施不走偏的。
从诞生之初，业务架构就明确了自己的使命：面向复杂系统构建，降低复杂度，更好地规划系统。从组织能力培育的角度，参与过业务架构设计工作的业务人员，他们的逻辑思维能力、结构化能力、企业级观念和意识都会得到明显的提升。
企业需要加强业务架构师团队人才的培养和引进。业务架构师不仅要具备深厚的业务知识和技术背景，还需要具备战略眼光和沟通能力，你想找一个啥都懂的人概率极低，但是找几个差不多的人做能力拼图，那问题不大。他们能够站在企业的高度，洞察业务的本质和发展趋势，为企业的数字化转型提供有力的支持。
在构建企业级业务模型时，标准化是一个不可或缺的过程。这是因为，为了确保企业级系统的高效运转和灵活性，我们必须对企业所有业务领域进行横向对比分析，力求在设计上实现“以更少支持更多”的目标。在这个过程中，如何平衡快速响应和减少重复开发，成为了一个亟待解决的难题。
标准化的基本方法
要实现业务架构模型的标准化，我们需要从数据标准化和任务标准化两方面入手。其中，数据标准化尤为重要。在构建企业级数据模型时，我们必须确保数据实体和属性的唯一性，避免因为重复的概念导致数据出现“同义不同名”的情况。这样不仅能提高数据的使用效率，还能确保统计结果的准确性。
与数据标准化相比，任务标准化则更具挑战性。由于没有严格的标准可供参考，我们在进行任务标准化时切忌机械操作。下面，我将简要介绍任务标准化的基本过程：
分析重复的业务动作：在对接过程中，我们经常会遇到多个不同的任务都可能对同一个数据实体在不同时间进行写操作的情况。
例如在电子商务领域，个人用户在注册账号、购买商品、收货地址管理以及售后服务等多个环节都可能需要更新其个人信息和收货地址。
在进行企业级标准化之前，这些环节中的信息更新操作可能各自独立，缺乏统一的流程和标准。这不仅会导致重复开发和维护的成本增加，还可能因为信息不一致而影响用户体验和企业的运营效率。
具体来说，用户在注册账号时可能需要填写一次个人信息和收货地址；在购买商品时，又可能需要再次确认或修改收货地址；在售后服务环节，又可能因为地址变更而需要更新信息。这些看似简单的重复动作，如果没有经过企业级标准化的处理，就可能导致数据的不一致和操作的繁琐。
因此，在电子商务领域，我们需要通过任务与实体之间的写操作对应关系，清晰地识别出这些重复动作，并对其进行标准化和整合。例如，可以设计一个统一的用户信息管理模块，让用户在一个地方就能完成所有个人信息的更新操作，同时确保这些更新能够同步到各个业务环节中。这样不仅能提高用户的操作效率和满意度，也能降低企业的开发和维护成本，提升整体运营效率。
做出关于标准化的建模判断：在找到重复动作后，我们需要做出建模决策。这涉及到是否将相关任务集中建模或分开建模的问题。
以制造业为例，我们可以将与产品制造相关的所有数据聚集在一个主题域下（如产品制造主题域）。
在这个主题域下，我们可以将各个业务领域中与产品制造相关的任务或操作进行抽象和整合。
在产品设计阶段，需要管理产品的设计信息、规格参数和BOM（Bill of Materials，物料清单）等数据；
在生产阶段，需要跟踪生产进度、记录质量检测和操作员信息等；
在供应链管理阶段，需要与供应商协作，管理物料采购、库存和物流等数据。
通过将这些与产品制造相关的数据集中管理，我们可以抽离出各个业务领域中共同使用的组件，如产品信息管理组件、生产进度管理组件、质量检测管理组件等。这些组件可以被不同业务领域共享和复用，避免了重复开发，提高了系统的灵活性和可维护性。
此外，通过将数据聚集在主题域下，我们还可以实现数据的统一管理和维护，确保数据的准确性和一致性。这对于制造业来说至关重要，因为任何数据的不一致或错误都可能导致生产延误、质量问题和成本增加。
流程模型与数据模型的语义对接：当我们通过工具筛查和语义分析解决了多数数据概念重复问题后，数据实体和属性基本保持唯一。此时，我们可以将流程模型与数据模型进行语义对接，识别任务所需使用的数据实体，包括读和写两类。这种对接需要我们从语义层面去理解流程和数据的关系，而不仅仅是简单地勾连流程与数据之间的关系。
虽然标准化过程看似简单明了，但在实际操作中却可能出现“过度整合”的问题。这通常发生在看似相近的业务领域以及一个领域内部的多个产品之间。由于业务建模是一种“纸上操作”，分、合都相对容易，因此建模者很容易产生整合的惯性。
为了避免这种错误，我们需要从业务和数据两方面进行综合考虑。
在业务方面，我们需要重新审视和理清业务流程，明确具体差异；
在数据方面，我们需要重新检视数据实体划分的颗粒度是否正确，是否因为包含的属性过多而导致内聚性不够。
只有确保数据实体颗粒度的合理性，才能避免不合理的标准化结果。
在解决标准化问题的征途上，我们或许无法找到一把万能的钥匙，但我们可以确信，高质量的模型和系统离不开业务与技术的深度融合。这种融合不仅依赖于建模者的丰富经验，更依赖于高质量的建模输入——这包括详尽的业务资料和富有经验的业务人员。单纯地阅读资料，是难以真正领悟业务的精髓的，尤其是那些充满变数的“活跃业务”。
当业务人员与技术人员携手合作，他们所能创造出的模型和系统质量将达到一个新的高度。以下为三类案例。
他们坚定地推进数字化转型，引入了占员工比例约15%甚至20%的技术人员，并直接派驻到业务部门与之共同工作。这种人员结构的调整，无疑为他们的业务创新和技术进步注入了强大的动力。
亚马逊的技术人员不仅负责开发和维护基础设施，还积极参与业务决策和创新过程。例如，亚马逊的推荐算法团队与商品销售团队紧密合作，根据用户行为数据优化推荐算法，从而提高销售额和用户满意度。这种合作模式使亚马逊能够迅速响应市场变化，持续推出创新服务，如Prime会员、Alexa智能助手等，巩固了其在电商和云计算领域的领先地位。
特斯拉的工程师和产品团队紧密合作，不断推动电动汽车技术的创新和突破。例如，特斯拉在电池技术、自动驾驶和车辆设计等方面取得了多项突破，这些成果不仅提升了产品的性能和质量，还为消费者带来了全新的驾驶体验。特斯拉的成功证明了当业务和技术团队携手合作时，可以创造出颠覆性的产品和服务，引领整个行业的变革。
为什么IT人员明知业务架构庞杂且难于设计、难以设计，企业却还是要做呢？
很简单，因为企业需要。一旦不合理的设计进入开发阶段，纠正的成本将会大大增加。不是你愿不愿干的问题，而是必须跟业务一起这么干的问题，否则违背整体最佳原则。如果是传统IT，那就必须向业务转型，或早或晚。
对于大型复杂系统而言，由于面临的问题域极为庞大，因此需要一套清晰的业务与IT的架构映射关系来指导企业的持续建设。这就像人们在生活中对地图的依赖一样，只有践行标准化，我们才能拥有一张准确的“地图”。
在构件模型的抽象要素及逻辑关系中，我们可以看到模板、构件、参数、服务、报文以及实例化等关键要素之间的相互作用和关系。基于这些要素和逻辑关系，我们可以设计出一个轻量级的架构管理和控制工具。
这个工具的逻辑示意图清晰地展示了从业务实例或产品的设计到系统支持的整个过程。在这个过程中，模板、构件、服务以及参数等要素相互关联、相互作用，共同构成了企业级业务系统的核心架构。
虽然信息采集会带来一定的工作量，但对于大型企业的项目管理来说，所积累的项目信息库价值连城。现实中，许多企业即便完成了众多大型项目，却难以积累起足够的管理信息来支持项目的快速决策。
企业往往只知道项目总花费，却不清楚具体开支去向，更无法精确掌握系统核心部分的成本。因此，当系统需要更新、添加新功能时，预算制定往往依赖于粗略的“拍脑袋”算法。
若信息采集过程可靠，所建立的平台将能有力支持快速架构设计，并将项目成本细化至服务层面，甚至可用于评估团队的开发效率。因此，设计一套有效的项目信息收集与分析逻辑至关重要，否则项目开发将难以实现“精益”目标。
通过工具化上述逻辑，我们可以基于构件模型构建一个信息量丰富的轻量级架构工具，该工具贯通业务至底层实现。
与基于角色和职责的业务模型不同，构件模型以系统结构和关系为基础，通过顺序流将构件串联起来，形成完整的业务处理过程。这样，新需求可以快速定位到系统的修改位置；若需新增构件，也能迅速确定其位置并分析与其他构件的关系。重要的是，这些工作都可以由产品经理和业务人员轻松完成，从而加快他们与技术人员的沟通速度。
对于原有功能的改造需求，业务人员可以在产品销售或服务提供过程中产生新需求时，通过产品与模板的对应关系迅速找到实现产品的构件模型。然后与技术人员共同基于构件模型分析产品需求的实现位置，快速定位到需要改造或新增的服务及数据。
对于新增功能需求，虽然可能涉及全新的业务环节或产品（这种情况相对较少），但基于原有的业务环节和构件模型，我们可以迅速确定新增环节与原有环节的关系，并设计前后构件间的数据关系和接口。
在这种分析模式下，业务用户可以更加专业和高效地参与到业务或产品设计过程中来，将更精准的需求传递到开发环节，从而提升开发效率。如果企业原先的开发模式中业务人员需要提供详尽的业务需求文档，那么在这种方式下他们的工作量将大大减少；如果企业原先的开发模式中经常出现模糊的“一句话”需求，那么在这种方式下这些需求将变得更加明确和具体。
要使企业级业务架构的设计成果具有生命力并持续发挥作用，关键在于经常使用它。这一点对于任何架构设计模式来说都是至关重要的。使用该工具管理新需求的目的就是将业务架构变成连接业务与技术的“通用语言”，使用越频繁沟通越容易也越能被各方接受并用于实际沟通中形成一个正向循环。
因此，一旦选择了走企业级业务架构这条路，就请务必学习《西游记》中孙悟空跟随唐僧西天取经的坚定信念与执着精神：“历经九九八十一难，方得正果。”
了解更多数据分析知识、与更多优秀的人一起进群交流请扫码
群码过期或者群满请添加客服微信 CDAshujufenxi 后拉您进群
