当许多技术学生看到商业体系结构的概念时，他们会感到熟悉和不熟悉。如果将业务结构分为两个，首先要看体系结构，大多数人可以想到技术架构，系统架构，分布式体系结构等。这些概念对技术同学并不陌生，甚至有点亲密关系。但是，如果您的眼睛向前迈进并跌倒，可能会有一种陌生感。尽管许多人正在编写业务代码，但尽管许多人正在解决产品的业务需求，但是当面对哪种业务结构时，就没有感觉到的感觉，并且对其含义和角色有很多疑问。这篇文章将使用实际Qunar活动能力层的案例介绍业务体系结构并揭示业务体系结构对技术同学的重要性。同时，该案例本身也是业务架构设计中每个人的目标。
商业体系结构概念（BA）的建议是，togaf（开放式BROUP ARCHTECHER框架）方法将公司结构（EA）描述为企业架构的一部分。BELOW公司架构（EA）由四个部分组成：
我们技术同学的主要工作集中在应用程序架构和技术体系结构中，因此，当提到体系结构时，每个人都会首次考虑应用程序体系结构和技术体系结构的相关内容，这将形成一个思维集合它可以通过合理的拆分应用程序，改进技术解决方案并保持技术高级性质以促进业务改进来优化调用链接。但是，实际结果真的可以像人一样吗？
作为一家互联网OTA公司，Qunar在获取新客户，营销，维护活动和转化率方面有强大的需求。有了这些需求，同时出现了各种活动。就设计，互动体验，奖励的丰富性和吸引力而言，还必须在同一时间上进行精心设计。
以门票盲盒为例，总体交互效果和过程如下所示
请参阅上图，活动的详细游戏如下：
如果我们抽象，则可以如下图所示，这种类型的帮助共享破裂的变体的活动过程如下所示：
对于上述业务需求和功能，实际体系结构设计如下：
该体系结构设计的优点如下：
从上述架构的引入，可以看出，在已知的活动游戏和过程的前提下，技术团队在建筑设计，分层建筑风格，外墙模式，中国台湾化设计思想上花费了很多思考，热头发配置配置从技术工作的角度来看，技术团队实现了出色的设计和交付。自然，该技术解决方案还希望该技术解决方案能够很好地支持活动业务的运营和开发，并帮助活动业务实现目标。
但是，就像本文开头提出的疑问一样，上述技术解决方案设计能否真正实现帮助活动业务的目标？我们可以看到该技术解决方案启动后活动业务所面临的问题和痛苦点。
上面的三个典型疼痛点对活动业务产生了巨大影响，具体的表现是：
这些疼痛点和影响不仅影响相关活动业务，而且还困扰着该活动的技术团队。为什么我们的建筑设计看起来很合理？每个部分都可以在技术层面上取出。为什么事件业务的支持仍然不符合活动业务的最佳目标。作为技术团队，我们的下一步应该去哪里，我们从哪里开始更改现状？
首先，我们分析了一波疼痛点，一一分析问题，找到背后的原因，并考虑获得建筑灵感，将问题变成改进的机会。这是我们的持续思考。
首先看疼痛点1-活动业务的技术解决方案非常高，与此同时，新活动的技术时间非常高
为了找到高度变化率技术解决方案的原因，我们需要研究库纳产品对技术解决方案的需求的研究和开发过程。
产品计划的来源是通过分析拆卸业务需求来实现业务目的所描述的预期产品解决方案来描述产品经理。内容通常包括该产品需求的背景，目标，业务流程和相关数据要求。在分析了技术解决方案的案例变化之后，我们发现更改的案例通常是技术解决方案的描述与产品的业务需求与业务流程之间的差异。决议的矛盾已经阻止，并且他们必须从业务需求，设计技术解决方案的角度重新开始，并调整中央和台湾能力的期望。
接下来，分析疼痛点的另一部分，新活动的成本很高。
对于新事件，主要角色和过程中需要完成的事情可以参考以下图
从上图可以看出，在线活动的业务过程中有四个链接。每个链接都需要相关的角色来完成相关工作。因此，该线上事件的总成本是四环部分的成本的总和，但是在这种情况下，但通常会启动实际新活动的费用。技术开发和在线运营的成本是最大的比例。上面已经分析了技术变更的原因，但是对于那些没有改变的新活动开发案例，工作时间将满足期望吗？当然，这不是。技术开发基于事件时制定计划和制定的能力。因此，台湾功能的设计是否符合新活动的在线流程和产品的设计思想，这将对技术解决方案和发展效率产生极大的极大。发射的业务过程应如下
上述过程的改进点是，基于原始的红色输入过程，添加了新的绿色路径。此路径代表了另一个与业务期望更一致的过程。在产品生成活动之后，通过活动，通过活动，通过事件，通过事件，通过事件，通过事件，通过事件进行活动，活动在活动中。台湾提供的配置功能可完成活动设计，然后直接进入操作配置阶段。同时，当活动中舞台提供的活动配置能力（例如活动市场）不足以支持该活动的需求时，有必要开发干预措施。技术解决方案不仅是针对的在此事件的设计中，但是从改善事件的能力构建的角度，以利用本事件的需求作为提高活动能力的机会。
如果我们总结了疼痛点一的分析结果，则可以完善发生的原因如下：
如果我们以分析的理由为改善这段时间的机会，那么我们可以按以下方式激发我们的灵感：
根据上面的疼痛点1的思想和过程，我们编制了疼痛点2和疼痛点3的分析结果，如下所示。
在这一点上，现在是时候导致企业体系结构中业务结构设计的价值了。我们上面的工作实际上是在原始体系结构方案中企业体系结构中缺乏业务体系结构。
如上图所示，在企业的策略和视角下，技术团队可用的IT解决方案和基础架构之间，存在差距。制定着陆解决方案更好地帮助业务目标和期望。公司结构以及业务分析和业务架构设计是降落公司结构的主要任务。
回顾以前的技术解决方案设计和遇到的痛点，这实际上是因为尚未解决业务结构的空缺问题。无论在基础IT架构和优化方面有多么艰苦的工作，业务目标的帮助仍然有限。仅当您意识到按照某种方法填写业务结构空缺和业务架构设计的含义时，解决问题的正确道路吗？
那么，如何设计架构设计？接下来介绍活动能力层的设计过程。您可以将参考用于业务体系结构的设计过程。
1.阐明活动业务的业务目标和业务逻辑，其明确的业务目标和业务逻辑如下所示
下面的说明，活动业务基于用户的社交链接。通过为用户提供有趣的游戏玩法，基于用户对损失的厌恶的心理，它为用户提供了其他权利和兴趣，以吸引用户，改善转型业务。它的基本业务逻辑就是重新介绍新用户，睡眠睡眠通过活动，用户和低活动的用户访问了Qunar用户池，并刺激用户的浏览行为，在用户池中共享行为和消费行为，以实现业务增长的目的。
2.整理业务流程和利益相关者。我们已经重新分析了活动业务的产品研发和运营过程，并确定了活动的业务过程和活动的生命周期。
一个事件是根据业务目标和可行性评估在评估阶段出生的。通过基于现有的活动业务模板和该事件的需求的事件的产品设计，该活动的设计完成了。活性，进入活动研发阶段时，只需要参与产品即可。如果当前的活动模板无法支持此活动，将有产品和开发共同进入事件开发阶段。具有能力的新模板组件。活动完成后，进入操作 - 统一事件操作的操作，此阶段操作遵循在线活动的操作，并根据业务目标随时在线调整活动状态，并需要随时在线调整。事件窗口结束后，归档了活动数据，并根据需要评估活动的效果并输入下一个周期。
在上面的业务过程中，自然而然地确定了各种利益的相关方和关注。
对于参与活动业务流程的不同利益相关者，他们的注意点是不同的，当我们进行业务结构时，我们需要确定这些利益相关者及其最关注的核心问题。会议并为下游提供了投入材料建筑设计着陆解决方案。
3.基于上述业务流程以及利益相关者的注意力的业务能力识别，我们可以针对每种业务需求分类业务需求和设计相应的业务能力。此阶段的输出如下：
需求分类是指导我们组织组织结构和边界部门的规则之一。通过不同类型的需求，重要性程度以及与战略目标的相关程度的优先级，我们可以在有针对性的方面制定资源投资计划，目的是将最强大的战斗资源投资到最有价值的事情上。在同一时间，您可以确定可以使用哪些需求来使用现有方案或现有系统支持，以避免重复开发并导致资源浪费。
4.在制定了确定着陆计划的业务能力之后，我们可以根据现有团队的知识，方法，技术资源，人力资源，可用基础架构和其他因素来设计相应的功能。
在满足了与各种业务能力相对应的实施计划之后，技术同学可以输入开头提到的熟悉链接，进行应用程序架构设计，选择技术解决方案，确定架构样式，选择适当的编码样式和代码coderegulation，组织组织特定的技术学生进入编码开发。
为了回应这一部分，当我们想完成某个业务的业务结构时，我们可以参考以下步骤：
以上是我们在活动业务架构设计中使用的步骤。如果您对官方标准过程感兴趣，则可以看到togaf ADM文档规范以了解更完整的过程。但是，与任何其他体系结构一样，从标准化到特定的实现，不可能避免基于本地化适应团队的当前状态和业务状况。每个人都必须知道这一点。
这是设计活动能力的设计过程的一个例子。已经确定了缺乏业务体系结构的过程以及如何设计业务体系结构。摘要部分，让我们看一下业务架构及相关应用程序架构，技术体系结构，数据架构概念以及在战略着陆中的职位以及职能。
上图清楚地阐明了业务结构的重要位置和核心作用。在同一时间，业务结构的五个要素还显示了业务结构：组织结构，业务能力，业务模型，业务流程，业务数据。可以查看活动的业务架构设计过程的一部分，并查看我们在着陆过程中围绕五个要素所做的事情。
同时，随着业务的发展和战略目标的变化，业务结构还需要不断改进。在TOGAF中，给出了架构开发方法（ADM），并给出了完整的体系结构开发周期过程。在这里，它也将提供给所有人的遗传。
（Togaf?系列指南的上图引号使用Togaf?框架来定义和管理面向服务的体系结构）
在这里，我们应该特别注意中间业务需求中的核心节点。我们的体系结构的开发必须始终满足业务需求的要求。同时，当业务需求更改时，无论我们的体系结构工作在周期中是否链接，我们都应重新检查是否应重新设计和改进，并在上一个链接中进行改进。
本文引用了很多与TOGAF相关的信息，我还建议所有人在官方网站上学习官方文件。如果您有在团队中降落业务结构的想法，我希望本文中介绍的案例可以带给您参考。
原始：https：//juejin.cn/post/7094933755197915167