I’ve been doing a little bit of musing (“Is SOA an Agile Enterprise Framework?“) about a development framework to support SOA. However, maybe Lean Production/Thinking would be better fit for SOA. In an earlier entry I mused about “How Web 2.0 supports Lean Production“. Let’s turn this question around and ask the question “How can Lean development be used in support SOA development?”.
Lean focuses on the elimination of waste in processes. Agile in comparison is tuned toward practices that adapt efficiently to change. There are though some commonalities between Lean and Agile Development. These specifically are:
- People centric approach
- Empowered teams
- Adaptive planning
- Continuous improvement
The last two bullet points align directly with the SOA Manifesto. For reference:
- Business value over technical strategy
- Strategic goals over project-specific benefits
- Intrinsic interoperability over custom integration
- Shared services over specific-purpose implementations
- Flexibility over optimization
- Evolutionary refinement over pursuit of initial perfection
One of the ideas in lean product development is the notion of set-based concurrent engineering: considering a solution as the intersection of a number of feasible parts, rather than iterating on a bunch of individual “point-based” solutions. This lets several groups work at the same time, as they converge on a solution.
In contrast, agile methods were meant for smaller more nimble development teams and projects. One would therefore think that in the context of enterprise wide SOA activities, Lean principles may offer greater value than the Agile practices. Well, let’s see if we can convince ourselves of this by exploring this in more elaborate detail.
Lean Software Development is defined by a set of “seven lean principles” for software development:
- Eliminate Waste – Spend time only on what adds real customer value.
- Create Knowledge – When you have tough problems, increase feedback.
- Defer Commitment – Keep your options open as long as practical, but no longer.
- Deliver Fast – Deliver value to customers as soon as they ask for it.
- Respect People – Let the people who add value use their full potential.
- Build Quality In – Don’t try to tack on quality after the fact – build it in.
- Optimize the Whole – Beware of the temptation to optimize parts at the expense of the whole.
Can we leverage these principles as a guide for a better approach to SOA development?
Where can we find waste in the context of software development? Poppendieck has the following list:
- Overproduction = Extra Features.
- In Process Inventory = Partially Done Work.
- Extra Processing – Relearning.
- Motion = Finding Information.
- Defects = Defects Not Caught by Tests.
- Waiting = Delays.
- Transport = Handoffs.
What steps in SOA development can we take to eliminate waste? Here’s a proposed table:
Waste in Software Development Lean SOA Extra Features If there isn’t a clear and present economic need for a Service then it should not be developed. Partially Done Work Move to a integrated, tested, documented and deployable service rapidly. Relearning Reuse Services. Employ a Pattern Language. Employ Social Networking techniques to enhance Organizational Learning. Finding Information Have all SOA contracts documented and human testable on a shared CMS. Manage Service evolution. Defects Not Caught by Tests Design Testable Service interfaces. Test driven integration. Delays Development is usually not the bottleneck. Map the value stream to identify real organizational bottlenecks. Handoffs Service developers work directly with Service consumers (i.e. developers, sysadmins, help desk)
The customers for a Service are similar to the customers for an API. I wrote years ago about how the design and management of APIs leads to the development of damn good software. The same principles can be applied with the lean development of services. Taking some wisdom from that, here are some recommended practices for Lean SOA:
- Designing Services is a human factors problem.
- Design Services to support an Architecture of Participation. Focus on “Organizational Learning”
- Focus on what a user of your Service will experience. Simplicity is the #1 objective. Only when this has been accomplished (at least on paper) do we talk about implementation details.
- Services arenxe2x80x99t included in a release until theyxe2x80x99re very simple to use.
- In tradeoff situations, ease of use and quality win over feature count.
- Useful subsets of standards are OK in the short term, but should be fully implemented in the longer term.
- Continuous Integration – Fully automated build process and tests.
- Always Beta – Each build is a release candidate; we expect it to work.
- Community Involvement – Community needs to know what is going on to participate. Requires transparency.
- Continuous Testing.
- Collective Ownership.
- Preserve Architectural Integrity –
Deliver on time, every time, but must preserve architectural integrity. Deliver quality with continuity.
- Services First – When defining a new Service, there must be at least one client involved, preferably more.
Finally, there is one last principle in Lean development “Decide as Late as Possible” that is of high importance. The ability to decide as late as possible is enabled by modularity. The absence of modularity makes composing new solutions and therefore new integrations extremely cumbersome. The key however is not to become a Cargo Cult and practice Lean SOA without understanding how one achieves modularity (or to use another phrase “intrinsic interoperability”). The key is to understand how to achieve that. That of course is the subject of the Design Language that I am in the process of formulating.
In conclusion, Lean SOA (A mashup of Lean and SOA) follow these principles:
Eliminate Waste – Spend time only on what adds business value. Create Knowledge – Disseminate and share Service knowledge with the organization and its partners. Defer Commitment – Be flexible before you optimize. Deliver Fast – Deliver value quickly and incrementally. Don’t try to boil the ocean. Respect People – Let the people who add value use their full potential. Build Quality In – Don’t try to tack on quality after the fact – build it in. Optimize the Whole – Strategic goals over project-specific benefits. Build Interoperability In – Services should be designed to be modular.
This is a simple as it gets. The devil of course is in the details.
Notes: You can find an earlier and different take on this here: SOA Agility.