🧚🏿 ➰ 🤱🏿 系统架构和业务架构 💇🏻 🙌 🧑🏾‍🤝‍🧑🏻

在对各种专家如何解释（建立）对体系结构的理解进行了足够长的思考之后，我决定他们仍然需要帮助：）我

没有批评，但是我有一些提供。

建筑和建筑结构

考虑一下建筑领域中建筑和建筑师的原始概念：

建筑是设计和建造建筑物，结构及其复合体的艺术，也就是说，是创建物质组织的环境的艺术。

建筑师是一名专家，他在专业的基础上进行建筑设计，包括建筑物设计，包括空间规划和室内解决方案的开发。

建设项目包括两个主要部分：建筑，建筑和工程。

该项目的建筑和施工部分包括：

建筑部分由建筑图和施工图组成，这些图指示建筑物，其结构及其元素的确切几何参数：平面图，地板，屋顶计划，立面，剖面，可视化。
设计部分包含常规数据，基础，地板，屋顶的设计解决方案，单个组件和零件的图纸，产品和材料的规格：基础，天花板，门，屋顶，结构组件和详细信息。

该项目的工程部分由详细图表组成：

给水和污水处理系统-供水接线图，轴测供水图，污水处理接线图。
加热和通风-加热接线图，通风接线图，锅炉管道（如果有）。
电源-照明布线，电网布线，ASU电路，接地系统。

建筑师仅处理建筑部分，而结构和工程部分则由相应的工程师处理。

...一个思考的地方...

对于“处于困境中”并喜欢与架构师进行比较的IT架构师：

, . , , , .

系统架构

现在，让我们看一个更接近IT的定义。我将以本文摘录为基础。

体系结构-系统在其环境中的基本概念或属性，体现在其元素，关系以及设计和演化原理中。（摘自：ISO / IEC / IEEE 42010：2011）

此类定义和类似定义通常用于大型架构框架（如TOGAF和SAFe）。这些框架非常繁重，由少量实践组成，这些实践被系统化并通过许多不同的技术加以稀释。尽管没有人测试过并且没有以整体形式应用它们，但是所有这些都被称为“最佳实践”。

– , . ( )

但是，具有“难以更改”特征的微妙之处。

假设您有一个设计解决方案，向开发人员介绍他们应该如何构建Java代码。如果您有很多代码，那么将所有代码从一种结构更改为另一种结构将需要大量工作。换句话说，这很难。因此，此选择的解决方案是“体系结构”，在这种情况下为软件体系结构。但是，一个开发人员可以轻松地忽略此决定，而编写功能不同的代码。毕竟，对软件进行“更改”很容易。尽管很难更改整个实现的体系结构，但仅更改其中的某些部分通常很容易。

从理论上讲，相对于软件而言，很难更改某些东西。如果选择软件的某一方面，则可以轻松对其进行更改，但是我们不知道如何使所有内容易于更改。使某些内容易于更改会使整个系统更加困难，而使其易于更改则会使整个系统非常复杂。（拉尔夫·约翰逊）

可以说，这揭示了根据ISO定义的“体系结构”中“基本”一词的含义，这是很难更改的。

体系结构的本质是结构化。结构化可能意味着将形式转化为功能，摆脱混乱，或将客户的部分形成的想法转变为可行的概念模型（Eberhard Rechtin）。

建立体系结构是根据其组成元素来组织和维护系统的活动。并且所有架构原则都针对系统组成部分的分解和组织。

问题

上面定义的问题尽管有用，但仍然存在，但与系统中嵌入的思想背道而驰。根据“难以改变”的标准来区分架构是很奇怪的。

同样，在这种情况下，通过组件进行的定义未传达必要的含义。

...一个思考的地方...

大多数系统架构师来自程序员，他们都是技术专家。他们想到了这一切。 :)

使用体系结构时，最好专注于系统的目的。

体系结构是一种设计解决方案，可以将一组设计解决方案组织到与预期目的相对应的系统中。

这是一个将汽车的车轮，发动机，车身和转向系统组织起来的设计解决方案。

换一种说法，架构是一种产生紧急效果的设计解决方案。出现-一个属性系统的外观，该属性系统不是其元素固有的；系统的属性对组件的属性之和的不可约性。

