网站架构师的工作内容( 从优先事项和部署到制定计划许多技术架构师专注于瀑布方法)

　　网站架构师的工作内容(

从优先事项和部署到制定计划许多技术架构师专注于瀑布方法)

　　从优先级和部署到规划

　　许多技术架构师专注于瀑布方法，以甘特风格处理时间线，在规划技术架构改进工作时，工作路线图是最重要的事情。

　　许多技术架构师都沉浸在瀑布方法中，并在规划技术架构改进时将路线图的甘特式时间线视图作为最重要的工件。

　　但路线图是瀑布思维的遗产。在最高优先级的部署计划顺利进行之前，除了最高优先级的平台或业务功能之外，规划技术架构几乎没有意义。正如我们在敏捷应用程序开发中了解到的那样，过早创建的计划在实施开始之前就已经过时了。

　　以灵活的方式通过待办事项管理技术架构规划远远优于传统的经典路线图方法。

　　这种方法有两个版本：平台驱动架构和业务功能驱动架构。首先是平台堆栈取代了积压中的敏捷“用户故事”。第二个是围绕业务功能构建“用户故事”的积压。

　　平台驱动架构调整：使用这种方法，无论是基于上述优先级的方法，还是基于一些更适合您业务的替代方案，您通常需要选择一个平台组件。无论哪种方式，规划者都会寻找平台级涟漪（其他受影响的堆栈）和应用程序级涟漪（一些可以利用受影响堆栈的应用程序）。

　　在执行最高优先级平台部署的过程中，技术架构师会在剩余积压中审核当前平台中用户故事的优先级，并酌情修改以适应不断变化的环境，并开始规划下一个最高优先级用户故事。

　　业务能力驱动的架构更改：在业务能力驱动的架构更改工作中，寻找导致业务流程瓶颈的应用程序在业务和应用程序健康评分较低的功能中，尽管相关性并不能证明因果关系。该过程非常合理。

　　从技术架构的角度来看，业务功能驱动的变革从配置具有最高优先级业务功能的核心应用程序开始，然后扩展到卫星应用程序。

　　同时，公司的业务架构师将协作设计和实施通过应用程序调整实现的流程改进。

　　与平台驱动的更改一样，在部署具有最高优先级业务功能的应用程序期间，技术架构师将审查并在适当的情况下调整积压的优先级，并开始规划下一个最高优先级。优先级的用户故事。

　　综上所述

　　这些知识够吗？

　　技术架构很复杂，必须以这种方式处理，因为如果您曾经尝试记录业务中发生的所有事情，以便 IT 可以设计、构建、销售、运输和支持其产品和服务，那么您就知道业务工作非常复杂。

　　顺便说一句，这就是您的 BCM 所做的。仅在前三个 BCM 层中列出数百个业务流程和实践并不少见。同样，将一千个或更多应用程序清单映射到 BCM 并不少见。

　　记录所有资产和计划改进工作的过程既耗时又昂贵。

　　但这没关系，因为不记录所有资产并规划必要的改进最终会花费更多的时间和成本。

　　当您面临现在做或以后做之间的选择时，您应该注意的一件事是，以后做会更糟。