从优先事项和部署到制定计划
许多技术架构师专注于瀑布方法，在规划技术架构改进工作时，以甘特图式的风格处置时间表，将工作路线图视为最重要的东西。
许多技术架构师沉浸在瀑布方法中，在规划技术架构改进时，将用甘特图式的时间轴视图绘制的路线图，作为规划技术架构改进时最重要的工件。
但路线图是瀑布思维的遗留产物。在最高优先级的部署计划顺利进行之前，规划超出最高优先级的平台或业务功能之外的技术架构几乎没有意义。正如我们在敏捷应用程序开发中所学到的那样，一个过早制定的计划在开始实施之前就已经过时了。
通过灵活处理待办工作的方式来管理技术架构规划，会远优于传统经典的路线图方式。
这种方法有两种版本：平台驱动的架构和业务功能驱动的架构。第一种是平台堆栈取代了待办工作中的敏捷“用户故事”。第二种是围绕业务功能来构建“用户故事”的待办需求。
平台驱动的架构调整：使用这种方法，无论是基于上述的优先级方式，还是基于一些更适合自己企业的替代方案，通常都需要选择一个平台组件。无论基于哪种方式，规划人员都会去寻找平台级的涟漪效应(其他受影响的堆栈)和应用层的涟漪效应(能利用受影响堆栈的一些应用程序)。
在实施最高优先级平台部署的过程中，技术架构师将在剩余的待办工作事项中审查当前平台里的用户故事的优先级，并在适当的情况下对其进行修改以适应不断变化的环境，然后开始为下一个最高优先级用户故事制定计划。
业务功能驱动的体系结构更改：在业务功能驱动的架构更改的工作中，尽管相关性并不能证明因果关系，但在业务和应用程序运行状况评分都很低的功能中寻找造成业务流程瓶颈的应用程序是很合理的。
从技术架构的角度来看，业务功能驱动的变更是从配置具有最高优先级业务功能的核心应用程序开始，然后再延伸至附属应用程序。
同时，公司的业务架构师将合作设计和实施由应用程序调整来实现的流程改进。
与平台驱动的变更一样，在部署具有最高优先级业务功能的应用程序过程中，技术架构师将进行审查，在适当的情况下，会调整待办工作事项的优先级，并开始规划下一个最高优先事项的用户故事。
结论
这些知识够用了吗?
技术架构很复杂，他们必须如此处理，因为如果你曾经尝试过记录业务中所有发生的事情，以便IT能够进行设计、构建、销售、配送和支持其产品和服务，那么你就会知道业务工作很复杂。
顺便说一句，这就是你的BCM所做的事情。仅在前三个 BCM 层就列出几百个业务流程和实践的情况并不少见。同样，你那些映射到 BCM的应用程序清单数量达到一千个或更多也很平常。
记录你所有的资产和规划改进工作的过程，既耗时又费钱。
但这没关系，因为如果不记录你的所有资产和规划必要的改进工作，最终会耗费更多的时间和成本。
当你面临选择是现在去做，还是以后再做时，你应该清楚的一件事，那就是以后再做将会更糟糕。
作者：Bob Lewis ，专栏作家
原文网址：
http://www.cio.com/article/3640510/the-secret-art-of-technical-architecture-improvement.html
原文链接：https://mp.weixin.qq.com/s/ChJp-t7wNgZIvPLP7x4Nxg