9月5日，莫斯科在HSE主持了圆桌会议“ IT项目架构师”。 圆桌会议的组织者Maxim Smirnov是
有关建筑和
Facebook频道的
博客 。
举行这样的活动我感到非常高兴。 成为一个很棒的建筑师曾经是，而且仍然是我的梦想。 很长一段时间以来，我都不了解建筑师的总体能力，如何发展以及如何选择方向以引导他们发展建筑，而且，我认为，这样的问题不仅对我来说是个问题。 很高兴能有一个社区，您可以来问建筑师问题。
在圆桌会议上，提出了15至20分钟的4份报告，随后听众提出了问题并进行了讨论。
报告简明扼要，讨论非常活跃和广泛。
此外，我在报告中的笔记。
报告1
从零开始的项目中决策架构师的关键技能
根纳季·克鲁格洛夫（Gennady Kruglov）
CTN认证SOA架构师
作为演示的一部分，涉及了架构过程的主要阶段：
- 业务参与。
- 敬业的工程师。
- 原型制作。
- 体系结构样式和技术堆栈（微服务，整体式，SOA）的选择。
- 开发架构草案。
- 向客户演示。
- 解决方案设计。
- 记录拱门解决方案。
- 建筑监督。
表现亮点：
建议制作一个原型以展示给企业。 在可能的情况下，选择一种体系结构样式时有必要让不同的方面参与进来-开发人员，安全性，操作。 设计草图时，您需要制作架构的不同部分-业务，技术，安全性。
如果可能的话，有必要吸引那些将直接使用系统这一部分工作的人员。
与有关方面讨论后，演示了原型。 如果项目开始，则将对体系结构的每个级别进行更详细的研究。
在开发过程中，必须与架构师进行同步，以验证过程是否遵循所选的路径。
发言人认为，建筑师需要的技能：
- 沟通技巧（说服，谈判）
- 简报
- 头脑风暴和研讨会
- 建筑风格知识
- 现代技术的广阔视野（了解优势和劣势很重要）
- 设计与应用技巧
- 使用不同框架，产品和编程语言的开发技能
- 决策文档框架知识
- 了解SDLC的不同类型（系统开发生命周期）
- 广泛的专业联系网络
- 管理开发团队的技能
报告2
IT项目的架构支持
德米特里·罗曼诺夫（Dmitry Romanov），ITSK
设计IT解决方案，项目的架构支持，每年大约80个项目，大约50位建筑师参与其中。
首席IT架构师的服务确定了IT领域的技术政策，该政策由IT项目架构师实施。 在回答建筑师通常会收集必要专业知识的问题时，Dmitry指出了以下来源：
- 经验-创建类似的系统
- 同事-公司内部或其他公司中的某人
- 供应商-与开发商协商
- 专题论坛
- Technopark-基于Technopark的认可或沙盒
考虑到需要在ITSK中担任架构师的角色，德米特里（Dmitry）指出，需要一个IT项目的架构师，这样一来，例如，在任何情况下，项目都不会完成一年，然后他们工作了六个月就意识到没有规模，然后重做了两年。 清楚的理解对于可以实现所建议的体系结构很重要。 根据项目管理方法，在ITSK中，架构师要么进入团队（如果敏捷），要么进入项目专家组。
报告3
组织的IT项目中的体系结构：主要重点
莫斯科信息技术部Ivan Lukyanov，产品“国家服务和MFC”
演讲者的专业传记：Diasoft的开发人员，BSC Praha的开发团队负责人，Neoflex的首席顾问，Alfa Bank的体系结构和战略部主管，DIT的体系结构主管。
Ivan建议从描述现有体系结构（按现状）开始，创建目标体系结构（要成为），并分析“组织现在所在的位置”和“组织想要去的位置”之间的区别，以描述使系统达到目标状态的步骤。
架构中IT项目的主要重点是：
- 关于要解决的业务问题的说明：架构师必须确保业务任务正确摆放，并以适合设计的形式进行描述，并由负责业务的人员同意
- 方式愿景：在组织架构师的努力下，应针对业务的特定需求开发组织的目标体系结构。 应该将目标体系结构分解为具体步骤（项目）以实现它。
- 设计：所有解决方案的设计均考虑到已开发的目标体系结构。 目标体系结构在项目之间逐步实现。 架构师批准有关架构的决定。
- 项目实施过程：组织应具有一个过程，其中包括对业务任务的分析和描述，目标体系结构的开发和设计过程（开发和运营未包括在报告中）。 该过程应得到所有参与方的同意，并得到管理层的支持。
- 对项目实施过程的方法学支持：经常是建筑师成为了人物，肩负着开发组织中实施IT项目的方法论的责任，同时考虑了业务任务和设计的制定。 作为这项工作的一部分，可以对组织中实施IT项目的现有流程（如果以前有过）进行调整，或者从头开始创建新流程（如果不存在）。 方法论工作的结果是描述的过程和支持文件，以模板的形式形式化。
该公司现在已经开发了自己的方法，包括用于文档工作的模板。 使用了
TOGAF和Gartner的原理。
批准了架构原则，并开发了“建筑和技术解决方案”文档，其中描述了解决方案的业务需求以及实施这些解决方案的项目。
架构师的特点：
- 社交性。 与管理层，绩效人员，支持人员，经理和测试人员的沟通非常重要。 架构师必须扮演翻译的角色-从业务语言翻译为技术语言，反之亦然。
- 前提条件是开发人员的经验（当然，如果是分析的话）。
- 尊重同事。
- 不断发展。
建筑不是用花岗岩铸成的一成不变的纪念碑，而是从业务支持角度对我们想要实现的目标的生动，不断发展的看法。
报告4
IT项目架构师：可能的观点之一
Evgeny Aslamov Aslamov，Lanit集团公司首席架构师。
尤金（Eugene）担任架构师的道路：开发人员，分析师，项目经理。 在短篇小说中，作者提出了几个与建筑师在定制开发中的角色有关的问题：他周围的事物，他的工作以及他的工作方式。
在尤金看来，谈到定制开发中的架构师时，我们取决于各种因素-时间，预算，团队，复杂性和任务量。 通常，在复杂的项目（数千个用户方案，与数十个系统的集成，大数据量，对高可用性和灾难恢复的严格要求）中，架构任务由一组架构师完成。 在更普通的项目中，一个人可以应对这些任务，而架构师并不总是专注于这些任务-他的角色可以与其他角色-首席开发人员或分析师结合在一起。
像任何团队成员一样，架构师在特定的环境中工作。 这种情况的一个概述：
顾客- 负责项目的客户提供的最高（无论如何，对于关键决策而言足够高）管理；
- 客户委员会（建筑，设计，运营等-经常发生）；
- 信息安全专家服务或部门；
- 需要系统“刻录”项目的客户员工；
- 现实-相当平庸的惯例，人为因素，程序问题，细微分歧等；
团队合同- 截止日期；
- 预算
- 法律报价；
- 我真正想应用的新技术，方法，芯片；
- 传统：它行之有效，是件好事，一切对我们都很好-改变什么等等。
作为上下文的一部分，一个建筑师或一组建筑师将执行以下操作：
- 它构成了项目开发和生存团队的边界。 首先，我们正在谈论由非功能性需求引起的边界。
- 考虑主要利益相关者的意见，形成，支持和更新体系结构解决方案。
- 担任口译员-从技术翻译成俄语，反之亦然。 对于客户和团队都是实际的。 架构师必须了解项目的所有方面（以及领先的分析师和项目经理），并能够解释他们与技术部分的关系。
- 提出很多不愉快的问题。 碰巧的是，某些决策是在团队中一个或另一个成员没有参与的情况下做出的。 这很正常。 如果已经完成某件事并且正在影响或可能影响系统的体系结构，那么您需要找出原因，弄清楚是否需要立即更改某些东西，为将来提供一些措施，或者可以简单地记录并保留它直到更好的时机。
在回答“他如何做到这一点？”这个问题时，尤金首先谈到了开发建筑解决方案的问题。 确定了有助于完成此任务的几个组件：
- 经验和类比。 这是建筑师最重要的资产之一。 而且它需要不断增加-不要停滞在一个项目，技术等中。
- 视野。 您不能使用自己的经验-同事的经验，社区的经验，标准。
- 原型。 如果使用新的，未经测试的或具有明显风险的产品，则必须进行原型设计。 同时，正确，准确地提出原型必须回答的问题很重要，否则只会使情况恶化。
- 保护您的决定。 在项目团队之前，在建筑委员会（您或客户的）之前，在您自己面前。 作为解决方案之一，可以引入ATAM-体系结构权衡分析方法 （全部或单个元素）。 例如，在我们的许多项目中，实施决策保护是将关键决策呈现给项目外的同事，以征求其他意见和评论。
与其得出结论，不如说：建筑师以及热爱工作的任何专家的非正式任务之一就是普及知识，技术，方法和技能，这将使团队更有效，更方便地解决项目上的问题。
尤金（Eugene）在habr上的文章“
我们正在Sparx Enterprise Architect中准备一个
项目。 我们的食谱 。“
问与答
接下来是问答部分，最容易记住的部分可以在下面阅读。
建筑师来自哪里？
根纳季：软件架构师-前团队负责人或那些负责人或首席开发人员。
德米特里：建筑师来自具有广泛专业知识的顾问开发人员。
开发人员可以讲话并绘制演示文稿-解决方案架构师。
尤金：通常，从任何部分开始-从开发，测试，项目管理等。 但是无论如何，某些技术专业知识会有所帮助-不必从头开始开发它们。
个人经验的一个例子：Lanit聘请了莫斯科国立大学机械系的一名学生，他是一个聪明，善于交际的无星状疾病的人。 他在分析，开发和与客户的沟通方面做了一些工作。 结果，他成为了我们公司的一名应用架构师。
伊万：来自开发商。 如果有一个好的开发人员，那么他可以继续钻研编程语言，进行更深入的开发。 但是，如果一次他好奇技术任务是如何诞生的，谁进行分析，由谁来决定是否应该这样做，那么这表明专家已经走上了新手架构师的道路。 好奇心的下一个层次是解决方案在业务层面上是如何诞生的。 您如何向组织负责人表明他需要而又不需要什么。 在描述建筑师的角色时，
Gregor Hohpe使用了电梯隐喻 。 电梯停靠的每个楼层在组织中都是某个级别的：第一层-机房-这些是开发人员，生产人员； 顶层-组织管理。 使建筑栩栩如生，建筑师在每一层（从第一层到最后一层）进行交流，并且他必须在每一层应对各种困难-技术，政治，沟通。
架构师能够收集必要的信息并传达到每个级别。 实际上，他是有关各方之间的调解人。
项目经理和架构师之间应如何共享权限？
权限之间必须保持平衡。 架构师的权限在技术部分，项目经理在组织部分。
如果余额转移到了RP，您可以按时完成项目，但无法正常工作或无法扩展。 而且，如果对建筑师感兴趣，那么在没人需要时，您可以得到一个很棒的项目。 这是如何回答“您爱谁的人更多-妈妈还是爸爸？”的问题。
如何成为拥有大量不同项目的企业架构师？
伊万：在大型组织中，有超过2,000人组成一个公司架构，几乎不可能遵循它。 在DIT中，将产品（服务）划分为一个部分，每个产品都有自己的技术堆栈，自己的体系结构。 至于公司架构，股东需要更多，以便他们了解组织在架构开发方面的发展方向。 为此，通常在组织中强调首席IT架构师的角色，其主要任务是确定公司体系结构的总体格局。
如何建立项目架构师和公司架构师之间的互动？
沟通很重要。 您需要建立沟通，然后进行沟通。 项目架构师可能不需要了解公司架构，但重要的是要了解集成的对象和影响。 建立建筑委员会很重要，不仅可以知道公司建筑师，而且还可以认识设计建筑师。
您可以从价值的角度看待它-谁带来更多的价值。 如果解决方案有效，那么就有价值。 企业架构本身并没有带来价值，而是通过已经实施特定任务的架构师的解决方案带来价值。
没有人需要通才，对任何事情一无所知的人越来越少。 最好能够回答特定的问题，例如，这里的RabbitMQ是否足够或是否需要Kafka。
企业体系结构存储库如何组织？
是否有可以计算，验证等的复杂模型？
尤金（Eugene）：我们有一个体系结构的存储库，但是没有自动化的方法来计算任何指标。 模型与模型本身之间的关系使我们可以将体系结构视为整体，而不是一组图片。 存储库的任务之一是提供影响分析。 在此基础上，您可以估算更改的价值。
后记
您可以来听听建筑师的声音，结识社区，真是太好了。 这样的会议始终是我了解在哪里进行挖掘以找到必要知识的机会。 此外，您可以讨论工作案例并获得建议。
感谢Maxim Smirnov和HSE组织了一次建筑师圆桌会议！
也非常感谢报告的作者（Eugene Aslamov，Gennady Kruglov，Ivan Lukyanov）编写本文的过程 ，因为原始注释是在报告期间撰写的，并且包含错误和不正确之处，已得到纠正。
他们说，在照片中，
法国的尚博尔城堡（
Chambord Castle），每个主人都在他的塔上建造。 有时，项目的架构看起来就是这样。 在我看来，需要一个建筑师，以便使所有事物都变得美丽且尽可能简单，以便即使拥有一堆风格各异的塔楼，您仍然会得到一座美丽的城堡。