敏捷可以解决了开发模式的官僚问题，从行动角度应对用户业务需求的变化；
构架可以从设计角度应对业务需求的变化问题，甚至在需求调研阶段，能解决需求的收集和确认。
需求的变化，一般可以从3个领域发生，界面、流程和规则、组织结构和权限。
界面问题一般表现在界面的元素发生改变，如一个订单，原来有几项，关联了一些子表。现在要多加几项，修改其中几项，还要加入一个新的关联，等等
流程问题一般表现在一个界面的提交后，可能要跳到一个特定的界面。现在要跳转到另外一个界面，并且有一些新的规则；或者这个用户跳转到这个界面，那个用户跳转到另外的界面；或者根据界面上的某个输入，大于某个条件，就跳到这个界面，小于某个条件，就跳到另外界面。
规则问题有很多包含在流程问题中，但是有些是单独的规则问题。如这个输入框必须输入，这个输入框必须大于多少。规则的变化会改变这些。
组织结构变化更是非常频繁，建立新部门，增加新成员，成员的调动等；权限的设置有通过组的设置，有通过职务的设置。
变化的源泉是什么呢？业务变化，人员变化，这些都是业务活动必需的，一个信息系统不可能指责业务的变化，而是必须服从业务的变化，否则本末倒置，信息系统会被业务遗弃。
只有适应业务的变化，才是一个信息系统必须要面对的。
那么适应变化，至少可以有2类单独的人可以完成，完成的方法也不同。
第一类是开发人员，第二类是业务人员。
第一类的开发人员的修改是通过在系统源代码基础上，修改代码对业务进行修改。每次业务改动后，都需要业务人员传递给开发人员后，经过开发人员绞尽脑汁的思考后，才能进行修改，并且需要进行测试后才能交给业务人员使用。复杂一点儿的修改可能会涉及到很长的周期。
第二类业务人员的修改可以通过业务修改工具，在业务改动后，业务人员可以通过开发或维护人员进行修改，也可以自行修改，修改后，仅需要业务的测试，而不需要源代码级的编译和测试，所以相应速度要快。
第二类就是我们说的构架带来的敏捷，业务的敏捷是通过业务工具，让业务人员实施的，抛却了中间的开发过程，所以会非常灵活和快捷。
如何实现这样的敏捷构架？
当然可以使用很多商业的构架，但是完全可以通过简单的设计，在自己系统中原生的实现。
一、首先一些系统设计的原则可以使系统更高效
各司其职。各司其职就是要让业务清晰，从业务对象到业务方法、业务规则，可以将业务对象映射到程序对象，从而完成设计过程，只有业务清晰了，才能够变化自如。
一个业务的源头只有1个，就更容易维护、修改、测试，也就越稳定。
如有那些业务，业务之间的关系，业务中的信息和流程、权限，等，有哪些类是固定的，那些类是变化的。
逻辑分开。各司其职的原则可能有很多手段，其中的逻辑分层就是其中一个。
逻辑分层不同于物理分层，物理分层是为了部署和性能等逻辑之外的需求，逻辑分层是为了逻辑的清晰。
如我们要在所有商店都可以使用这个软件，每个店面的店长可以在这个程序中录入最新促销信息，这些促销信息的一部分可能会通过网络传到广告中心进行发布。
这里，录入最新促销信息到数据库，是一个业务需求，而所有商店都可以使用这个软件，保存的信息传输到广告中心发布，属于部署需求；而店长可以录入，则属于规则需求。
当我们建立设计时，一定会将促销信息，使用者，商店，这些要素提取，形成要实现的类，而不去管哪些信息信息传输到广告中心。
对于促销信息中的字段，我们可以放在一个单独字典表中，以备业务变化时可以修改字典进行扩充。
而录入界面，则可以通过模板或界面设计文件进行设计和呈现，当界面变化时，可以修改界面文件达到目的。
这样，业务变化时，我们就可以根据变化种类的不同，找到相应可以变化的部分，修改后，就可以重新运行。
避免了编译系统，带来了直接的效率。但是由于系统会执行解释方式，可能会造成效率的降低。
适应变化，开发要降低效率。
适应变化，系统也要降低效率。
二、构架还可以降低分布系统的开发工作量
分布系统在各个层次要写很多重复代码，而统一业务后，可以节省在各个层次间写多次业务代码或者传递。
属于物理逻辑的层次，其实是为了部署和扩展使用的，他们不属于业务逻辑，所以不需要由开发人员开发，甚至不需要开发代码。
所以，通过设计，可以即实现灵活的部署方式，又减少代码量，实现业务统一。
类似于单机版或C/S构架的开发方式，而分布式的部署方式是最理想的状态。
三、良好的构架设计可以轻松评估工作量和开发时间
由于对于系统分析透彻，对于系统隐含需求更加清晰，所以可以更容易掌握系统的重点，难点和开发量，也更容易在系统前期同客户交流，确定系统需求，避免因为用户考虑不周带来的变化。