此时架构师、产品经理或需求分析师等人员利用自己的经验能力，对系统的业务需求进行分析、拆解、抽象，形成业务文档和技术文档，以及技术验证代码等。
这个阶段，架构设计工作是重中之重，其中包括：
系统分拆：如何把系统拆解为不同的子系统、模块、业务单元；
技术选型：使用什么样的基础技术框架或脚手架；
技术验证：确定核心技术难点如何解决，检验能否满足期望指标；
接口规范：系统的内部不同部分以何种形式确定接口契约和数据通信；
集成方式：系统与外部其他业务系统如何进行集成；
技术规范：如何规范开发、测试、部署和运维的技术标准性；
部署方案：系统如何进行物理部署，需要多少机器、什么配置，对网络有什么要求；
运维方案：系统如何进行技术性运维，如何日常监控、预警报警；
……
这个阶段总结一下就是：业务为要，架构先行（包括业务架构和技术架构）。
实现期
这个阶段主要是编码与测试，准备部署上线，是软件从代码到最终的生产系统的过程，我们可以称之为代码形态。此阶段需要考虑的技术类工作包括：
确保各项技术规范和技术指标的执行落地，保障高质量的代码；
指导研发人员和解决各类技术问题，提升研发团队效率；
制定测试的技术性方案和基准，自动化、性能、安全等；
配合准备部署环境，运维实施方案落地等。
运行期
这个阶段系统上线、验收通过，已经初步稳定，然后进入维护阶段，成为了设计期架构设计草图的一个可用实例，我们可以称之为实例形态。此时需要考虑：
发布上线相关基础性工作，包括是否使用持续集成（CI)、自动化发布等技术；
运维基础性工作，自动化运维，监控等相关技术。
架构的形式与特点设计文档和代码
我们一般说的架构既包括架构的设计过程，也包括设计的产出物，一般可以包括各类设计文档、设计图，也可以包括一些技术验证代码、Demo 或者其他相关程序。
文档的目的在于准确记录我们的思维产物，在软件尚未实现时，作为指导蓝图，尽量精确的描述清楚软件。
在软件的实现过程中，可能随时随着我们的深入研究，根据具体情况对文档做出局部的一些调整和修改。
文档作为结项或交接的一部分，也是整个软件项目的产出物的一部分，成为公司 IT 资产的有机组成部分。
架构服务于业务
正如 19 世纪的伟大建筑师路易斯•沙利文（Louis Sullivan）倡导的建筑设计著名格言：“功能决定形式（Form follows function）”。
软件架构首先是要服务于业务功能的。
架构影响研发团队的组织形式
业务拆分的方法和技术框架的选择必然会影响到研发团队的组织形式。