业务拆分的越细致，越有利于我们更好的对项目的各项指标量化计算，更精确的估计工时和成本，从而指导我们每个小组应该分配多少资源，使用什么样的协同和任务确认形式。
并且随着项目的推进，计划与实际情况之间的匹配程度也随时可以进一步精确调整，进而影响到我们应该对每一块任务的投入资源进行动态调整。
架构存在于每一个系统
每一个已经实现并运行的系统，都是特定架构设计的载体。
有些系统对应的架构，有详细的设计文档来描述；有些系统的设计文档，残缺不全，甚至还因为在系统的发展变化的同时，文档没有更新，导致设计文档与实际系统不符。
有些系统干脆就没有设计文档。
但是这些系统，都是基于一定的架构来创建的。
每种架构都有特定的架构风格
每种架构方式，每个具体系统内所体现的架构设计，都是可以被工程师们理解，进而提炼出来一些架构思想和设计原则，这些思想和原则就是这种架构方式的风格。
依据这些风格，我们可以将各种架构方式，进行分门别类，从而进一步讨论每种架构风格的特点。
架构需要不断的发展演进
随着计算机软硬件的不断发展，软件架构思想也在不断的发展变化。
另一方面，软件为其提供业务处理和服务能力的每个具体行业领域也在不断发展变化，业务处理流程、参与角色、业务形式不断的推陈出新。
这就要求我们在系统架构设计时，保持终身学习的精神，持续吸收新思想新知识，保持贴近一线业务群体，随时因地制宜，调整架构设计，采取最适合当下场景的解决方案。
架构的目标与方法
明确软件系统架构的一些通用目标，可以使我们更明确如何考虑架构的方向；而了解架构的方法和方法论，则让我们可以知道从哪些角度可以比较全面的描述清楚一个系统的架构设计。
可控性与拆分
对于复杂问题的简化处理，一个简单办法就是分而治之。
按一定的粒度把目标问题进行分解，可以非常有效的提升目标的可控性，使得目标变得更加可以量化、进而优化。
系统按照合适的粒度拆分成不同模块的过程，我们一般称为模块化。模块化也是软件工程化的基础。
在这个基础上才能够实现分工合作。
复用性与抽象
复用性一直是软件设计领域的一个很重要的指标。
复用的一个关键是我们对于现有具体问题的抽象，找到各种不同问题中存在的不变性，进而作为一种通用结构来统一处理。
拆成是把整体变成很多局部，再对局部分开对待和研究其性质。
反过来，我们按照高内聚的指导思想把一些紧密联系的功能聚合后，打包成一个可以整体复用的部分，这就是组件，这个过程就是组件化。
通过组件化，我们可以得到抽象再组合出来很多业务组件。这样，在更大粒度上实现了功能的复用。
非功能性需求九维目标（1）高性能
系统必须满足预期的性能目标，在并发用户数（Concurrent Users）、并发事务数（Transactions per Second，TPS）、吞吐量（Throughout）等指标方面达到预估值，支撑使用人群的正常使用操作。
（2）可靠性
业务系统直接影响到用户的经营和管理，因此必须是可靠的。
（3） 稳定性
软件系统必须是能够在用户的使用周期内长期稳定运行的。这要求系统具有一定的容错能力。
（4）可用性
可用性是指系统在指定时间内的提供服务能力的概率值。我们一般采取集群、分布式等手段提升系统的可用性。
高可用性是目前系统架构设计方面的一个热点。
（5）安全性
用户的业务数据是具有非常高的商业价值，如果被泄露或篡改将会带来重大损失。
安全性是软件系统的一个重要的指标，也是架构设计的一个重要目标。
（6）灵活性
软件系统应该具备满足不同特点的用户群和目标市场的能力，更灵活。
（7）易用性
软件系统必须拥有较好的用户体验，便于用户使用。
（8）可扩展性
业务和技术都在不断的发展变化，软件系统需要随时根据变化扩展改造的能力。
（9）可维护性
软件系统的维护包括修复现有的错误，以及将新的需求和改进添加到已有系统。
因此一个易于维护的系统对于用户提出的问题或改进，可以及时的实现高效的反馈和响应支持，同时有效降低维护成本。
基于这些目标，经常有人说：“架构是系统非功能性需求的解决办法的集合”。
架构的不同风格典型的企业级应用系统或者互联网应用系统一般都是通过 Web 提供一组业务服务能力。