The supreme consideration is speed. This is to take advantage of what is beyond the reach of the enemy, to go by way of routes where he least expects you, and to attack where he has made no preparations.
– Sun Tsu, Fourth Century BC.
There’s a great video on Google Video called “Competing on the Basis of Speed“. It’s a presentation by Mary Poppendieck, the author of “Lean Software Development: An Agile Toolkit” and is part of the Google Tech Talk series.
The focus of the presentation is on how companies like Toyota, Dell, and Google use speed and agility as a competitive advantage. Companies that compete on the basis of speed are harder for their competitors to catch. Speed itself acts as a barrier to entry, preventing competitors from successfully entering into their market.
It occurred to me while watching the video that speed isn’t only an advantage in the marketplace, but is also valuable in an internal IT department. Obviously an IT department within a company that competes on the bases of speed needs to be fast and agile, but even within a company that’s not known for speed, IT agility is an asset. A fast, agile IT department can deliver benefits to the business faster, and for lower cost.
So how do you achieve speed and agility? According to Mary Poppendieck, author of “Lean Software Development: An Agile Toolkit”, Speed requires a precise understanding of value: who, what, when , where, how and why. And it means getting value to customers without complexity creeping into your product or process.
We’ll try to return to the who, what, when, where, how and why in a future blog post, but first lets look at complexity. Avoiding or eliminating complexity is necessary to achieve agility. But to successfully eliminate complexity, we need to be able to identify it. So what is complexity? According to Poppendieck, there are three kinds of complexity:
- Waste: Anything that depletes resources without adding customer value.
- Inconsistency: Anything uneven, unbalanced, or irregular
- Overload: Any excessive or unreasonable process burden.
Poppendieck discusses a number of ways to identify and minimize these forms of complexity within individual software development projects. But a major problem for most enterprises, is the complexity across projects. Problems like duplication of functionality, duplication of data, out of synch data, high support costs, etc.
Solving the problem of cross-project enterprise IT complexity requires enterprise level IT planning and a cross-project enterprise level architectural approach to managing IT complexity.
Service Oriented Architecture, or SOA, is an approach that’s uniquely suited to reducing all three types of complexity in enterprise IT systems. Let’s look at how SOA reduces complexity, starting with how SOA helps to reduce waste.
SOA reduces waste:
SOA reduces waste by allowing the elimination of duplicate functionality across the applications within an enterprise. Common examples would be multiple applications which each calculate sales tax, or multiple applications which each process credit cards, checks or other types of payments.
This type of duplication of business functionality across multiple enterprise applications is wasted effort not only during the development state, but also across the lifecycle of the applications. Software is seldom static. 60% to 80% of all software development is after an application is first released to production. Business requirements and business processes change, and business software has to change to meet the new requirements and to match the new processes.
Software re-use through SOA helps to reduce the cost, complexity, and risk of these changes throughout the life of the enterprise applications. Consider the earlier example of an enterprise having multiple applications that each process credit card payments. What happens when there is a change in the business requirements for processing those payments? If the enterprise has used a SOA approach and has exposed payment processing as a reusable service, then the changes needed to meet the new requirements only need to be implemented once, in the shared service.
Contrast this with what happens when the same changes needs to be implemented in an enterprise that’s used a legacy, non-SOA approach. In this case, the same change will need to be made in each application that processes payments. Multiple changes, across multiple applications, possibly on multiple technology platforms translates into more cost, more risk, more complexity, and more waste.
SOA Reduces Inconsistency:
In addition to reducing waste, there are a number of ways in which SOA reduces complexity through reducing inconsistency. Reducing duplication of functionality, as previously mentioned, reduces inconsistency. If a particular element of business functionality is implemented multiple times across multiple applications, it’s highly likely that these implementations will not be consistent with one another. Even if they start consistent, they won’t stay that way!
Enterprise reuse through SOA also helps to reduce data inconsistency through the reduction of data duplication, and the ability to develop “single versions of the truth” for important data elements.
Mature SOA implementations reduce inconsistency even further by extracting business process information into a business rules engine. These rules can then be leveraged to control business processes across multiple applications and across multiple services, not only reducing inconsistancy, but also further reducing waste.
SOA reduces process overload:
Finally, the third type of waste is overload. Overload in Lean software development is about avoiding overloading your software development process. An overloaded process is unable to deliver solutions in a timely and consistent manner. An important measure of whether a process is overload is the process cycle time.
Cycle time in IT projects is the speed at which a business problem is reliably and repeatably translated into a deployed technology solution. Shorter, more consistent cycle time is good, because it translates into greater ability to deliver new business features and solutions. You can improve the cycle time by reducing the size of the tasks. Shorter projects = better cycle time = better ability to deliver value to the business.
Here again SOA can help. SOA enables new projects to reuse functionality from existing service enabled applications. Over time, this reuse inherently reduces the size and complexity of IT projects. But SOA can reduce project size even further. Using SOA, complex applications can be divided into into smaller discrete services. Each of these services can be built out separately, either in separate projects or at least as sub-projects.. Once the services exist, they can be combined and orchestrated into a composite application, usually driven by a rules engine.
I encourage you to take an hour some evening to watch the video. It’s very informative. I’d also encourage you to think about how SOA can help reduce complexity in projects you’ve worked on. What functionality have you built that could be exposed as services for re-use on other projects?