👩🏻‍🏫 ❕ 📡 敏捷教会了我们建筑的真正含义 🤜🏿 ⏳ 📕

什么是建筑？不是城市或建筑物，而是组织版本：企业体系结构，解决方案体系结构，应用程序体系结构，软件体系结构，业务体系结构，基础架构？当我们（建筑师）从烦人的象牙塔转向这个话题时，我的头开始动起来。但是这一次，我必须谈谈这个问题，因为这是考虑（建筑，技术）债务和建筑主题的前提，所以这三篇文章总会成为一个故事。

敏捷以及他对建筑的看法

敏捷宣言中正式提到了架构，该宣言指出基本原则之一是：“最佳的架构，需求和设计决策是在自组织团队中诞生的。”

最好的体系结构，需求和设计来自自组织团队。
（摘自：《敏捷宣言》原则）

问题不仅在于它没有给出体系结构的定义，还没有给出体系结构的来源，而且还很幼稚。

敏捷不仅有认真的支持者（而且我认为自己也是其中的一员），而且还有相当一部分狂热者，他们倾向于相信（有时迫使他们的领导层相信）“在敏捷上工作”会给您某种无限的改变和改变的能力。您可以进行各种更改，包括大的转换。我们甚至拥有相当大的框架，例如可扩展敏捷框架（SAFe），该框架可以根据最高战略级别的灵活原则进行更改。

这样的框架与早期创建的综合框架（FEAF，MODAF，TOGAF等）有共同点。没有人真正使用全部内容。所有在狭窄环境中工作的人通常都不容易理解框架的范围。在我看来，当前工作实践的基础已被推断出可以创建一个完整的框架。尽管“填充物”从未经过测试，但是，所有东西都作为“最佳实践”出售。

让我们看一下TOGAF和SAFe，它们牢固地基于应用程序开发的世界。当TOGAF将其两个体系结构定义之一基于ISO 软件体系结构的定义时，这是显而易见的。

– , , .
(: ISO/IEC/IEEE 42010:2011)

或者，当SAFe告诉我们有功能和促成因素，而促成因素之一就是“基础设施”（尽管您当然可以抽象化这个概念）。框架通常在定义和细节上有点繁琐，它们试图变得全面。因此，随着时间的推移，它们通常会越来越多地定义和拥抱。但是大型框架通常仅部分使用，因为在大多数情况下完整框架是官僚主义的过度。在“定义疾病”中经常看到的是，对所有事物（包括那些将在现实中忽略这些定义的事物）建立严格定义的愿望（路德维希·维特根斯坦）。

尽管可以用批判性的眼光看待大型框架，但敏捷概念本身（尽管不是新概念）的确（至少部分）确实是对复杂性（尤其是可变性）的非常实用的答案。敏捷是当今复杂组织中大多数变化和转型的反应。复杂性是因为IT允许变得复杂。可变性，因为与充满重型设备的工厂相比，IT相当容易更改。它仍然是软件，甚至是硬件没有像建筑物的墙壁那样的使用寿命。与过去的“纸质”组织相比，如今的复杂组织产生了更多的自主变更。采用大型前期设计（BUFD）的瀑布变得不切实际，以致在当今拥有IT负载的世界中，瀑布几乎变得不可能。因此，我们在许多（敏捷）团队并行工作的基础上，在组织中获得了永久的大规模并行发展。

, - . - , , , . - — , — .
( , )

如上所述，关于“什么是架构”的讨论通常是浪费能源，最好将其用于为组织开发良好的设计解决方案。架构有很多定义，我已经在上面指出了最广泛使用的定义。 Mastering ArchiMate中还有另一个定义，我承认我在某种程度上喜欢它：

企业体系结构是关于理解组成企业的所有不同元素以及这些元素如何相互连接。

这来自企业体系结构开发研究所。这并不是说我不同意他们写的所有内容，但出于某种原因，这个“ O”并没有说“ How”。而且“理解”是一个同样的易滑词。因此，这一切并没有真正帮助您。麻省理工学院，美国政府等还有许多其他定义。ArchiMate基金会的其中一个定义是：“用于设计和实施企业，业务流程，信息系统和基础结构的组织结构中的一致同意的原则，方法和模型。 ”。

但是符合我自己感觉的定义是马丁·福勒（Martin Fowler）在他2003年广为人知的文章“ 谁需要建筑师？””。在那里，他完成了将架构定义为“难以更改的事物”。这与Grad Buch的定义没有什么不同，他说：

所有架构都是设计决策，但并非所有设计决策都是架构。体系结构代表着形成系统的重要决策，在此系统中，重要性是通过变更成本来衡量的。

