1.业务架构（有时也叫功能架构）
首先我们来讲讲业务架构
业务架构大家经常听到，如果问度娘会出现很多业务架构图，教大家如何来画图，但对业务架构的来龙去脉讲的很少，反而看了之后还是很难和应用架构甚至产品需求分析区分开。在计算机专业课程中对业务架构讲的非常少，或者说没有涉及到这方面的知识。但业务架构这个词并不新，从提出到今天已经有20多年了。但是在开发人员中，业务架构显然没有需求分析的概念明确，业务架构师也远不如产品经理常见。
1995年著名的TOGAF提出了业务架构的概念，TOGAF 将企业定义为有着共同目标集合的组织的聚集。例如，企业可能是政府部门、一个完整的公司、公司部门、单个处 / 科室，或通过共同拥有权连接在一起的地理上疏远的组织链。TOGAF 进一步认为企业架构分为两大部分：业务架构和 IT 架构，大部分企业架构方法都是从 IT 架构发展而来的。业务架构是把企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，它包括业务的运营模式、流程体系、组织结构、地域分布等内容。TOGAF 还提供了一个详细的架构工具模型：
从上面模型中可以看到，业务架构的输出物有：组织、目标、角色、业务功能、业务流程、业务功能分解等等。业务架构不仅仅是一张业务架构图，而是由一系列的输出物构成。
日常工作中经常会在一张图上面表达业务架构，包括组织角色、业务模块，架构图示例：
应用架构、数据架构、技术架构都是基于业务架构而产生出来的一系列工作，都是为业务架构服务的。应用架构是描述了IT系统功能和技术实现的内容。在TOGAF中，应用架构的输出有：应用功能、功能组合、接口描述、系统集成关系等等，应用架构是个系统工作，也是基于业务需求、业务架构逐层进行分析，最终获得的一个完整方案。应用架构设计完成后，我们能够清楚的知道需求对应的有几个系统，每个系统有哪些功能，系统之间的关系，接口有哪些，业务流程是什么样子，系统的用户有哪些等等。为了直观一点，我们拿应用架构工作中其中一个应用架构图来看看：
某购物车系统应用架构图示例
应用架构设计文档基本包括：系统定位、应用架构图、场景验证、业务流程、接口描述、系统集成关系、实施路线。
功能架构主要包括功能、角色和权限三部分。功能是企业服务，用户使用的每一个功能，就是企业的每一个服务。角色是用户操作的归类，功能与角色的对应关系即权限。了解系统架构的现状，从功能架构开始。
业务架构图可以按多系统业务架构图和单系统业务架构图进行说明。
多系统业务架构图
来源于《深度｜从一个故事说起，谈谈企业应用架构的演变史》，作者杨堃，侵删)
由上图可见，业务架构图是从业务逻辑的视角出发，为产品经理整齐地展现出一个企业各类系统之间的层次和关系。在产品大神杨堃的《深度｜从一个故事说起，谈谈企业应用架构的演变史》一文中，形象地为我们描述了业务架构图从无到有的过程，非常值得各位产品人学习的。下面就根据大神的经验说一下自己对业务架构图的理解。
业务架构图按照层次结构可以分为经典的三层结构：展现层、业务逻辑层和数据层，而上图作者在该基础上又分别对展现层和业务逻辑层做了细分。在上图的基础上其实还可以加上一层运维层来说明系统所需要的硬件条件。对于单个系统的架构图而言尤其重要。
| 一级层次 | 二级层次 | 说明 |
|---|---|---|
| 展现层 | 前端 | 面对外部客户的客户端、Web官网、公众号、小程序等 |
| 后台 | 面对内部人员的后台系统 | |
| 业务逻辑层 | 业务单元支持系统 | 主要指可以在同一企业的不同子系统中复用的支持同类业务的单元系统 |
| 职能单元支持系统 | 主要指企业职能部门使用到的OA、邮箱等系统。一般中小企业这块都是相对比较独立的。比较难嵌合进其他业务系统体系中。 | |
| 基础架构支持系统 | 基础业务逻辑，包括账号体系、鉴权授权体系、定位、短信、支付等等 | |
| 数据层 | 数据仓库 | 负责打通各系统之后的全部数据存储和处理 |
| 运维层 | 运维层 | 主要指企业各系统的硬件环境 |
使用多系统应用架构图还有一个好处在于，每当有新增的子系统时，可以提前预判是否需要共用哪些单元或者业务逻辑。例如是否用同一套账户体系，这对产品前期开发至关重要。
单系统业务架构图
对于一个从0到1的项目而言，产品经理除了要了解这个项目在整个企业应用架构中的定位，还要对整个系统的模块和功能有着清晰的分层次设计和了解。所以产品经理就不仅需要多系统业务架构图，也需要单系统业务架构图。
单系统应用架构图
由上图可以看出，单系统应用架构图分层可以和多系统应用架构图一致。但是每个层次里面的说明单元就变成功能模块，而非子系统。
应用架构图看起来和具体功能设计没太大关系，但心中存在这一张图时，可以从整个大局去设计系统，做好提前布局，避免后期出现巨坑。
定义业务战略、治理、组织和关键业务流程。
业务架构-数智豫电-2022年概设
本平台业务架构主要由成果应用、报表分析和数据管理等业务内容组成。如下图所示
业务架构
——摘自《自主变革的基石 制造企业管理技术及SOA实践》
主要考虑部署，例如你不同的应用如何分别部署，如何支持灵活扩展、大并发量、安全性等，需要画出物理网络部署图。按照应用进行划分的话，还需要考虑是否支持分布式SOA。
每一个典型业务，都可以把它想象为一台运行中的机器，而其中的每个业务组件便是构成这台机器的功能模块。之所以要利用组件来进行业务架构的搭建，正是因为组件具有上述特性，这些特性能确保搭建的典型业务架构图，既完整有效、又无功能冗余，而且有利于今后展开系统架构的组件分析和设计。这样的架构能告诉我们：是由哪些内容相对独立的业务模块构成了这项典型业务。如对其中的每一个业务组件之间的作业关联关系、相互沟通的方式进行研究，就能掌握整个业务架构的协同作业水平；如果对每一个业务组件都采用前述外特性定义的方法加以描述，就能掌握这些组件当前能完成哪些独立的业务内容以及能达成哪些业务目标。本节重点介绍利用业务架构图分析典型业务的分析方法，分析的对象就是业务架构在功能构成方面的完整性和合理性。
首先，需要表达出当前的典型业务是由哪些业务组件构成的。基本可以断言，大家在开始按上述三个层次描述某个典型业务的构成时，一定会对应该如何定义管理层和决策层的业务组件感到困惑，这是非常自然的反应。因为，至今以来，大家总是在研究执行层的作业方式，不会去、也不敢去研究管理层和决策层的作业能力。但在不远的将来，我们的企业注定要进入业务协同和系统整合的时代，所以，大家现在应该开始学习如何定义和建立管理层和决策层业务组件的具体方法了。
典型的整车生产企业产品开发业务的业务架构示意图
如典型的整车生产企业产品开发业务的业务架构示意图所示：当我们对于某项典型业务的业务组件的构成进行初步的归纳后，能够得到该项业务的一个整体的框架结构，我们可以称之为“业务架构图”，以及在这个框架内，企业中三个层级的员工在该项业务上分别从事着哪些作业内容。分析执行层的业务作业方式和作业规律，你觉得很正常，但如果让你去分析作为你上司的管理层、甚至决策层的作业方式和作业规律时，你也许会感到有所不安。这种心理反应，实际上正好反映出目前很多企业中的一种能力倒置现象的产生原因。很多人都了解这样的事实，那就是，企业中的很多升职后的中高层领导，在就位后的很长时间内，不能进入应有的管理角色中，这绝对不只是个人能力的差异问题，而主要是因为我们的中高层领导总是习惯地认为：研究执行层的作业方式和规律才是他们的主要职责，而没有注意到自己的作业内容和作业方式在整个作业链条中的重要作用，其结果，自然是管理层和决策层领导们的业绩，只好取决于执行层作业人员的努力程度，这种习惯也导致我们的中高层领导们不会去研究影响自己判断能力和决策能力的技术瓶颈是什么。而很多新出现的现代管理模式，实际上就是为了解决中高层领导们的作业能力问题，或是为了解决三个业务层级之间的信息沟通能力的问题，这也就是为什么业务架构分析人员还必须分析战略层和管理层作业形态的原因。下面将分别说明上述三个不同层次作业组件的特点：
（1）战略层业务组件
战略层业务组件自然是用于定义和规范战略层决策人员的业务行为的。那么，哪些人员可以归类于战略决策层之中呢？一般说来，在典型的制造企业中，部长以上的领导应被理解为企业战略决策人员，因为，他们通常已脱离具体的、单一的业务管理，他们通常会被要求在某个综合业务的专业领域提出战略性规划，并按规划进行部署和指挥。但在很多企业中，还设置有经营管理课或战略策划部等机构，其中的一些专门从事为决策层领导进行战略数据分析和提出具体方案的高级管理人员，也应该被认为是战略层业务组件中的业务人员。
战略层业务组件通常应按如下的作业基准进行设计：
- 对于特定的典型业务，是否具备有效的战略规划编制和调控能力。
这里提到的调控能力，是指当企业经营发生重大的内部或外部环境变化时，企业内部是否具备能对既定规划及经营目标做出及时分析和调整的响应机制和具体的作业标准。
- 制定、发布以及变更经营战略规划的流程和作业规则是否明确。
这只是一个规范作业流程的问题，在很多企业内部，通常具有手工审批，进行传递的流程，有时存在指令重复、重要度不明、不易追溯等管理问题。
- 是否能及时、准确地获取相关战略指标的动态统计数据（用于决策）。
这是直接影响战略层决策能力的重要条件。这里提到的及时和准确，往往可以作为衡量一个企业管理技术水平的标尺。
- 战略指标数据是否能明确指向具体部门或具体业务组件（用于能力评价）。
这同样是一项检验企业管理技术水准的重要课题，在此后的第七和第八章中，将对此课题展开详细的讨论。
- 是否具有根据设置的危机监控标准，及时触发决策机制的系统反应能力（确保决策的及时性）。
这是一个技术含量最高的课题，任何企业都很难达到这样的水准，只有在管理方法和技术手段方面同时达到很高水准的企业，才能有效展开这一类课题的研究活动。但这一课题显然是所有企业都需要瞄准的目标。
当然，上述的作业基准未必一定完整和精准，只是按照对一般指挥机构职能的理解来考虑的。例如，企业每年需要设置生产成本控制的战略目标，如经营层的业务人员（实际上是一些领导们）能按图2的成本控制图谱获取所有部门和所有组件的目标达成数据的话，自然就能及时做出相应的评价、指导和决策调整。关于如何实时采集和展现业务状态数据、以及如何设计战略决策信息舱的详细情况，请参见第八章《商业智能和可视化管理》的内容。
单车成本构成示意图
（2）管理层业务组件
由于管理层处于决策层和执行层之间，从信息沟通的角度来说，具有上情下达、下情上报的职责，一般情况下，上情下达比较容易实现，但下情上达则相对困难，存在诸多的管理和技术问题。管理层业务组件应以提升管理层控制业务过程的能力、以及提高管理层和执行层及战略层之间的信息沟通能力为主线进行设计。管理层作业的重点应按如下思路设置：
- 对于某个典型业务的企业战略，是否具有明确的计划编制、监督实施等作业标准。
如部门接受了达成企业某个战略，或实现某个企业年度指标的任务时，应该按照既定的作业标准，进行自身业务能力的分析、指标的分解、作业分工以及过程控制方法的确定等作业，以确保该项战略目标或年度绩效指标能按计划展开，并确保其实施过程能得到有效的监控。
- 相关的典型业务的过程状态是否能有效掌控。
这一条可以认为是管理层的主要业务方向之一，如一个中层管理人员对如何监控业务过程缺乏最起码的研究，那就基本可以断言，他肯定是一个缺乏最起码业务过程控制能力的管理人员。
- 对于某些典型业务或某些关键的作业节点，能否实时、有效地评价员工的执行力。
管理人员之所以需要掌握员工或团队的执行力，不仅仅有利于达成业务目标的正确预测，更重要的是将有利于管理人员发现团队中意愿不足和能力不足的员工，以便及时加以指导。另外，如能实现员工执行力的数据统计，还将有利于事后的正确评价。
- 对于部门重点业务以及管理改进目标，能否掌握员工知识贡献度的不同。
能设置符合这一方向的业务组件，其先决条件是必须已经实现了基本有效的知识管理，否则，这样的要求就偏高了一点。作为一个以创新为主的业务部门的管理人员，必须研究如何做才能达成这样的目的，关于这一点，将在第八章中进行详细的介绍。
- 对于所承担的企业战略指标部分，是否具有实时采集、分析和上报的机制。
如果管理层职员基本具备这样的意识，就基本上能够得到他们上司的认可，至少能够保持住当前的官帽。如果能够建立这样的机制，具备这样的能力，那就完全不用担心自己的升迁问题了，因为，能够实现及时、准确地“下情上报”的管理人员，已经充分具备了能随时取悦上司的资本。
总之，从信息沟通的功能来说，设置中层管理业务组件的目的，一是能够掌握企业战略动态，及时编制、和实施部门业务计划；二是要能够实时掌握执行层业务的作业状态（进度、执行力、作业量、知识贡献等）、并能够及时处理、分析执行层的业务统计数据，以便及时对员工进行指导、督促和评价，以及顺利履行按规定向上通报的职责。根据以上思路设置管理层业务组件，从表面来看，似乎主要关注的是中层管理者们处理信息的能力，但大家必须清醒地认识到这样一个事实，那就是：没有充分有效的反映执行层作业状态的信息，管理层就不可能进行有效的控制、指导和评价，作为管理者的能力，也就不可能得到充分地展现。
（3）执行层业务组件
执行层业务组件的设计重点，当然首先要关注组件的设置是否有利于实现所属典型业务的目标，其次是希望它能以最少的资源投入来确保业务目标的实现。如果企业单一系统的建设卓有成效，则基本可以认为该企业的执行层业务组件应该是处于一种良好的状态。但在当前加强目标管理、绩效管理的企业，所有执行层组件应该还要考虑是否需要设置向管理层提供信息服务的功能。归纳起来，应考虑以下要素：<br />- 是否能确保实现典型业务的业务目标。<br />要回答上述问题，必须对典型业务有完整的认识，所以，必须尽量把有利于实现业务目标的业务活动、操作方法以及技术手段都纳入研讨的范围。也许，在考虑如何才能实现典型业务的业务目标时，暂时可以不要过多地去推敲效率的好坏。<br />- 实现业务目标的效率如何。<br />如果企业对于作业效率有很高的要求，则在设计业务组件时，或许要更多地考虑组件的合并、组件业务流程的连通方式的改进、执行力的监控等有利于提高作业效率的问题。<br />- 业务过程失控的危险是否已完全消除。<br />企业中的有些业务，如必须需要通过设置控制基准值，并通过逻辑条件或数学运算规则来发现业务过程失控、指标达成失败等现象时、则需要考虑追加自动监控组件，如果没有自动监控的条件，也应明确人工监控的具体方法。<br />- 业务状态数据是否可实时采集、统计和发布。<br />对于必须控制进程的业务，则通常需要考虑追加进度监控组件，至少应明确关键节点的进度监控方法。<br />- 业务组件之间的协同是否顺畅。<br /> 这一条要求是指业务组件之间的流程连通方式、信息共享方式是否符合业务目标的要求，如果不能达到要求，则要追加某种提升协同能力的辅助组件。<br /> 总之，执行层业务组件是实现典型业务目标的骨干部分，而管理层业务组件的合理设置可确保执行层业务过程得到实时的控制，而战略层业务组件则应起到目标调整、资源调整的决策作用。<br />在进行上述三个层面的业务组件设置时，如果已经掌握了相对先进的、行业内的最佳实践模式，并对该典型业务进行过组件构成合理性的分析，或者根据日常的业务不良投诉记录，已经掌握了某些组件的问题，那么，在分析和描述该项典型业务时，可明确地表达出该典型业务在构成上的缺失或冗余项，以及当前这些业务组件的业务能力的总体状态。在分析中，最容易发现的是业务组件的缺失项，即一些目前我们还没有开展的业务，而这些业务的开展恰恰有利于企业最新战略的实现。但发现所谓冗余项，则通常是一个不容易完成的任务，因为，大多数员工不会斗胆挑战现有业务存在的合理性，因为大家已经习惯于把时间打发在这些日常业务上了。但作为业务分析人员，建议大家必须时常保持高度的怀疑态度，因为任何业务组件的存在都要消耗资源，为此，任何业务组件都存在压缩、分解乃至取消的可能，如果能通过业务的重组或优化，凸现出某些业务的冗余功能，并最终取消之。这才是分析人员应该加以重点研讨的方向，才是大家更值得骄傲的地方。真所谓“居人之所恶，故几于道”，我们业务分析人员，没有必要对自己始终保持对现实的批判态度而心怀歉疚，反倒应该随时提醒自己，要始终保持对现有业务合理性的怀疑态度，在这方面，做“恶人”比做“好人”，更能体现业务分析人员的职业价值。对于上述的分析结果，自然应在业务架构图中表达出来，具体的表达方式可参见图2-4。在图中，采用的是用色彩区分来表达组件业务能力状态的方法，虽然这种表达方法比较直观，但肯定不是唯一的表达方法，在此建议大家不必拘泥于形式，只要能容易理解即可。<br />**和最佳实践模式对标或完成调查和分析后的业务热点分析图**<br />不过，有一点，希望大家注意，上述的架构图是一张企业级的典型业务架构概略图，所以，对于每一个典型业务，都包含了所有相关部门的业务组件。但实际上，我们的很多具体分析，往往只须针对一个部门的业务展开即可。在这种情况下，也可以按照上述的方法编制部门级业务架构图，只是这种架构图在大多数情况下，不需要考虑战略层的组件设计，所以，只采用两层的架构图也是没有问题的。另外，根据需要，对于部门级的业务，还可以编制一种横向按时间顺序展开的架构图，但这种架构图不利于展开全局性的分析，所以，通常不采用，这里就不作详细说明了。<br /> 根据以上两个图例，读者是否不再介意使用‘业务架构’这样的表达方法了呢？为此可以认为，即使是相对抽象的业务也是可以用相对直观的架构形式来表达的。这样的表达方式不仅仅只是为了直观地进行业务的归纳，更重要的是为了直观地表达出现有业务架构的缺陷。图3中，红色的组件表示缺失、冗余或存在严重缺陷的组件，此类组件我们通常称之为“热点组件”（这样的架构图也可称之为热点组件示意图）。红色组件通常是表示尚未实施改进对策的热点组件。粉红色的组件则表示该组件虽有问题，但目前正在对策中。黄色的组件表示存在当前可以默许的缺陷，但随着企业的发展也许需要加以关注的组件，通常其评价的平均得分低于3分。绿色则表明该模块当前运行正常，暂时不需要特别关注的业务。当面对如此直观明了的业务架构图。没有理由不对缺失的和有缺陷的模块部分进行进一步的问题定位分析、并制定改进方案。但怎样才能知道A组件是缺失，应该考虑增设，或B组件有缺陷，需要改进呢？这便是后面的章节中将要重点介绍的核心内容。<br />**下面这张就是画的比较细的业务架构图**<br />
若有收获，就点个赞吧
0 人点赞
