看看软件架构师的职责

> Photo by Daniel McCullough on Unsplash.

这篇文章绝对比我以前的那些不同。现在有一段时间，我真的想写一些理论文章并分享我在启动时成为软件架构师的想法。让我们从日常工作中真正做的事情开始。

介绍

如果您阅读了我的一些写作，您知道它与云，容器，安全性和更多的流行语有关。但它实际上是什么意思？我在日常工作中做了什么？

对我来说，它实际上更容易向行业之外解释架构师师的位置更容易。

• “像一个建筑师，但是对于软件而言。”
• “有蓝图，草图和这些东西？”
• “确切地！”

看？简单。

但是，一旦你更深入地解释它就会变得更加困难。一旦有人真正了解一些流行语。

软件架构师作业有很多定义。这是一种包含多种职责的位置，可以由各种具有完全不同的方向的人完成。为了给出一些例子，有些是研发团队的一个组成部分，而其他人则更接近顾问（甚至有时承包商）。有些人专注于特定的项目或产品，而其他人则采取更广泛的角度。有些人采取完全内部的视角，而其他人则更为以客户为导向。

它还与架构师工作的组织类型和他们乘坐的舞台有关。例如，大公司可能会有一些架构师部门，每个架构师都专注于组织中的特定产品或方面。

架构师在初创公司中的角色通常具有更大的灵活性，并且通过在早期加入新的启动，我很幸运能够塑造我所看到的架构角色。

有许多文章将为您提供架构位置的优秀概述，将其除以类别和子类别。今天，我想谈谈我的个人观点。或者更确切地说，我现在正在做什么。

> Image courtesy of the author.

架构师位置的支柱

当我向新同事解释我的立场时，我将其描述为我们解决方案的高级方面的一般接触点。我使我的企业对核心产品有了很好的理解，而是对解决方案如何工作的理解 – 我们拥有的组件以及它们如何相互作用，数据流动的方式，我们使用的技术堆栈等。

显然，您无法期望任何单身人员了解一切或在各方面的专家。然而，我相信，我的立场的人应该有必要的背景，以便有很好的理解，充满信心，以发出意见（即使需要一些额外的研究），并始终渴望学习和发展。那是必要的！

我的同事可能通过我们每天所述的互动类型了解我的立场。那些有时认为我们产品的核心，但通常处于更高的级别并关注基础设施，组件之间的集成，客户事项，安全事宜等。

当我开始更深入地考虑它时，试图了解我的立场的确切构建块，我意识到我很容易将我的工作划分为四个不同的方面：设计，基础设施，API和集成。

在我的角度来看，这四个方面不仅彼此相关，而且它们或多或少彼此依赖。我开始看着它们作为分层结构，这对我来说完全有意义：

> Image courtesy of the author.

让我试着解释一下。

拿起一个（虚拟）铅笔

主要的是，至少我个人花费大部分时间的那个是设计。这是我工作的所有其他方面取决于的基石。这也是所有蓝图和草图都活着的部分。实际的架构图纸。

重要的是要记住，在展示设计时，大多数人都不会对复杂的系统设计感兴趣（尽管您可能仍然想要拥有一个 – 至少为您自己）。他们很可能会更加感激看到更简单和更优雅的图表，并且肯定会帮助他们更好地了解自己的思维方式。

然而，引领我们解决方案的端到端设计不仅仅是关于如何提供信息或漂亮的图纸。最重要的是，这意味着我负责构建块，通信，集成点等的高级设计。确保我们清楚地了解组件如何合作，涉及哪种技术，以及数据流动。

谈到数据，我有几年的大数据经验 – 我作为数据工程师和数据工程团队领导者在我以前的位置，这可能是我在工作时总是专注于数据的主要原因在设计上。此外，我有时会发现它有效地思考解决方案架构 – 甚至是一个小的一个 – 作为数据管道。它并不总是一个很好的契合，通常没有涉及的数据湖，但我相信它更容易连接点并清楚地了解我想要实现的东西，可能的数据流动以及如何我的设计覆盖了所有这些。

最后，在考虑外部技术时，迄今为止最近的发展是最重要的。始终确保您计划在产品中使用的每种技术，基础架构或图书馆都不只适用于您的用例，而是最好的选择 – 坚实，维护良好，安全。

所有的钱都在哪里？

一旦我们清楚了解我们的解决方案图 – 建筑块和接线 – 是时候了解这一图栩栩如生的时候了。我们解决方案的端到端设置是什么样的？每个构建块居住在哪里？他们如何沟通？

基础设施的主要目的是支持设计，并且为了做到这一点，我们必须用纯粹的救主心态做出相当多的决定：

