精益企业中企业架构师的角色

2015年11月30日


Photo of Kevin Hickey

Kevin Hickey 热衷于帮助企业组织找到敏捷和精益实践的实际应用。 他拥有作为开发人员、架构师和项目经理领导软件交付的经验。 他目前是 Thoughtworks 的技术负责人。


如果您是一位正在向精益或敏捷实践转型的企业架构师 (EA),您可能会感到有些迷茫。 您已经努力工作才走到今天。 您可能编写了大部分维持企业运营的关键系统软件。 您帮助实施甚至可能设计了架构。 您知道其中一些是较旧的技术,而且有点脆弱,但由于资源太少,时间太紧,因此必须做出妥协。 事实上,您自己跟上最新趋势的能力也受到了影响,因为只有您知道如何保持事物的正常运转。 为了帮助管理时间,您实施了通用标准,并尝试将请求集中到架构评审委员会或其他计划会议。 开发人员经常绕过系统工作,抱怨流程阻碍了他们,但您知道这些事情是为了公司好,因此您加强了政策以试图保持控制。

现在,新的领导层或咨询公司来了,并宣布该组织“正在变得敏捷”。 开发人员将此解读为以敏捷性和灵活性为名做任何他们想做的事情的授权。 他们开始将您视为过去的遗物,并颠覆或忽视您。 他们引入了可能破坏基础设施稳定或在关键时刻失败的实践和技术。 您知道企业需要您完成您的工作,但您觉得每个人都在与您作对。

事实是,他们需要完成您的工作,现在可能比以往任何时候都更需要。 这项工作是利用您的知识和经验来最大程度地降低风险、管理成本、建立 IT 能力以及使技术使命与业务保持一致。 使命保持不变,但实现的方式略有不同。 精益和敏捷都侧重于价值创造、减少浪费和快速反馈,因此您需要一些新的实践才能在这些新环境中取得成功。 新的工具箱包括分享简单的愿景、搭建桥梁、协调业务和提供指导,所有这些都是为了促进创新。

如何实现

总的来说,这是对 EA 和架构团队传统实践的转变。 您现在不再是为开发团队做出决定的集中式 EA 小组,而是一个影响者和信息聚合者。 您的角色不再是做出选择,而是帮助他人做出正确的选择,然后传播这些信息。 要做到这一点,需要一些新的工具和技术。 以下是一些关于如何扮演这个新角色的想法。 所有这些都是高级别的,并不适用于所有组织。 目标是灵活应对您所支持团队的需求;尝试一些技术,衡量它们的有效性,保留有效的技术,并对无效的技术进行调整。

拥有并分享愿景

促进一致性的第一步也是最重要的一步是为企业组合制定长期愿景。 能够描述当前状态和未来状态架构对于使项目保持一致至关重要。 首先评估当前的投资组合。 映射出存在的系统及其功能。 这不需要非常详细或调用单个服务器。 相反,要关注应用程序和产品以及它们之间的关系。 可能需要多层。 如果企业规模足够大,请将问题分解为功能区域并分别进行映射。 如果存在底层架构模式或策略,请识别它以及它在哪些地方被遵循和没有被遵循。 例如,如果企业战略是面向服务的架构,哪些应用程序会绕过它并直接访问主数据? 应用程序在哪里通过公共数据库进行通信?

一旦您绘制出当前状态,请考虑您希望架构在未来是什么样子。 您想保持相同的底层策略吗? 完全转向不同的模型会更好吗? 您当前策略的优势和劣势是什么? 如果您想发展当前的策略,请生成架构的更新视图,其中不一致的区域与其余部分保持一致。 如果您认为有必要进行彻底的战略变革,请规划出理想的最终状态。 请理解,这是一个长期愿景,但您希望其他技术团队遵循这一愿景。

现在您有了一个愿景,您需要确保组织中的项目技术负责人理解它。 向关键开发人员展示您的愿景,并获得他们的反馈和意见。 他们可能比您更了解为什么有些事情是这样的,并且可以帮助您理解。 愿意,甚至渴望根据他们的反应调整愿景。 如果您要对整体架构或特定团队的领域进行根本性更改,请尝试让他们接受更改。 这将使您的愿景更容易实现。 尽量避免将架构作为强制性要求,而是将其用作与开发人员及其团队达成共识的工具。 请记住,您是在努力让他们成为您的合作者和盟友。 他们对愿景的积极参与比完全按照您的意愿实现愿景更有价值。

当您感觉到某种程度的共识时,请使当前和未来状态架构可见。 这并不意味着在驱动器上的文件夹中、Sharepoint 网站上或 Wiki 上。 制作海报或墙面尺寸的打印件。 在多个区域展示它们。 目标是确保每个人都能分享愿景并继续朝着目标前进。 随着架构的发展,更新视觉效果以反映已完成的工作和方向的任何变化。 展示正在取得进展的地方,并认可正在取得进展的团队。 帮助其他人为共同创造伟大的事物而感到自豪,他们就会支持它。

搭建桥梁

一旦你有了愿景,你就希望看到它变成现实。 但是,由于您和您的团队没有开发或管理项目,您如何才能做到这一点? 最好的方法是成为开发团队的合作伙伴和资源。 您的目的不是限制或阻止进度,而是促进进度。 当开发工作开始时,请联系技术和项目负责人。 向他们展示目标企业架构的最新视图,并讨论他们的项目如何实现该愿景。 通常,团队参与的工作类似于企业中正在进行或已完成的其他项目。 确保他们了解这些项目,以便他们可以利用从共享经验到实际代码和工件的任何东西。 尽量避免陷入实现的细节;不要担心将使用哪些库或版本。 相反,要关注项目的高级目标和设计,以及它如何与总体愿景保持一致。

