3. 架构的背后
为了实现架构的目标涉及到以下三个方面：技术，组织和过程。这里举例说明。
1) 技术对开发效率和运行性能，以及组织和过程的影响。
案例A.映射的问题。公司产品的一个重要需求是根据客户输入，映射到PDF文件上。技术上整体实现需要四个步骤：在PDF文件上画好所有的数据域，通过读入一个XML映射文件，获得运行数据并生成FDF，合并FDF和PDF生成目标文件。后两步工作都由代码自动化了，因而实现的主要工作在于前两步。
在第一个实现版本里，XML映射文件的DTD太简单，致使一个xml文件至少在4000行左右，同时xml文件太verbose了。这样的结果直接导致运行系统在峰值时，由于XML消耗了大量内存，1G的内存根本吃不消;同时对XML解析执行使用了CPU的大量时间;导致开发人员需要做大量的工作，开发效率降低了，通常需要尽一周才能完成一个xml文件，员工都不愿意做;也导致开发过程的漫长， 开发部门对于BA部门和ST部门的要求反应变的缓慢。
在第二个版本的实现中，重新实现了DTD，加入了大量的关键字同时也消除了verbose，大量的缩小了XML大小，从4000多行减低到900多行。不仅减低了内存使用，提高执行效率;也提高了开发效率，基本只要一天就可以完成一个映射文件。同时对BA部门和ST部门的反应也快了。
案例B：脚本的问题。产品在web层提供了脚本支持，出于方便开发的目的。但是没有对脚本的环境限制，脚本可以做系统程序的大部分工作。导致开发人员偷懒，在web层混入了大量业务逻辑代码。最终造成业务逻辑分散而不可控制。
2) 组织结构对技术，开发效率和应变能力的影响。
案例A.部门的分工问题。开发部门根据不同的职责，分成A，B和C等数个小组。大部分开发中互不相干。但也有时候，需要跨组的支持，比如B要实现某个需求，需要A在一定条件在记录一个或多个信息。因为每个开发人员各自负责一部分工作，导致跨组沟通的困难。同时由于整个开发部采取任务绩效，有时间压力，加上只是一个小的要求。于是在A人员的同意下，B人员直接在A代码中写入业务逻辑。每次都是这样的小改动，不断的发展后，代码开发变凌乱。
案例B.开发的历史问题，当某个开发人员写下的代码，有是问题的，接手开发人员由于文档不全以及没有测试用例，不愿意承担变化的代价，选择小修小补，这个小修小补有可能和有问题的代码混杂，导致更大的代码。
3) 过程对开发效率和应变能力，以及组织的影响
案例A.过程的问题。开发部门的上下游部门BA部门和ST部门的合作关系。ST部门的绩效考核,考核基于发现错误的数量，导致ST为了完成任务，提出一些非正常性要求。PM部门出于部门的方便通常提出一些实现难度比较大要求。开发部门本身又存在时间压力，导致一些需求的实现本应在低一层的代码中实现的，却在高层用蹩足的方式实现。
案例B.帮助系统的问题。帮助系统一开始采用一个个单独分散的静态页面。出于性能的考虑和部门负责考虑。帮助系统不断改进中，过程缺乏组织性，文件的命名规则随意，存储位置随意，造成了管理的混乱。直接的后果是页面的入口混乱和各自引用关系混乱。
在帮助系统的第二版，从静态页面转成动态页面。采取统一分类和命名规则，并统一了入口。同时采取分级管理引用关系，适度冗余。虽然减低了运行性能。但提高了开发效率和可维护性。