• 我们将使用的机器类型运行我们的系统。
• 我们将使用的缓存解决方案类型。
• 是否将成为云集成的解决方案或我们提供自己的解决方案。
• 如何自动扩展基础架构以确保我们可以支持必要的负载，但具有最低资源。

但是，我第一次考虑基础设施，在创建我们解决方案的设计时将是。我觉得即使你在手头上没有任何东西，你只开始考虑大局，你应该已经给出了一些想法，例如数据存储的位置以及如何访问它，需要哪些数据库，以及可以利用其他云组件。

如今，云架构通常是完整解决方案架构的组成部分。云组件可用于替换架构的部分（例如，有效地执行流程的某些部分或从客户接收数据），并且在许多情况下，它们将比您的自定义解决方案更便宜，更高效。返回数据工程世界，使用预定义的云解决方案可以使用几个月的研究，并且仍然在训练ML模型时提供惊人的结果。

当然，您可以根据预定义的云组件进行限制，但肯定应该考虑使用它们。

界面理论

API是您产品中混乱的最终治疗方法。它们是确保每个组件的最佳方式 – 无论是您的企业级产品还是微小的内部软件包 – 只是以其所设计的方式解决的方式。

我将它视为我的角色的一部分，以确保我们尽可能使用Clear API，并且我发现这一极为重要的不仅要明确定义我们的产品与外界的互动，还可以如何互相互动。

我坚信每个组件或包装，甚至是完全内部的组件，都应该有一个清晰的界面。拥有它应该清楚地了解其使用案件的人，谁应该以什么方式访问它，以什么方式（从我的建筑师角度来看，知道谁正在访问它以及以何种方式，这是安全的我的角色的重要组成部分，它从确保接口 – 外部自然，而且是内部的），以及为什么他们期望得到什么。他们不能让任何人在任何他们想要的方式中导入包或与组件进行互动。这可能是灾难性的。

通过清楚地了解用例，它应该相对容易定义一个清晰的接口 – 一组函数，这是该组件与外界的唯一交互，每个都具有明确的输入和输出定义。

一旦定义该接口，如果有人以不同的方式使用该组件，则可能意味着两件事之一：它们使用错误或者应更新界面以支持新的用例。无论哪种方式，这种方法都可以更清楚地了解组件的交互，并将导致更好的产品。此外，具有具有定义接口的明确端点也使得测试组件更容易，并限制在系统中被破坏的可能性 – 或者至少它可以更清晰地突破发生。哪一方突然不遵循商定的API？

放在友好的脸上

在规划我们解决方案的高级设计时，与客户的整合及其系统也落在我的架构师翅膀下。这些是图表的边缘，我需要确保我可以回答这些问题，比如客户如何向我们发送数据以及我们如何将结果返回给他们。

由于集成可能强烈影响设计的部分，基础设施和API，因此有些人会说它属于这方面的底层金字塔（或可能在与其他方面碰撞的相邻金字塔中）。我部分同意，但我认为坚实的设计，基础设施和API将使固体产品 – 稳定，高效，有效。此外，如果两个客户有相互冲突的要求，会发生什么？

显然，客户的最佳解决方案是为了整合，正如他们所希望的那样，尽可能少的努力。它让他们开心。但作为一个建筑师，我必须问自己，如果我们实际上可以支持客户所要求的一切。很多次，答案是肯定的 – 特别是对于一个为客户渴望的小型创业公司。多次，说不出问题，但建筑师必须至少举起红旗。

尽管如此，一旦您拥有固体产品，可以进行调整以满足客户要求。有时请求感觉如此根本，我们使其成为我们产品的一部分。其他时候，它可以是如此redgy，如果你很幸运，处理它会在你的代码中有十几个“ifs”的结果（如果你不是那么幸运，它需要一个特定客户的专用基础架构），但你可以容纳它无论如何。底线是您不希望丢失顾客通过集成差距。

概括

在本文中，我讨论了软件架构位置对我来说意味着什么以及我在工作中实际做的事情。

虽然我经历了我工作的四个方面，但我并没有真正提到另外两个重要方面：安全和合规性。两者都是我工作的每个其他方面的思想和决策过程中的一个组成部分，我致力于他们的大量时间 – 这么多的时候扩大了这些主题，同时简要讨论了上述工作的其他方面使本文专注于他们，这不是我的意图（我肯定打算在不久的将来写一整块，在不久的将来）。

最后，重要的是再次强调这篇文章的观点。这个职位有一个广泛的定义，人们可以在人们之间变化。我仍然希望你发现它有点有趣，也许你甚至有一个新的想法或者只是有助于思考的东西。