客户天天打电话要修改产品功能，简单的一个需求可能要做一个月。产品越改越笨重，为了赶工期bug越来越多。头疼！
产品从初级版到现在已经四个年头，相关的程序员来去换了三批，在补丁上打补丁是常有的事，很多功能只是开了个头，换个项目经理就被遗忘。我们总是害怕客户在这个产品上提出新的需求，只要客户还用得过去，能不改就不改。即使到了非改不可的地步，也会容忍这些僵化的代码带来的种种限制。
昨天才刚上的功能，忽然又要去掉。客户在使用产品中的这些流程，难道事先就没有人考虑到么？现在说这个功能重要，又说要做各种的接口和延展，需求积压到这个程度，对不起！代码已经改不动了。
出来混，早晚是要还的。
在初期，我们的客户并不了解信息化可以为他带来什么、改变什么。随着时间的推移，企业信息化层层深入，甚至已经演变成企业在市场竞争中的利器，逆转的情况就出现了。企业客户的业务流程从之前的顺应软件，逐步的变为让软件去顺应该企业的发展。于是同一款软件的客户们提出了各种个性化的需求，加功能、改流程、维护优化等等。
那么，我们如何避免这些头疼的问题出现呢？
这些问题出现的根本原因是商业软件的设计与开发方式已经不符合企业信息化的发展要求。现在市面上大多数软件，是几个程序员凭自己对业务的理解，把各种功能拼凑起来成的，在初期这些软件因为弥补了空白，企业确实看到了收获，随着项目的推进和新需求源源不断的产生，系统的维护压力越来越大，而且软件中的业务流程与企业发展过程中的现实流程开始产生偏差，于是软件为了迎合企业信息化的要求不断的修改，最后软件越来越笨重，导致很多新的业务流程无法实现，代码已经改不动了，所以这套所谓企业信息化的系统能解决的大部分是固定程式的业务，企业信息化进入纠结期。
但是，企业已经尝到了信息化的甜头，在强大市场利益的驱动下，越来越多的软件厂商并不一味的纠结下去，开始推出所谓的“客户化”，即以客户为导向，收集客户的需求，搭建业务框架之后再开始编写代码。这种理念并没有被快速的模仿，因为所谓的“客户化”往往把软件厂商弄得筋疲力尽，软件业是个靠大量复制用户而生存的行业，要做到真正的个性化服务需要承担的成本将非常大。所以这种“客户化”的理念，还只是技术架构层面的范畴。
最近在“客户化”的基础上，提出了“业务基础架构平台软件”
按计世资讯的定义：业务架构平台软件是指以业务导向和驱动的、可快速构建应用软件的平台。其包括集成应用平台、开发体系两个部分。从技术角度分析，该平台软件为复杂应用软件系统的开发提供了一个基本框架，并有与之相应的、方便易用的开发与维护管理工具。这个框架给出了一些复杂应用软件的基本组成部分和实现方法，并且预置了很多供参考的软件模块。有了这样的准备，在业务基础架构平台软件之上开发管理软件就可以降低复杂性，省去很多基础性的研发工作，从而大大缩短研发周期，提高研发效率。
这种“业务架构平台软件”其实就是功能模块形式下的“客户化”。通过客户的业务基础框架，软件会有很多模块化的功能和可扩展接口，一方面客户可根据自身的业务特点从模块化的功能池子中选择需要的功能；另一方面，当池子中的功能还不能满足客户需求时，通过模块化的扩展接口，程序员可以在基础平台上迅速的开发新的功能。举个大家熟知的例子：WordPress这款博客软件正是这种“业务基础架构平台软件”的典型，一方面提供很多栏目模块和功能供博主选择，并且提供自定义；另一方面，因为这是一个开源的平台，所以会有各种各样的应用被迅速的兼容进来。我们的软件不需要向客户开源，不奢望客户参与开发，但是如果这个平台有良好的业务架构和技术架构，软件的项目团队在做功能增加和修改的时候只要模块化就行。于是，业务架构和技术架构被放到同一个高度上来，避免出现开发过程以技术架构为主，业务架构为辅，业务进行架构设计之前过早的进行大规模的代码编写。
以上一直在强调模块化，这是“业务架构平台软件”的关键所在，但是这个模块化，现今还处在摸索阶段，三百六十行，每一行的业务流程都不同，但是我们通过大量的流程对比，是能够发现一些规律的，这些规律的组合就形成了模块。《业务架构和应用架构》这篇文章的作者无处查找，但是其中有一段话对业务架构的模块化说明值得借鉴：“初看架构这个词容易理解为静态的事物，但是广义的业务架构一定是静态和动态分析的集成和融合，在分析过程中相互影响又相互促进。动态的信息即我们说的普通的价值链分析的思路，从企业端到端的一级流程到各个业务领域二级，三级等流程的分析。形成一级流程->子流程->活动->活动单元->任务->事件的主线；而对于静态信息则包括组织，人员，岗位，角色，业务对象和表单，规程，模板等各种信息。静态信息的重点是业务领域和业务对象，即形成业务领域->业务主题域->业务模块->业务单元->业务组件的静态数据逐层分解。静态信息+动态信息+交互点和接口分析后形成完整的业务架构。可以看到流程再细粒度分解后的活动单元的组合可能形成业务组件和业务模块，同时业务模块本身又存在更细粒度的流程和活动分解，业务组件本身又是多个流程的组成部分，因此静态和动态相互融合，形成交互，所以必须分析交互和接口。”
除去以上这些，业务架构和技术架构下的模块化平台软件还具有以下特质：
1、 以用户为中心
用户将成为信息化的主导，他们不用去考虑技术如何实现，只需要了解自身业务流程，只需要利用模块池中的功能组装成符合自身需要的目标软件即可。这样用户可以彻底改变以前信息化过程中的被动地位，从而有效保证软件和需求二者之间的平衡。
2、 敏捷开发
因为具备模块化的接口和延展性，所以程序员不需用从零开始逐步开发，只要利用原有的模块为基础进行开发。
3、 集大成
说到功能池的概念，这种软件必将是一个集成了多种系统的平台，它就像PC主板一样，会有很多插槽，无论你要建立什么样的管理系统，这些功能都将轻松整合在一起。
4、 生命周期很长
因为建立了业务架构和技术架构协调一体的机制，所以其生存的根本就在于能够顺应企业的发展，通过敏捷开发的方式来实现软件的生命周期模型。这些因素都有效地驱动了软件的持续完善，从根本上保证了管理软件和企业发展的动态平衡关系，使软件具备较长的生命周期。
在业务架构和技术架构协调一体的同时，渐渐发现，因为企业的应用越来越多，企业应用的多样性、复杂性以及它们直接相互关联交互的需求增强，已经越来越多的企业从应用层上升到了数据层，如果还是像传统软件一样，将数据存储在系统文件中，那么这个所谓模块化的“业务基础架构软件”仍然无法发挥他的威力。
这时候就应该将信息系统架构提到业务架构和技术架构的高度，协同解决。我们称之为“业务架构、信息架构、技术架构三位一体”
很荣幸，从2009年开始，我主导了一款餐饮行业应用软件的设计和规划工作。这一年半的时间里，在项目组摸索寻找这种一体化的工作方法。其实并不是三种架构都在同一个地方等你，而是走着走着发现问题，然后一个一个的捡起来，最后发现其实一开始三者是可以结合成一体的。
在信息架构中，我们不仅将企业数据存储到数据库中，而且将这一数据库存储到统一的服务器中，作为数据层开放。采用C/S结构，让客户和服务器实时交互，系统记录客户的操作数据，通过对这些数据的分析归纳，做出行业通用的业务模型。客户通过与服务器的链接，可以任意的在功能池子中选择自己需要的模块。
IBM在介绍其DB2pureXML时曾经提到：“由于这种开放的服务特性，这类核心信息在服务各种业务的过程中必然需要考虑很大的差异性和复杂性，必然需要把数据的存储和数据的访问隔离。数据的差异性和复杂性将对数据模型的灵活性和可扩展性提出更高的要求，而数据的访问和底层存储的隔离，将直接导致未来越来越多的应用通过XML的服务接口获取信息而非用SQL直接访问底层数据库表。”
是的，这正是saas成为行业趋势的原因，软件应该是“软性”的，它能够顺应企业发展的需求，而不应该让企业去顺应软件。业务架构、信息架构、技术架构也正是saas的精髓所在。
今天玩把概念，个人一些零星的观点不成体系，仅作抛砖引玉。感谢大家百忙中的阅读！