作为一名企业架构师,当自己的组织开始向精益或者敏捷实践转变的时候,很有可能会感觉到一些失落。在转变之前,你经过了非常努力的工作才达到了架构师的位置,你可能编写了保持企业运行所需的大部分关键系统软件,帮助实现、甚至是设计了整个架构。你知道架构中的哪些地方使用了比较老的技术,哪些地方比较脆弱,但是由于没有资源和时间去改变而不得不对现实妥协。同时,由于只有你知道如何保持事情运转,所以很多事情不得不亲力亲为,导致自己没有精力去研究探索最新的趋势。而为了提升时间的利用效率,你制定了统一的标准,并且尝试着在架构评审或计划会议上控制需求。但是开发人员由于不清楚公司良好运转的条件,对每天重复的老套工作和繁琐流程充满了抱怨,使得你不得不加强政策从而尽量保持控制。

现在,新的领导或者咨询公司来了,他们声称组织应当“变得敏捷”。对此,开发者的理解是,敏捷和灵活性允许他们做自己想做的任何事情。于是,他们开始将你看作是陈旧事物的代表,开始颠覆或者忽略你。他们引入了可能会破坏基础设施稳定性或者可能会在关键时刻引发系统故障的实践和技术。虽然你清楚组织依然需要你,但是却感觉每一个人都在和自己做对。

事实上,他们可能比以往任何时候都更加需要你。需要你的知识和经验将风险和管理成本最小化,将技术任务与业务对齐。只不过虽然任务还是那些任务,但实现方式与之前相比有一点不同。因为无论是精益还是敏捷,它们都关注于价值创建、成本缩减和快速反馈,因此,如果想在新环境中取得成功那么你必须接受一些新的实践。例如,共享简单的愿景、建立桥梁、对齐业务、提供指导等所有可以促进创新的努力。

那么如何实现这种转变呢?总体来看,企业架构师和其团队需要从传统的实践中进行转变。架构师将成为信息的影响者和聚合者,同时也是信息的传播者,其角色定位不再是自己做决定,而是帮助其他人做出正确的决定。而要实现这一目标需要一些新的工具和技术。下面将会介绍一些关于如何扮演好这一新角色的途径,虽然想法比较高层,并非适合所有的组织,但是每个组织的目标是灵活的,通过技术实验和效果衡量,团队可以从中选择适合自己的,舍弃不适合的。

拥有并共享同一个愿景

保持一致性的第一步,也是非常重要的一步,就是让整个组织拥有一个长期的目标。想清楚当前和将来的架构是让项目保持协调一致的关键。应该从评估现在的架构开始,找出目前都有哪些系统,它们的作用是什么?这一步不需要深入详细的描述,也不用找到它们都部署在哪台服务器上,只需要理清楚应用程序和产品以及它们之间的关系即可。整个架构可能分很多层。如果是大型组织,那就先将问题分解成功能区,然后再一个个的找出来。如果有基础的架构模式或者策略,那就识别出来,看看哪些地方遵循该模式,哪些地方没有。例如,如果组织采用的是面向服务的架构,那就看看哪些应用程序基于该架构直接访问主数据?它们如何与常用的数据库通信?

在搞清楚系统当前的状态之后,接下来就需要考虑清楚将来的架构是什么样子。是否应该保留与现在一样的基础架构?完全采用全新的架构是否会更好?当前架构有哪些优势和劣势?如果要演化当前的架构,那就创建一张架构更新图,在图上将变化的部分与保留的部分区分开。如果整体架构的变化是必要的,那就要清楚理想情况下最终状态是什么样。要记住,这是一个比较长远的、需要技术组的其他人遵循的愿景。

有了愿景之后,还需要确保组织中的技术领导者能够理解它。这就需要向关键的开发者介绍愿景,获取他们的反馈。通常,他们比你更清楚某些事情的来龙去脉,也更能帮助你更好地理解架构。你需要愿意并且渴望基于这些反馈调整愿景。如果要对整体架构或者某个特定区域做出革命性的改变,尽量让团队认可这种转变,因为这会让愿景更容易实现。尽量不要让架构成为一种任务,而应该将其看做是一种能够让开发团队建立共识的工具。要让开发团队成为你的合作者或者同盟。因为他们积极地参与远比完全按照自己的想法推进愿景更有价值。

在达成某种程度的共识之后,一定要让所有人都知道当前的架构和将来的架构分别是什么样子。这并不是说要将它们放到磁盘上的某个文件夹、SharePoint网站或者Wiki上,而是要制作海报或者一整面墙的涂鸦,在很多地方展示它们,确保每个人都能够了解该愿景,并激励他们不断地向该目标努力。在架构演进的过程中,这些图画也需要随之改变以反映当前的工作进展。要展示出那些正在提升的地方并认可为之付出的团队。如果其他人对一起构建伟大架构的工作感到自豪,那么他们就会支持你的工作。

建立桥梁

有了愿景之后,你就想它成为现实。但是既然你或者你的团队并不开发或者管理项目,这又如何实现呢?最好的方法就是成为开发团队的合作者和资源。你的目标并不是限制或者阻碍工作的进展,而是促进它。当某个团队开始开发的时候,与他们的技术经理和项目经理沟通,向他们展示更新后的企业架构图,讨论如何让他们的项目实现这一愿景。通常情况下,团队从事的工作与企业正在进行或者已完成的项目相似。架构师应该确保团队负责人了解这些项目,以便于能够在实际的代码和产品中利用共享的经验。尽量不要关注实现细节,不要关心使用的类库及其版本,要关注高层目标和项目设计以及它们与整体愿景的对齐方法。