沃尔沃：大型组织中的敏捷系统架构

系统架构被认为是大型复杂电气系统开发的基本要素。这是因为一个好的架构可以保证系统满足所有必需的质量要求，并且在未来升级后依然满足。除了设计良好的体系结构之外，当今此类系统的开发还需要敏捷方法，尤其是在软件开发。这主要是为了确保质量和更短的开发周期，尽早到达客户，并直接将他们的反馈整合到开发过程中。为了协调大型组织中许多敏捷团队的工作，通常有必要使用框架来扩展敏捷开发。

敏捷开发的主要原则包括：

1。专注于质量、快速发布和快速响应客户反馈的增量功能增长。

2. 没有重大的预先计划，在我们知道的尽可能多的时候，尽可能晚做决定。

3.对开发过程中变化有足够的准备。

4. 将系统划分为具有明确边界、职责和独立生命周期的子系统。

第四个原则实际上源于系统工程实践，但它考虑了其他原则的先决条件，因为它降低了复杂性。这些原则的主要思想是指导所谓的敏捷团队开发他们完全独立的一个系统功能(例如，规格说明、设计、实现和验证)。然而，每个原理也会影响系统的架构。

在可扩展敏捷框架(Scale Agile Framework，SAFe)中，架构师的角色是框架中所有级别的三个关键角色之一。架构师主要负责子系统中的主要组件，并平衡子系统中的功能性和非功能属性的开发。与整个系统相关的架构决策留给所有相关子系统的架构师通过直接讨论来解决。由于分区管理原则，这样可以确保子系统尽可能独立。

然而，在大型复杂的项目中，实际情况通常是不同的。首先，由于遗留系统、初始系统分区期间的时间压力、在开发期间由于将系统的功能方面优先于非功能方面而导致的子系统之间的依赖性增加，子系统之间的独立性远不如预期的那样。其次，团队之间缺乏沟通和透明度通常会导致本地化的决策，并不是所有相关的架构师都参与其中，从而使系统处于不一致的状态。

为了克服这些问题，我们需要一个专门的架构师团队(完整系统架构师团队——CSA)，他们具有系统的整体视角，并对其架构一致性负责。然而，这至少产生了以下新问题:

Q1。在不同的开发阶段，CSA如何与SAFe的系统/解决方案架构师协作?

Q2。职责——哪些架构决策应该在当地制定，哪些涉及CSA?

Q3。在SAFe中，如何合适的设立和组织CSA？

针对上述的问题，下面从系统体系架构的定义，并对SAFe进行说明，然后介绍沃尔沃汽车对上述三个问题的解决方案，最后聊聊这些方案的优缺点。

系统架构

IEEE将软件架构定义为一个系统的基本组织，它体现在其组件、组件之间的关系以及它们与环境的关系，以及指导其设计和发展的原则。

在本文中还考虑了软件和硬件的系统架构组件。我们还想用Jansen和Bosch的定义来补充IEEE定义，该定义强调了体系结构的系统质量方面：体系结构由一组确定系统质量特性的设计决策组成。

SAFe

完整的SAFe是为大型组织设计的，用于将敏捷原则扩展到多个部门(例如，研发、制造、人力资源和财务)，它定义了四个组织级别[4]:

1。团队级，所有软件和硬件的开发都在此进行。

2。程序级别定义敏捷发布组(ART)，负责系统中团队拥有的组件的持续集成/发布。

3.(大型)解决方案级别负责管理一个复杂产品的多个ARTs。

4. 组合级别为一个或多个大型解决方案定义策略和预算。

每个描述的级别都包含一个带有优先任务的待办事项，以及一组负责确保系统中新产品的连续不间断的角色。这些角色之一是架构师，它分别作为系统架构师/工程师和解决方案架构师/工程师出现在程序和解决方案级别上。这些角色负责所谓的“架构级别”的开发，以确保系统有必要的质量来支持未来的扩展，即减少架构的技术债务。

除了系统架构师和解决方案架构师的角色之外，企业架构师的角色也可以在投资组合级别上使用，并负责提供战略技术决策，包括与所包含的大型解决方案的架构相关的决策。企业架构师还不是沃尔沃汽车敏捷框架的一部分，但是将在后续简要回顾他们在确保整体系统架构方面的可能用途。

