敏捷开发在软件开发中已经成为一股渗透力量，它的影响力还在进一步传播中。业务端的个体已经出现敏捷漏洞（Agile bug）——他们期望快速行动、迅速迭代以及可交付成果的稳定流。集成已经成为所有应用不可或缺的部分，企业集成架构部门被迫在混乱中尽可能成为敏捷开发团队。

　　在敏捷运动所波及的地方，有备而来呈现突出优势的是“精益运动”。有时候大家交换使用术语“敏捷”和“精益”。精益原则更类似于现代化制造原则，这一原则因汽车制造商丰田（Toyota）而闻名。精益方法有什么图书的标记吗？就是要消灭浪费。

　　精益理论正在逐渐包含在中间件集成开发和独立应用程序开发中。2010年有一本引路的书籍——《精益集成：业务敏捷集成工厂方法》（《Lean Integration: An Integration Factory Approach to Business Agility》），作者是John G. Schmidt和David Lyle。

　　在这本书的引言部分主要介绍了集成浪费。《精益集成》的内容建立于Mary和Tom Poppendieck之前的工作，他们是《实施精益软件开发》一书的作者，他们的内容建立于浪费概念的确立，类似于制造业和生产业。Schmidt和Lyle将其延伸到应用集成实践中。

　　举个例子，生产浪费（或者“muda”）是指有关于材料不必要运动中的运输浪费、库存浪费，典型的形式是库存积压；还有动作，指的是完成一项工作多余的步骤。这些库存现象已经类比到开发和集成中。

　　Poppendiecks映射了这些概念到软件开发领域中，运输的浪费可能意味着不必要数据的传递。这里的库存积压指开发工作并没有得到实际的部署。此外，产业动作浪费在这个世界的观点就是开发团队成员之间过多的任务转换。

　　映射精益集成

　　这种映射是怎么对应到应用集成的原则中的呢？作者Schmidt和Lyle看到了平行线。在一个称之为“镀金（gold-plating）”的工厂中，当它开始集成的时候，哪些可能成为不必要的材料运动呢？《精益集成》作者的观点是在创建功能性集成能力或者额外性能之前，他们需要的是错误实践。

　　书中写道，镀金工厂的业务领导失去了勇气。他们感觉自己的项目正在担负别人的负担。Schmidt和Lyle用了一个幽默的暗喻来描述这一情况，即“坐公车的第一个人就要为公车买单。”

　　谈到这里，SOA从业者可能会生气。服务需要一种企业的观点，SOA从业者认为这只能导向集成孤岛，以后会要求重做工作。《精益集成》的作者建议集成架构应该“仅仅创建第一个项目需求中的功能/性能，并以这样的方式来完成：当第二个项目到来时，他们可以在未来扩展。”

　　他们还写道：

　　“……如果改变的本质是第二个项目要求重构第一个项目开发的解决方案，方法就是要做到更加的令人满意，因为存在风险和创建早熟的功能的‘Muda’。”

　　当然，这也是有争议的。精益集成看起来好像和重要的SOA原则是对立的，就像敏捷方法的出现也是SOA的对立面，或者甚至是企业架构等等。但是这本书提供了思考的源泉。作者说“像花生酱那样使用中间件”（或者“在每一处应用”）白费力气做重复性工作和不必要的复杂性都是其他形式的浪费集成实践。

　　《精益集成》是个不错的读本。对于喜欢前景分析的人来说会是本重要的书籍。