Is 'lean' at odds with 'service orientation'?

Is 'lean' at odds with 'service orientation'?

That's the question put forth by Jack Vaughan over at SearchSOA.com. In a read of John Schmidt and David Lyle's work on Lean Integration, he ponders whether the two disciplines run counter to each other, versus supporting one another:

"The authors of Lean Integration suggest integration architects should 'build only the features/functions that the first project requires, and do so in such a way that they can be extended in the future when the second project comes along. ... If the nature of change is such that the second project requires refactoring of the solution that was developed for the first project, so be it. This approach is more desirable because of the risks and 'muda' [production waste] of building functionality prematurely.''

This has been a debate that has raged with the service orientation space for some time now. With SOA, projects may be a bit more expensive up front, with the second and third time a service is employed in an application or process the charm. The basis of SOA is evolutionary refinement over pursuit of initial perfection. Does this conflict with the do-it-right-the-first-time, but cheaper and faster credo of lean?

John Scmidt talks about lean integration in more detail here at the Informatica Perspectives site, which actually aligns strongly with a service-oriented philosophy:

"[Lean integration] explicitly takes the responsibility, and risk, for managing the integration dependencies away from the system owners, and it does it in a way that is service oriented and non- bureaucratic.  Second, it eliminates integration development tasks from the critical path of projects by using factory concepts such as automation, patterns, and reusable objects to turn a traditional custom development activity into an assembly activity."