重要的是不要混淆抽象级别。再后来，可能会出现一个问题，什么是好的架构？该架构应确保实施系统质量的三个主要属性：可靠性，效率，灵活性。还有其他一些功能，例如可伸缩性，可测试性，可维护性等，但是它们并不总是那么重要。

业务架构

业务体系结构有其自身的特点。首先，有一个工作架构需要理解和描述。其次，您需要了解自己的业务原理和基本概念。只有了解业务和基本概念，您才能提出更改建议。

与其他任何架构一样，使用三个方面来描述业务架构的基础：

主题是组织人员结构。
活动是业务流程，功能和服务。
对象是活动的结果和活动的材料。在这种情况下，结果和材料可以是物理的或信息性的。

但是，这还不足以理解这一点，您需要考虑基本概念和原理。

“三种活动”的概念

活动分为三种：

管理器-控制系统功能的活动。治理流程的一个例子是公司治理和战略管理。
主要（运营） -作为公司业务基础并创造主要收入来源的活动。运营，采购，制造，市场营销，销售等业务流程的示例。
支持性的-为主要业务服务的活动。例如，会计，招聘，技术支持，行政部门。

支持活动通常是外包的。上面示例中“作为主要”指示的活动并不总是主要活动，因为它们也可以外包。总会有一项管理活动，从理论上讲，所有内容都可以“外包”，除了管理之外，还可以使公司虚拟化。

外包管理：

? outsource. :)

戴明循环概念

因此，作为建筑师，我们将公司的活动分为三个部分。现在，您需要了解它们如何协同工作。为此，我们需要另一个古老但仍然相关的概念-戴明循环，又称PDCA：

规划

法案

检查一下

调整

您无需从字面上看，它只是一个隐喻，在不同的公司中，它的实现方式不同，但是这些阶段始终存在。

让我们看看我们的特定设计工作，产品制造或服务提供：

谁计划了这个过程？
有哪些监管文件？
谁做的动作？
验证如何完成？
调整如何进行？

如果在“操作”和“检查”阶段一切似乎都清楚了，那么“计划”和“调整”就需要更近一些。

决策概念

在这里，我们需要第三个概念-决策。这是解决管理问题和项目管理的通用方法。

了解任务

评估情况

开发解决方案

选择解决方案

重要的是要了解此序列中的所有步骤以及完成该过程所需的步骤。此方法适用于计划，并根据情况进行调整。

让我们将此概念映射到我们的设计中：

如何完成任务澄清？
情况如何评估？
...

现在，让我们提升领导能力。

领导如何在调整和评估情况方面获得信息，也就是说，关于我们项目的报告在哪里，以便他们了解好或坏的一切？

原则“目的必须决定架构”

在此提醒架构的定义很重要：

架构是一种设计解决方案，可以将一组设计解决方案组织到与预期目的相对应的System中。

最终用途通常是主要活动。管理活动集中在主要活动上。支持活动可以提供支持。

同样，不要忘记质量的上述属性：可靠性，效率和灵活性。主要活动是个人的事情，但是我认为，您可以自己处理。

原则“建筑必须遵守准则”

没有利益相关者的支持，该架构将无法实现。我们将必须研究所有利益相关者，他们的动机和目标。

内部冲突是可能的。

...一个思考的地方...

定义业务架构

至于专业定义，我认为鉴于业务和IT并肩发展的事实，最好将业务体系结构看作是企业体系结构抽象顶层的一组解决方案。

在现有的定义中，我喜欢建筑委员会特别兴趣小组（BASIG）（OMG建筑委员会）给出的定义。

A Blueprint Of The Enterprise That Provides A Common Understanding Of The Organization And Is Used To Align Strategic Objectives And Tactical Demands.

, .

如果我们给出架构的一般概念，那么架构师的角色将变得非常清晰。

鞋匠的工作是制造和修理鞋子。

架构师的工作是创建和管理架构。他必须创建一个解决方案，将所有其他解决方案收集到系统中。

他应该具备什么能力？

架构师必须在其业务或系统级别了解架构原理和概念，这是他的技能。

同样，架构师应该是驱动程序，描述架构是成功的一半，但是说服人们实施并不断提供支持是第二项任务，这同样重要。

为此，架构师必须具有训练有素的软技能。...

架构师与分析师和程序员之间的另一个区别是，他必须精通操作技巧。

...一个思考的地方...

系统架构和业务架构