Today SOA is often viewed as a complex, “enterprisey” kind of architecture mostly targeting large enterprise-wide development and integration effort. This view could be justified as SOA technologies and products, could, indeed, be complex.
This, however, does not mean that development of a SOA-based system can’t be agile. In fact, in my view, agile, highly iterative development approach is in the “genes” of SOA. SOA can be a great agility enabler for a software development organization.
Many development efforts involve replacing existing “legacy” applications. In fact, cases of creating applications that provide brand new functionality are relatively rare in enterprise world; usually some (or all) functions provided by the new application already exist in a legacy application or applications. A legacy application’s users may desire new features or they may want to otherwise alter the behavior of the legacy application, hence creating the rationale for its complete or partial re-write.
The truth is, most key business processes and principles of running a business do not change very often. Certain details may change, of course; for example, a loan approval process could be completely automated based on the available credit history and other personal details. This, however, does not change how interest on a loan is accrued – I suspect that the compound interest formula is a few hundred years old (at least). Or take a double-entry bookkeeping which was invented in fifteenth century. There have been some refinements but key ideas have not changed much in accounting.
The need for a complete re-write of a legacy application forces developers to re-invent the wheel, over and over gain. It also kills the agility because of the requirement to re-implement all of the functionality of the legacy application before it can be shut down and replaced by a new one. This makes the initial release cycle a long one; and if it is sufficiently long, the “latest and greatest” technology selected for the new effort will becoming obsolete even before the development is complete thus perpetuating even more changes and churn. This is not to mention the fact that project stakeholders don’t see any return on investment for years to come.
SOA promotes a completely different approach to software development by allowing reuse of existing legacy code. Almost any code can be wrapped in a Web service; this includes COBOL/CICS, COBOL/IMS, PowerBuilder, VB, you name it. This obviates the need for a complete re-write of large chunks of functionality. Instead, new features can be added incrementally, on the top of the existing code. This means that the time required to release new features can be reduced drastically. The first version of a new application could simply be the old code wrapped in services stringed together using some new logic (potentially, with a new UI on the top). Then, new features (expressed as services) can be injected into this architecture as quickly as necessary. With every release the system contains complete functionality including all the functionality of the legacy code. This is much more agile than big bang approach with monolithic builds.
This all sounds fine in theory, reality, however, is much more complicated. The most obvious complication is that the old code could be extremely messy and poorly organized and so developers of a new application could have a natural desire to improve it by potentially re-writing it. This urge should be resisted. If the code does what it’s supposed to do, it should be left alone. All “improvements” should go into the Web service wrapper, and the old code should remain intact. While this approach creates a maintenance issue and potentially promotes bad code, it allows the development team to stay agile. Later on, after the new system has proved itself to its customers, legacy code could be replaced with the new technology. This, however, should be a gradual process with legacy modules switched off over several releases. This approach allows developers to focus on delivering value to their customers instead of being bogged down in endless technology improvements cycles.