用新技术突破“怎么做”，进而推动“做什么”
这种方式就是我们最常说的“技术驱动”。利用更新、更快、更稳定的技术，创新业务的实现方式，从而推动业务的发展、创新和颠覆。
最著名、最具颠覆性的创新，大概当属移动支付。本质上，它只是利用移动互联网、NFC等技术，提供了一种新的支付方式。然而对“怎样付钱”的创新，催生出了余额宝、网约车、团购、外卖、共享单车等等一系列全新的、颠覆性的业务或行业。
不过，这种“技术驱动”模式并不适合于“业务驱动”的业务、公司或行业。在“业务驱动”下，“做什么”的业务需求是“主动轮”，而“怎么做”往往只能担当“从动轮”。也就是说，技术必须以满足业务需求为先，而将技术上的创新、突破则变得无关紧要、可有可无，更别谈驱动业务了。
那么，在“业务驱动”模式下，技术就无法反客为主了么？不，有办法。
“业务驱动”下的“技术驱动”
理解业务
任何一项创新，都必须建立在对旧事物了如指掌的基础上。技术想要驱动业务，也必须通过全面、深入的理解业务来构建地基，才能万丈高楼平地起。
当然，技术人员理解业务，与产品人员一定会有不同，也一定要有不同。产品人员从业务的最终结果和表现上来理解业务，技术人员从内部结构、组织和实现方式上来理解。例如，产品人员理解的业务是“一个审批流程”，技术人员的理解则是“状态模式”、“工作流”；产品人员理解的是对某个渠道做某个处理、对另一个渠道做另一种处理，技术人员则会将其理解为策略模式。
从这两个例子上可以看到，设计模式是一种理解业务的不错的方式。设计模式本身就是用于“处理某一类业务问题/场景”的方法，很自然的有助于我们理解业务。此外，不少的技术架构，如工作流、权限、SSO等，也能够为我们理解业务提供帮助。
以账务系统为例，账务系统主要包含记账、业务数据维护、账务金额计算三项功能。其中以记账业务为核心，记账业务中又以还款功能为核心。技术人员梳理后，将还款功能理解为一套状态机。除了还款业务外，账务系统中还有繁多的记账业务；技术人员进行梳理后，将这些业务梳理为一套策略模式加工厂模式。类似这种梳理工作，就是技术人员理解业务的过程。
搭建高扩展性的基础架构
在理解业务的基础上，搭建出一套适合当前业务需求、以及未来业务发展的架构，这是技术真正开始驱动业务的第一步。
“业务驱动”的一大特点，就是业务需求在不断的变化。面对这种情况，如果技术实现也不断的随之变化，那么技术、技术人员一定会疲于应付——这种困境我们已经遭遇了太多了。
高扩展性的基础架构，能够在不断变化的业务需求面前，保持技术实现的相对稳定性，从而，一方面提高业务需求的实现效率，使得业务需求及其变化能够尽快的付诸实践；另一方面，也可以减少技术的债务和负担，从而有更多的资源来思考和实践“技术如何驱动业务”。
账务系统目前就走到了这一步。账务系统的架构并没有使用多么高上大的技术，但是它拥有足够的扩展性。我们组合了策略、工厂、模板和状态等种种模式，使得账务系统的实现非常的灵活，从而可以比过去更少的投入来做业务需求，而产出（工期、质量）上仍与以前一致、甚至更好。以最近的房贷需求为例，无论一期还是二期，我们都能够在一周以内开发完成，并保证上线后不出现bug。这样，我们就能够拿出比以往更多的资源，投入到进一步的技术优化上。
构建完备的领域模型
“高扩展性的基础架构”只是第一步。只有构建起了领域模型，技术才能够真正开始“驱动”业务。而只有完备的领域模型，才能够全面、深入地刻画出业务的本质属性。
领域模型实际上是“理解业务”与“技术架构”结合后的产物。只有充分理解了业务，才有可能构建起一套领域模型；而只有合理的技术架构才能够把业务完备的表达和实现出来。
例如账务系统的两套生命周期图，是在系统梳理过程中理解业务的基础上，结合此前搭建账务系统基础架构时的经验，最后总结出来的。这两套生命周期图，加上它们的实现代码，比较完整的刻画出了账务系统的业务逻辑，并且也指出了账务系统内的数据关联。在这两张图的帮助下，我们能够判断产品人员提出的需求是否合理、是否完整，也能够清楚的知道我们需要对系统的哪些功能做出哪些改动。可以说，我们已经不用被产品牵着鼻子走了。
突破模型、创新业务
构建领域模型的目的，不仅仅是描述现有业务、容纳新的业务。更重要的是，它勾勒出了已知业务的“边界”。而只有知道“边界”在哪里，才知道创新的“束缚”和目标在哪里，才能够有的放矢，完成业务上的突破和创新。
在账务系统中，目前我们能够确认的创新点，主要是还款计划表计算逻辑以及还款计划表状态变更这两方面。还款计划表计算逻辑上，我们目前只有等额本息、先息后本两种基本算法；但还可以提供新的（如等额本金）算法。在提前还款、部分提前还款功能上，目前必须提前一个月申请，申请后才能还款；但我们还可以提供更加灵活、方便的提前还款功能。等等。 虽然我们现在还没能真正实现这些突破和创新，但这是我的梦想和方向：用技术驱动业务的发展和创新。