1. 业务架构
在需求初期，业务的需求描述往往比较模糊，可能只是一句话。他们可能来自老板、运营或者用户。直接把这句话作为核心产品功能是不恰当的，合理的做法是先把这个产品所有的问题域列清楚。
问题域，是指自己的产品能够解决的所有问题的空间集合。从核心需求出发，将所有当前需要解决、未来可能要解决的问题放入产品框架的范围。能够帮助我们的产品拥有更高的可拓展性，在后续具备迭代和优化的空间。
在经过问题域的罗列后，我们应该能够得到一个模糊的产品方向和功能范围。把这些问题域的答案抽象总结成一个确定的产品需求。根据核心需求和问题域的答案，梳理出业务流程。
业务架构就是在业务需求初期，将模糊的需求描述转变成清晰的问题域，梳理出清晰的业务流程。为产品架构提供输入。
业务架构包括业务规划、业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往是空中楼阁。
业务架构必须与其面向的实际应用场景相匹配，由于每个产品或项目的业务场景均有所不同，所以每次做新的软件开发前，必须设计软件架构。试图不经分析直接套用先前的架构方案，十有八九会让当前的系统在某个点上报出大问题导致推翻重建，更不要说直接拿别人的现成架构方案了。例如，A 业务中有套 A 系统，恰巧 B 业务需要解决类似 A 业务的场景。此时很多情况，B 业务的人员会考虑把 A 系统直接拿过来，以为做一些简单的修改，就能在 B 业务中落地。结果在系统落地的过程中，很多功能模块不能直接使用，都要重新按照业务进行修改。最终的结果是，A 系统经过不断的重写修改变成了 B 系统。
上述的案例正是由于业务架构没有做到位，没有做好软件架构的分析和设计，所以我们很难看出两个系统有多少差别，也无法确定用一个业务系统去覆盖另一个业务系统的可行性有多大。相反，对 A 和 B 业务领域进行业务架构梳理，我们就能清楚发现两者的一致与区别，就能有效的评估系统覆盖的可行性和合理性。
经过业务架构阶段之后，需要输出的产物包括：企业战略方向图、问题域列表、业务流程图。