最后，需要强调的是，在某种程度上，系统架构的开发是上文所描述的“没有大的预先计划的敏捷原则”的例外。这是因为，在建立增量功能增长流之前，需要将系统的高级划分放在最重要的质量属性上。

沃尔沃的解决方案

在沃尔沃，如何开发和维护系统架构的基本原则是将责任和架构工作尽可能地分配给不同的ARTs部门，而不是将其全部开发放在一个中央组织单元中。这是为了在设置架构和完整系统的高层结构时利用整个组织的能力，这是为了在考虑完整系统的情况下进行局部决策的可能性。

SAFe描述了不同抽象级别上的架构角色，这些抽象级别可以很容易地解释为层次结构。沃尔沃汽车将重点放在具有不同专业知识和观点的不同架构角色之间的合作上，而不是聚焦于层次结构。架构决策应该在ARTs和架构师的工作组中进行，而不是集中在决策论坛中。

沃尔沃的三个主要架构角色是Volvo Cars定义的完整系统架构师(CSA)，以及SAFe定义的解决方案架构师(SoA)和系统架构师(SA)。下面针对之前提出的三个问题进行探讨。

Q1。在不同的开发阶段，CSA如何与SAFe的系统/解决方案架构师协作?

CSA和在SAF中定义的架构师角色之间的协作最好用两个场景来描述:本地化开发和临时集中开发。这两种场景都适用于所有开发阶段，即使在更改常常局限于特定领域的后期阶段，对CSAs和SoA的需求可能较少。

图1所示的本地化开发描述了这样一种情况，即大部分架构工作都局限在一个解决方案或特定的ARTs。

图1 CSAs、SoA、SA之间的协作

在这种情况下，CSAs将加入SoA/SA的本地开发的架构团队，以支持正在进行的开发中的完整系统视图。CSAs负责处理对其他解决方案和ARTs的依赖以及优先级的安排，或者特殊时候同步处理。当CSAs关注整个系统架构时，SA将关注体系结构对整个系统各自部分的影响。然后在各自的范围内指导和支持开发团队，就像CSAs指导和支持SoAs和SAs一样。SoA负责确保策略、结构和解决方案在职责范围内保持一致。架构团队的协作根据相关解决方案设定的优先级，或者作为待定项。

图2中可视化的临时集中开发描述了架构工作对不同解决方案和/或ART产生影响且不限于特定区域的情况。

图2  CSAs、SoA、SA之间的协作

在这种情况下，将为特定任务设置一个临时工作组。CSA将领导工作组，并邀请所需解决方案和/或ART中的其他架构师参与。CSA将支持完整的系统视图，并在需要时与并行运行的其他临时工作组进行同步。工作组的成员均负有寻找适用于ARTs和完整系统视图的解决方案的同等责任。工作组将确定受影响的解决方案和ART中的工作。

在这种情况下，将为特定任务设置一个临时工作组。CSA将领导工作组，并邀请所需解决方案和/或ART中的其他架构师参与。CSA将支持完整的系统视图，并在需要时与并行运行的其他临时工作组进行同步。工作组的成员均负有寻找适用于ARTs和完整系统视图的解决方案的同等责任。工作组将确定受影响的解决方案和ART中的工作。

值得一提的是，CSA / CSA团队的数量可扩展至正在开发的系统的规模，例如其子系统的数量或定义的ART /解决方案的数量。

Q2 CSA和SA/SoA的职责划分？

图3描述了不同架构师角色的职责和重点领域。“解决方案”和“ ART”框代表职责和组织领域，不是系统的技术部分。子系统用于显示整个系统的分区，包括与其他子系统的接口。每个子系统都包含软件和硬件电子组件。

图3 一个有组织的和分区的系统示例

SA负责在ART的职责范围内开发和体系结构的维护，以及子系统之间的结构和接口。CSA应该是SA工作的一部分，负责结构和外部接口的制定，并确保ART子系统完全适合整个系统。

