Responsibility 1: The functional needs of the enterprise as a whole must be considered to maximize reuse
Background
It can be common to find feature/function duplicated across multiple applications and development organizations, especially in companies that have been around a while. For instance, "address validation", "geocoding", "credit card validation", and "currency conversion" are examples of functionality that might be duplicated. In each case, the features might differ, the underlying technology might differ, and where applicable underlying software vendors might differ. Ultimately this duplication translates into increased hardware, license, labor, and maintenance costs.
What are some reasons duplication exists?
In using "currency conversion" as an example:
- Technology and platform differences: A distributed application invokes currency conversion directly using a C API. A COBOL application uses currency conversion on the mainframe and inaccessible to distributed applications.
- Differing requirements: An application area supporting North American operations deploys conversion between U.S. and Canadian currencies only. At some other point in time, another development area supporting international operations requires conversion for a broader set of countries. Or an application needs "historical" conversion rates but the service owner is only able to support "current" rates.
- Differing priorities and timelines: An existing service cannot be extended to meet the needs of others due to project workload and competing priorities.
- Ownership considerations: An application area is unwilling to take responsibility for any impacts resulting from outages. Or is unwilling to coordinate changes/testing with any other development groups.
- Differing performance and availability requirements: An application team with more stringent availability or performance needs decides to deploy duplicate capability to maintain control of their own destiny.
- Lack of visibility to existing services that are available
These items are sometimes used as justification for sprouting duplicate functionality. An archaeological dig into the history of how duplication came to be is educational. Sometimes the reasons for duplication can be rationalized. And sometimes the reasons aren't valid at all, especially after a certain amount of time has passed.
Considerations
When building a new service or transitioning a legacy environment to common services, it is important to ensure "functional ownership" is clear. Achieving reuse can have different context. Some services have utility across the enterprise. Others are more domain-specific but hold the promise of greater use across the enterprise in the future. This is the reason I slipped the word "enterprise" into Responsibility 1.
To paint a simple picture of a good "currency conversion" service, it is one that maximizes reuse for both today's use cases as well enables future use cases to be supported. It supports currencies for the countries presently served and can expand to support other countries when needed. It supports conversions for current conversion rates as well as historical rates if there is a need to do so. And the architecture and development team is able to flex to meet additional functional, performance, and availability needs to maximize reuse across multiple applications.
This can be difficult to achieve without organizational considerations and/or a formalized governance process. Additionally, standing-up a service suitable for the enterprise requires the ability to perform a necessary level of business analysis. This is to ensure the broad functional needs of the enterprise are identified.
As briefly mentioned in a prior post, the goals of SOA typically involve reducing duplication and increasing reuse as a means to promote a more cost effective and agile operating model. It is difficult to meet these objectives without taking at least the spirit of this principle seriously.
Next time I'll explore...Responsibility 2: Meet performance and availability requirements. As requirements and usage patterns change over time, be prepared to adapt.
