项目的启动，标志着企业开始正式向一个架构活动投入各种资源。这是架构活动中极具里程碑意义的一个节点。

项目启动的真正目的，是让所有参与方完成一次有约束效应的目标与任务确认。

在进入项目启动之前，你跟各个参与方仅仅达成了合作备忘录。这是在口头上达成的约定，没有较强的约束性，因而我们还需要与各方正式“签约”，生成最终版“交付合同”。也就是说，通过项目启动会把合同的内容广而告之，参与者也都会公开支持合同，并认领交付项目。在此之后，签约正式生效，所有参与者都要对这个虚拟合同中的任务条款负责（Commitment）。

不过“签约”之后，不是说自此之后再也不能更改这个合同中的条款了。而是指有了承诺，任何参与者都不能单方面更改条款，需要通过一个确定的流程才能更改。

在互联网时代，项目启动环节的王道是以终为始，公开架构活动的明确目标，以清晰的语义阐述参与者的责任、权利和架构环境，保障参与者对目标的全力投入。那么架构师，就需要设立保障机制，来保障这个合同是真实有效的，从而最大程度地提升架构活动的成功概率。

在项目启动之前，架构师需要跟项目经理一同来做一些准备工作，主要有如下四个方面。

  1. 资源环境：确认并锁定运营资源、产品资源、技术资源和数据资源。
  2. 架构环境：将之前搭建的架构环境，尤其是架构信条的细节，整理成完整的线上文档，并共享给其他参与者。
  3. 架构文档：完成整体的架构规划，初步完成不同领域的细节规划文档。
  4. 重大风险：梳理好整体和各个领域的风险，完成已知的重大风险预案。

在准备的过程中，会发现架构活动可能还面临着一系列的挑战，主要有如下六个方面。

  1. 缺乏问题升级机制和冲突解决机制：在互联网这种舍命狂奔的状态之下，缺乏这种机制的架构项目，注定会在众目睽睽之下以崩塌收场。
  2. 缺失技术细节：多数沟通停留在口头，设计文档不存在或者不完整；核心领域和强依赖中有大量仍处在争议状态的设计评审结论。
  3. 架构方案互相冲突：整体的架构方案，跟一个或者多个细分领域的架构方案有冲突。
  4. 隐藏的技术风险：多数互联网公司不怎么区分大项目和日常需求，导致对大项目的技术风险评估过于简单和乐观。而这些大的项目，可能会因为系统复杂度高而导致失败。
  5. 资源不确定：某几个领域的资源无法保障 100% 的投入，只表示“尽力而为”。
  6. 边界模糊：部分执行团队之间的任务边界模糊，这也是第 26 讲提到的任务边界划分尚未完成的情况。

作为架构师，我们可以从技术视角解决前四个挑战。而后两个挑战，则要依靠项目经理来推动完成。

根据这四个挑战，架构师需要完成的任务项依次是：架构方案的正确性验证，技术交付内容的正式确认，重大风险解除，以及预警机制建设。