In my first post on the promise of SOA, one of the constraining organizational factors that prevents full realization of the benefits of SOA investments I mentioned was:
Project management methodologies and software development processes that are based on waterfall approaches to building software and usually highly dependent on integrated testing.
Large enterprises usually have well-established project management processes, often built around a waterfall approach to the software development lifecycle. These processes serve a very valuable process in a non-SOA environment, as these organizations generally have complex, interdependent systems with a large amount of change occurring in parallel. Rigorous, formal waterfall development processes help mitigate the risk of change in this type of environment. Unfortunately, these processes also inhibit the flexibility SOA promises.
The reality is that designing software employing a service-oriented architecture is only one part of a larger solution. Simply building software so that it can be flexible doesn’t address the people or process aspects of using, maintaining and updating SOA solutions. Furthermore, an entire organization doesn’t move to SOA over a month, a day, or a year. When thinking about SOA, it’s necessary to think about how SOA will operate in a mixed environment where some applications are monolithic and difficult to fit into a service-oriented paradigm. Failure to do so results in unrealistic expectations that can undermine the credibility of the SOA efforts.
In organizations with a mixture of legacy (monolithic) and newer (distributed) platforms, the newer platforms are often easier to migrate to SOA. Doing so is necessary to deliver the long-term value of SOA, but may have little or no short-term value if they are dependent on non-SOA systems and particularly if they interact with legacy systems. Setting realistic expectations for this stage of SOA adoption is important because the benefits being realized will be related to changes within the applications using SOA. It is critically important to understand how much software change of an SOA-enabled system is dependent on monolithic, non-SOA enabled technology as this is the change that will not improve without significant change to legacy platforms.
If more than 50% of software change effort is driven by legacy systems, it’s very likely that the technology project management and software development lifecycle (SDLC) practices in use are geared towards those systems. Before expecting the software running on these systems to be SOA-enabled, the processes that govern software change must be examined. If the project management practices or SDLC approach is tailored to monolithic interdependent systems, simply making the interfaces to these systems SOA-enabled won’t make the overall environment any more flexible or maintainable.
All phases of an organizations SDLC approach must be examined in the context of the desired SOA target state to understand how the process may need to change. For example:
- Requirements artifacts. Developers supporting a monolithic system may be used to “line item” style requirements documents that alter the behavior of the system. “Line item” requirements may not provide the full context of the change, whereas more modern SDLC approaches (such as RUP or Agile) develop these requirements within the context of use cases or stories. This context helps to produce better SOA-enabled software using object-oriented software design, whereas line item requirements are sufficient for monolithic systems that historically used functional programming styles.
- Design documents. Design documents for changes to two or more interdependent monolithic systems often require deep technical knowledge of the interfacing systems. Even if this knowledge is not documented in the design artifacts, the interfaces themselves may not adequately abstract the internal operational details of the service provider from consumers. Furthermore, they often times are not built for re-use. Design artifacts may need to be tailored to force provider implementation details and to promote compoennt reuse.
- Testing approach. Monolithic systems often require very integrated testing environments and long testing cycles. If SOA-enabled systems are constructed carefully and correctly, the need for long integrated test cycles should be reduced. Testing processes and artifacts may need to be adjusted to encourage verifying correct abstraction of internal service provider logic from service consumers and the existence of appropriate reuse characteristics. If testing emphasizes and adequately verifies the interfaces, reduced integrated testing should be realized.
- Project timelines and release cycles. If requirements, design and testing artifacts and processes are revised to encourage an SOA approach, project timelines and release cycles may also need to be revised to account for changes in the way SOA-enabled software is designed and built. As SOA adoption increases, the duration of design, testing and implementation phases may be shortened. There may also be the need for more iteration within each phase (even if it occurs in the context of a waterfall SDLC approach) to take advantage of faster prototyping and more componentized development activity.
- Implementing SOA governance. As discussed in my prior SOA post, governance is critically important to the success of an SOA program. Ensuring compliance with SOA governance policies should be part of the organization’s project management and SDLC routines. Any standards with which SOA software is required to implement should be validated as an element of these routines.
Every organization is different, so the suggestions in this article are broad. When applying them to a particular organization, the key is to consider how the project, SDLC or organizational activities for changing existing, non-SOA systems need to change to support the desired target state SOA environment. So many of these activities occur from organizational “muscle memory”, they are often forgotten about until an SOA program is failing and root causes are investigated.
