在您的项目中，您是否直接与企业架构师合作？您是否收到企业架构师（EA）的文档？企业架构师是否是项目设计和评估活动的瓶颈？你和我一样，对企业架构师的角色有点困惑吗？

一个小小的谷歌搜索将让你确信EA是某种组织向导，他们可以看到所有并且知道所有。她是否住在一座塔楼里并且像一个熟悉的人一样养了一只乌鸦。

定义很难得到。有很多，听起来好像它们是由混淆机器生成的。但似乎有几种不同的口味：

1. IT-业务桥梁 - The Bridge负责了解当前的业务战略并将其转化为支持该战略的IT项目。
2. 集成大师 - 大师了解整个生态系统 - 应用程序，数据库，服务 - 以及它们如何相互连接。她为IT项目团队提供文档和指导，以确保他们了解生态系统变化和约束的影响。
3. 生态系统设计师 - 设计师是组织中的顶级技术分析师，负责制定项目团队负责详细设计和交付的系统设计决策。
4. Enforcer - Enforcer为组织设置软件标准，并确保所有项目团队都接受有关这些标准的教育。
5. 创新者 - 创新者的任务是展望行业趋势和尖端技术，以确保她的组织具有竞争力。

当然，EA，如PM或PdM，不是一个可以轻松融入任何盒子的角色。 EA的作用部分取决于她所在的组织和她自己的专业领域。根据具体情况，她可以完成所有这些角色。我和同一家公司的不同EA合作过，这些公司采用了截然不同的方法。有些是“这里是一个为您的技术设计提供信息的架构图”。有些人“邀请我参加每次会议，让我审查你们的所有要求”。当你搬到不同的项目或工作岗位时，这会让你很难知道你应该期待什么。

敏捷世界中的企业架构师

这种混乱在敏捷世界中更为明显。我见过的大多数模型都说明了团队的责任，他们非常重视EA的活动，将实际的软件团队显示为EA团队想象和设计的能力的提供者，有时将业务分析完全排除在外。这与Agile软件开发的现实并没有真正同步。那么组织如何将EA集成到敏捷中呢？

我们对敏捷的关注主要集中在用户故事上，这是一种提供软件功能以提供业务价值的请求，通常范围非常小。无论您是将用户故事视为更大功能的细分还是作为独立请求，都将重点放在用户身上。但如果用户故事是整个故事，那么你就遇到了问题。可以一次建造一座乐高城堡一座塔，但是如果你没有从足够大的底板开始，你最终会把它拆掉并重新开始。

我向EA询问了我是否曾在敏捷组织中就构建权进行了一些见解。他解释了他与敏捷团队合作的理想方式。我将把它作为我下一个项目的路线图，以确保我有效地参与建筑师团队。

原文：

本文：https://jiagoushi.pro/node/56