在讨论项目时,不可避免地会出现技术选择。 大多数情况下,团队都满足于使用与企业中其他项目类似的技术。 然而,有时技术人员会了解到一项新技术,并希望使用它来解决他们的问题。 避免立即说不,或者假设他们选择新工具仅仅是因为它新颖有趣。 虽然这种情况可能会发生,也确实会发生,但新工具的创造是为了解决问题,现在可能正是向前迈进的合适时机。 与技术团队讨论选择,以确定他们是否有充分的理由使用新技术。 确保他们了解将新平台投入生产的成本和难度,并且收益大于成本。 您可能需要先听一会儿,然后做一些研究,然后再结束讨论。 考虑使用真实的测量结果和边界进行限时概念验证,以确定可行性。 如果最终新技术不是正确的选择,请尝试获得开发人员或其领导的共识。 尽可能避免将其作为强制性要求。 这将有助于与开发团队建立良好的关系,并确保他们将您纳入未来的决策中。 在试验新工具或技术时,请限制企业在任何时候正在进行的试验数量。 如果同时进行太多更改,将很难准确衡量效果。

最终,只有在开发团队的支持下,EA 才能取得成功。 如果你把他们当作下属,他们会想方设法绕过你,让你的愿景和战略处于危险之中。 你仍然要对结果负责,但几乎没有能力改变它们。 相反,如果你把他们当作合作伙伴,他们会帮助你实现你的愿景,每个人都会成功。 拥抱变化,但要衡量它,并确保每个人都理解变化的价值。 最终,始终尝试引导团队实现企业架构的愿景。

寻找变革机会

大的变化需要时间和机会。 一旦你有了对未来的愿景,并开始在企业内部建立起兴奋感,你就希望立即看到结果。 重要的是要记住,架构的重大变化需要逐步进行,并在适当的时候进行。 使用投资组合中的现有项目来启动变革过程。 指导新的实施朝着架构愿景迈进。 请记住,改变代码并朝着期望的方向前进的机会可能不会以您希望的速度或在您希望的领域出现。 学会庆祝胜利,无论多么渺小,并保持警惕,寻找机会做出积极的改变。

话虽如此,但要与业务部门合作,优先考虑解决现有投资组合中最糟糕部分的项目。 商业领袖很少了解更改技术组件的价值,也不了解维持现状的成本。 当纯粹的技术变革是必要的时候,你就需要创造机会来改变它们。 确保从未来节省的成本抵消实施成本的角度,或从降低风险的角度来构建变革。 如果有必要,在业务部门中寻找合作伙伴,并创建一个既能增加新的业务价值又能实现架构变革的项目。 寻找机会淘汰那些拖累预算和运营团队的旧应用程序和硬件。

对变革步伐的耐心将有助于避免挫折。 请记住,变革只能在正在进行的工作的背景下发生,因此要充分利用预算和投资组合中的项目。 通过确定能够为企业创造新价值或节省比开发成本更多的资金的新项目来创造机会。 请记住,创造商业价值是您的主要目标,因此要避免纯粹的技术项目,这些项目虽然有趣但没有价值。 随着企业从遵循您的愿景中看到越来越多的产量和价值,势头将会增强,变革的步伐也会加快。 在此之前,请继续塑造工作并完善愿景。

建立学习型社区

除了对整体企业架构有一个愿景之外,EA 还负责以正确的技能和实践来执行该愿景。 虽然每个开发团队都将培养其成功所需的技能,但在不同团队之间分享最佳技能和实践将有助于每个团队更好地执行,并拥有共同的使命感。 作为团队之间的桥梁,您最适合培养这种社区意识。

建立社区的方式多种多样,从非正式的午餐到第三方培训,不一而足。与其试图确定哪种方式适合您的组织,不如组建一个由技术主管到开发人员组成的技术专家小组,他们对自己的工作充满热情,并让他们提供帮助。让团队定期开会以计划活动。确保留出一些时间让开发团队分享他们所学到的知识——包括成功的经验和失败的教训。有机会与整个 IT 组织分享将开始建立社区意识,从而形成一个健康的组织。

避免强迫人们参加培训和学习活动。让这些活动对所有人开放,但可以选择参加。不感兴趣的人会通过捣乱或表现出无聊来分散注意力,从而打击演讲者的积极性。那些充满热情的人会欢迎学习和成长的机会;而那些不感兴趣的人则不会从强制参加中受益。

社区意识和学习机会将激励开发人员并促进留存。通过领导社区的核心,您可以根据您对组织未来的愿景来指导组织的发展。允许其他人参与此指导将从内部识别和培养领导力。强烈的自豪感和社区意识将带来更高的质量和更多的协作。

一步一个脚印

改变既不容易也不快。转向一套新的实践需要时间和精力,但最终将是值得的。当您的团队共同创造价值,并且企业将 IT 视为合作伙伴而不是负担时,这一切都将是值得的。请记住,要在精益企业中成为一名企业架构师,就要在开发团队和业务部门之间建立关系。创建一个愿景并引导开发朝着这个愿景前进。要广博,不要深奥。帮助开发人员进行自我投资。明智地进行实验。最重要的是,享受乐趣,学习新事物,创造价值,并将您的组织转变为行业领先的创新者。


重大修订

2015 年 11 月 30 日:首次发布