从优先级排序和部署到规划很多技术架构师在规划技术架构改进工作时，专注于瀑布方法，以甘特式风格处理时间线，将工作路线图视为重中之重。许多技术架构师沉浸在瀑布方法中。在规划技术架构的改进时，以甘特图的时间线视图绘制的路线图被视为规划技术架构改进时最重要的神器。但是路线图是瀑布思维的遗产。在最高优先级的部署计划顺利进行之前，规划超出最高优先级平台或业务功能的技术架构毫无意义。正如我们在敏捷应用程序开发中了解到的那样，过早制定的计划在实施开始之前就已经过时了。通过灵活处理待办事项来管理技术架构规划，远优于传统的经典路线图方法。这种方法有两个版本：平台驱动架构和业务功能驱动架构。首先是平台堆栈取代了积压中的敏捷“用户故事”。二是围绕业务功能构建“用户故事”待办需求。Platform-DrivenArchitectureAlignment：使用这种方法，无论是基于上面描述的优先级排序方法，还是基于一些更适合自己企业的替代方法，通常都需要选择一个平台组件。无论哪种方式，规划人员都会寻找平台级连锁反应（其他受影响的堆栈）和应用程序级连锁反应（一些可以利用受影响堆栈的应用程序）。在实施最高优先级平台部署的过程中，技术架构师会在剩余的backlog中回顾当前平台用户故事的优先级，并酌情修改以适应不断变化的环境，并开始规划下一个最高优先级的用户故事。业务功能驱动的架构变更：在业务功能驱动的架构变更工作中，寻找在业务和应用程序健康评分较低的功能中造成业务流程瓶颈的应用程序，尽管相关性并不能证明因果关系该过程是非常合理的。从技术架构的角度来看，业务功能驱动的变化从配置具有最高优先级业务功能的核心应用开始，然后扩展到卫星应用。同时，公司的业务架构师将协作设计和实施通过应用程序调优实现的流程改进。对于平台驱动的变更，在部署具有最高优先级业务功能的应用程序期间，技术架构师将审查并在适当时调整积压的优先级，并开始规划下一个最高优先级。优先用户故事。结论这些知识足够了吗？技术架构很复杂而且必须如此，因为如果您曾经尝试记录业务中发生的一切，以便IT可以设计、构建、销售、运输和支持其产品和服务，那么您就会知道业务正常很复杂。顺便说一下，这就是您的BCM所做的。仅在前三个BCM层中列出数百个业务流程和实践的情况并不少见。同样，将一千个或更多应用程序清单映射到BCM的情况并不少见。记录所有资产和规划改进工作的过程既耗时又昂贵。但这没关系，因为不记录您的所有资产并规划必要的改进最终会花费您更多的时间和金钱。当你面临是现在做还是以后做的选择时，你应该知道的一件事是，如果你以后再做，情况会更糟。作者：BobLewis，专栏作家原文网址：http://www.cio.com/article/3640510/the-secret-art-of-technical-architecture-improvement.html