（注意：更完整的引用对“科学与艺术”有好处）。我还坚信，毕竟，架构只不过是设计决策，真正将其分离的愿望部分源于“ [谈论设计决策的愿望，但希望将它们夸大”，以便他们听起来很重要”（福勒）。因此，在我们的建筑世界中，我们可以说：体系结构是难以更改的设计决策。当然，仅在实施它们时真的很难更改它们。本文将经受住一切，字母也会轻易改变（除非您参加了为期6个月的地狱式建筑讨论）。但是，作为衡量设计决策重要性的度量标准，体系结构是一个很好的定义，并且比ISO，ArchiMate，TOGAF等组织中的定义要好得多。

但是，它具有“难以更改”的特性。

假设您有一个设计解决方案，为您的开发人员描述他们应该如何构建其Python代码。如果您有很多代码，那么将所有这些代码从一种结构更改为另一种结构将需要大量的工作。换句话说，这很难。因此，此选择的解决方案是“体系结构”，在这种情况下为软件体系结构。但是，一个开发人员可以轻松地忽略此决定，而编写功能不同的代码。最后，对软件进行“更改”很容易。尽管很难更改所实现的整个体系结构，但通常很容易仅更改其中的各个部分（请参见上面的Ralph Johnson）。因此，建筑是由许多“轻”组成的“重”事物。您可以在各个级别看到它，例如，如果您的设计决策是仅使用Oracle数据库，并且突然出现了单独的PostgreSQL数据库，这些数据库很容易设置，因此很容易出现（这使您的情况更加复杂，通常不批准）。但是更换在您的环境中，PostgreSQL上的所有 Oracle都很繁琐（这可能甚至不完全可行）。因此，形成以下定义：

体系结构-难以从实现中完全删除的设计决策。

（尽管在大多数情况下，福勒的收缩“很难改变”）。关于“难以更改”的另一种说法，由于依赖他人而可能难以删除它们，因此“实施”一词的含义很广泛，例如，改变服务的制造商和消费者。应始终从组织的角度考虑``沉重''，这是为什么架构范围通常比解决方案，项目或产品的范围宽的一个很好的例子。
注意：1）此定义不依赖IT。2）可以这样说，按照ISO，我在“体系结构”的定义中揭示了“基本”一词的含义。

敏捷和架构，相同规模的不同目标

事实证明，敏捷世界和建筑世界之间有着非常有趣的关系。敏捷设计为尽可能进行更改，以使更改变得容易（或至少不困难）。另一方面，正如我们所注意到的，架构是很难改变的地方。换句话说，它们处于频谱的相反两端；它们是您组织中的根本摇摆。

我支持敏捷，并宣布这是更改IT加载的复杂业务环境的最佳方法。但是，这意味着我们发现使用敏捷方法很难实现的就是事实上的“架构”。所以敏捷教我们什么是建筑。

注意：值得注意的是，敏捷是从精益中获取很多，精益是基于丰田的物理工厂方法。丰田想要使生产更加灵活以应对复杂性。但是，此设置的许多方面不容易转化为软件的fl石世界。例如，丰田公司支持非常有限的可变性，并且大多数事情都无法改变。在软件中，一切都会改变，从定义上讲，一种（稍微但有很大影响）对物理生产过程进行次优化的方法可能不是另一生产过程的基础，这并不是正确的。

那么，我们在哪里找到架构，哪里会遇到麻烦？有几个明显的例子：

feature/defect «», , . ( , , ESB ), . , . , , ( ), .
Agile , , YAGNI (You Ain’t Gonna Need It) (just in time). SAFe Architectural Runway, features defects. SAFe , . SAFe « Runway», features «». YAGNI ( , «»). – , – . , , Agile , « , DevOps» (DRDC). , , Tomcat, JBoss, Session state storage , File sharing, Redis, MongoDB, MQ, IIS .. Lean ( ) YAGNI, , , «» («muda» « » Lean). , , , , ( «muru» «»). , , Runway , , .
Agile , . , , , . , , Agile ( «muri» «»). , . Agile ( : ...) – .

对于在此使用日语的条款，我深表歉意。因此，敏捷关注的事实是架构是一个对象，而不是一种实践，但是头脑却说：

架构是使敏捷变得困难的每个已实施的设计决策。

您在“跑道扩展计划”中放置什么的选择取决于进行转换的难度：这是架构的选择。而且，您不能在用户的压力下将其留给产品所有者。还应该在架构利益相关者的参与下做出选择，因此要对“保险杠”和“短期”进行制衡。这个迷你系列文章的第二部分将详细讨论体系结构（作为一种实践）。

将架构定义为“重物”的组合并不是我们所需要的。因为除了“艰苦”之外，我们还需要一些有关架构方面的建议。人们常说架构的思想是通过创建灵活的解决方案来提供灵活性。实际上，福勒指出，架构师的任务是删除架构。但这太简单了。灵活性通常很昂贵，并且这些“成本”（时间和金钱）不能无限地增加（请参见上面的Johnson）。每个人都希望解决方案具有完全的灵活性，但是它并不便宜（而且没人愿意付账），它并不快，而且并非总是可行。有时情况很简单：您必须做出难以改变的选择，您不能支持所有选项（例如，选择平台，您不能支持所有功能）。当然，如果选择不是很昂贵，则选择灵活的解决方案或尽可能长地推迟选择（如SAFe建议：不要限制您的选择）。但实际上，人们常常不得不做出选择。难以更改的选择是体系结构选择。架构试图最小化不必要的灵活性，因为天真地认为会有一个世界，所有的变化都很容易，没有困难。事情同样重要，甚至比灵活性更重要。我认为其中有三个：可靠性，效率和灵活性-鲁棒性，效率和灵活性（REF）。

了解有关REF，架构实践和债务的更多信息。在第二部分中，但我记得我们很多年前创建的视频“为什么要使用企业架构”，当时我们使架构成为 BUFD世界中最灵活的：

听你的医生和律师

总之，架构（作为对象）就是“繁重的”，但您也可以说“架构（作为一种实践）很重”。它们之间有着密切的联系，架构（作为一种实践）很困难，因为当今的复杂性使变更变得困难，而今天的不稳定使变更变得强大。这就是为什么您必须付钱给优秀的兆字节架构师。好吧，也许不是，但是您绝对应该听取优秀建筑师的意见，并非常非常认真地听取他们的建议。只剩下一个简单的问题：如何认出一个好的建筑师？

敏捷教会了我们建筑的真正含义

敏捷以及他对建筑的看法

敏捷和架构，相同规模的不同目标

听你的医生和律师

More articles: