The only reason anybody spends money on integration at all is because software, as a rule, doesn't integrate by itself. But no executive thinks that spending money on integration addresses a strategic need of the business. Instead, money spent on integration typically goes into fixing something that really shouldn't have been broken in the first place.
Based on the traditional approach, a software application is defined with system-based requirements, its design, and then coding and testing within a well-defined software development lifecycle. The primary focus is on the code's implementation. As a result, integration with teams has traditionally been tightly coupled with little consideration for metadata. Today, integration solutions and paradigms have shifted the focus to code re-use and consolidated application solutions. This approach redefines the solution based on business-defined services - which is how it should have been done from the start.
With the introduction of service-oriented architecture, the paradigm of business users creating application functionality was very exciting and led to a lot of buzz. This was done through building and managing business processes, all hosted on an enterprise service bus - thus disentangling the integration “spaghetti” forever. SOA abstracts the underlying technology, so that developers enmeshed in connecting systems and applications can now focus on building services. With a selling proposition like that, it was no surprise that everyone wanted a piece of the action.
What Isn't Working with SOA
However, for all the excitement SOA generated, the enthusiasm has dimmed a bit somewhere down the line. So, what happened?
SOA is usually mistaken for a set of Web services defining a complete solution. Rather, SOA is a technology paradigm that supports the processes defined and governed by business. There has been a considerable investment in building SOA infrastructure already, but the payback has been slow, leading companies to invest in development of Web services rather than define a pure service bus.
There is a perception of 'SOA' as a means to enable integration with legacy systems. Legacy encapsulation can certainly be a great enabler for business processes, but it doesn't substitute for an effective SOA strategy.
A successful SOA initiative should focus on reducing complexity, transforming systems into services that implement core capabilities and eliminating redundancy. Further, it must define common patterns that apply to all business units and set up 'software factories' that enable the delivery of new products as services in a fraction of the time it used to take.
A successful SOA initiative must begin with strategic investment and aim at lowering total cost of ownership as subsequent implementations takes place. For an organization to adopt this strategy, it needs to be mature enough to take the risk of initial investment. Organizations with a clear focus on implementation will reap long-term benefits. To define the SOA roadmap well, it is critical to understand that it is about processes or services definition as well as technology and people. (See Figure 1, left.)
What Should We Be Thinking About?
Cut through the hype, be realistic. SOA has been overhyped, oversold and set up to fail. Headlines decrying the failure of strategic SOA projects tell tales of woe. In many cases, organizations that merely needed some straightforward extensions to their existing architecture were up-sold unwieldy architectures that proved impossible to deploy. It's a bit like starting to build a bypass for a town, but somewhere along the way the project grew to the size of a major city. Some useful reality checks:
- Ensure relevance by grading usefulness of each solution fit.
- Start small and deliver business value before becoming more ambitious.
- Define a roadmap for the entire service lifecycle, not just service identification.
- Ensure that SOA is requirements-driven and not demand-driven.
Crack the whip and rein them in. Governance is one of the most abused terms in the SOA world. Many on the SOA team manage architectural principle exceptions to orchestrate grossly inappropriate solution architectures. Those who question them are labeled prudes and dismissed in the name of progressive architecture. It is imperative to determine and price-out the SOA solutions that actually provide significant value to business. Applications that provide very little value to business but cost an awful lot are the ones to eliminate first. Doing SOA right requires core services and infrastructure to be built before the high-visibility, high-value projects can be properly accomplished. It is important to ensure strict adherence of key projects to all governance mandates.
Skip the canonical data model. Purists may shake their heads, but our experience has been that the enterprise canonical data model is not indispensable for an SOA initiative. The way forward is a federated MDM strategy and a brokerage approach to communication between systems. This should ideally be based around a distributed data strategy that leaves information in the source systems but provides references between them. If you consider the impossibility of imposing the canonical data model on your next SaaS provider, the virtue of this approach becomes apparent.
Get on the dirty bus. The real enterprise service bus is a myth. The entire enterprise will never get on a single “bus.” This is primarily because there never will be a business case strong enough pull funding for the strategic service model on legacy systems. A more pragmatic approach would be to divide the enterprise bus into two logical sections: the clean data bus that hosts enterprise services adhering to the enterprise service framework, and the dirty bus to host specific services for legacy and non-adhering systems. The dirty bus clearly scores over the erstwhile point-to-point integration, offering greater control over auditing, logging and exception handling.
Agreed. An SOA initiative needs to actually make things better for your company or employees or what was the point? Having the technology but not fully utilizing it is a waste of time and resources.