在解决方案级别，SoA与SA的职责差不多，这意味着SoA负责解决方案及其ARTs的结构和接口，同时要完成CSA的工作，确保整个系统的一致性。

CSA的主要职责是开发和维护与SoA和SA对话的完整系统的体系结构。CSA专注于解决方案和ART之间的整体结构和接口（不是内部的），并协调解决方案/ ART之间的更改。

Q3、如何在SAFe中设置和组织CSA？

当CSA与所有解决方案架构师和ART一起工作时，CSA已在沃尔沃公司中放在解决方案级别，由其负责整个电气系统及其集成。如图4所示。

图4  沃尔沃汽车中的CSA SoA和SA协作

CSA分为敏捷团队，每个团队负责对接并支持特定的解决方案和ART。除此专业外，每个团队都应该能够为其他CSA团队和临时工作组做出贡献。

总结

当我们在Q1中讨论CSA与SA / SoA之间的协作时，有待解决的一件事是如何在开发阶段启动这种协作。谁发起协作并不重要，但重要的是要确保所有相关的CSA，SA和SoA都从完整的系统角度参与寻找最佳的架构解决方案。因此，首先要确保的是，所有ART/Solution都知道CSA的存在，并了解何时应将它们参与一个或多个子系统的特定体系结构解决方案的开发。

一方面，开发阶段的体系结构更改可能源于负责一个或多个子系统中功能实现的ART/Solution。 例如子系统上需要支持新功能的新接口， 在这种情况下，此ART/Solution中的SA和SoA应该对计划的体系结构更改的影响进行初步评估。如果确定更改不会影响其他ART/Solution所拥有的子系统，则可以根据其本地商定的体系结构决策着手实施新功能。否则，他们应联系负责此ART /解决方案的CSA（人员或团队），以便共同定义整个系统的最佳架构解决方案。CSA还可以帮助从其他ART /解决方案中识别SA和SoA。

另一方面，在开发阶段的体系结构更改也可能源自CSA团队。例如由于通信总线上的高带宽而将一个功能重新定位到另一个子系统。在这种情况下，CSA应召集所有受影响的子系统ART/Solution的SA和SoA，以便为整个系统找到最佳架构解决方案。

关于Q2中提到的CSA和SA / SoA的职责，很明显，使CSA参与影响多个子系统的更改对于从整个系统角度确保最佳体系结构解决方案是有好处的。但是，如果影响到两个（或少数几个）子系统和ART的微小更改，则这些ART中的SA / SoA应该有可能对其子系统进行决策，并将更改告知CSA。

关于SAFe（Q3）中CSA团队的安置和组织，沃尔沃决定采用将这些团队与SoA放置在一起。这种的好处在于，他们负责整个电气系统相关的多个领域，例如工具，平台软件和硬件以及与整个系统体系结构相适应的常规系统集成和测试。但是，缺点是CSA团队也同样参与其他解决方案的开发，导致他们的职责超出了其所属解决方案的范围。

组织CSA团队的不同方法也是可能的。沃尔沃汽车上讨论最多的方法之一是，CSA团队是否应在负责整个系统的解决方案中组建ART。这种方法被拒绝了，因为根据SAFe的说法，ARTs应该生产完整的可发布产品，而架构本身就是可发布产品的一部分，但它本身并不是可发布产品。讨论的另一种方法是，由于CSA团队在开发的早期阶段要进行大量工作，然后才开始在ART和解决方案中进行持续开发，因此将它们置于SAFe框架之外。这也被拒绝了，因为CSA是持续开发流程的一部分，并且在后期开发阶段同样重要，因此它应该是SAFe框架（ART和解决方案）的一部分，其中大部分开发工作都在其中进行。

最后，CSA团队也可以置于SAFe的投资组合级别。但是，如果一家公司拥有多个投资组合，那么即使多个投资组合同样需要其工作，仍然不能解决将CSA纳入一个投资组合的问题。决定将CSA放置在何处取决于CSA如何最有效地成为持续开发流程的一部分，而不是从主流的角度进行操作。同时，重要的是要确保CSA在产品战略和业务工作中持续投入和参与。