Successful adoption of Service Oriented Architecture has been a topic of discussion pretty much since the beginning of its introduction to enterprise businesses five or six years ago. As companies have worked to adopt this approach to building more reliable and agile applications at a lower price, they quickly found that it wasn't as easy as it was to build the monolithic applications of old or even the n-tier and Internet applications that became standard archetypes in the late 1990s.
While those types of applications certainly require solid application development, deployment, and management discipline, SOA introduces several new dimensions to the challenge of successfully adopting applications built on this architecture. Applications that rely on SOA have two inherent attributes that do not necessarily exist within applications based on other architectures. First, the architecture promotes the composition of ever-smaller atomic services into higher-order services (a ProcessOrder service, for example, has ValidateCustomer and CheckCredit services associated with it). This "feature" introduces the potential for hundreds or thousands of these compositions to exist in the enterprise (or, in some cases, outside the organization's firewall; more on that in a subsequent post). Second, services based on SOA are autonomous and stateless by nature (or, at least, they should be!). As such, they can be created and exposed by anyone in the organization as a completely independent island of functionality without being tied to any one specific application.
While both of these elements of SOA can certainly benefit enterprises who wish to accelerate the creation of custom, line-of-business applications through the promise of service reuse, the dark side is that services can proliferate out of control. Adopting SOA doesn't inherently enforce reuse. Corporations may have multiple versions of a "CreditCheck" service created by different departments.
Further, these services don't necessarily have well-defined service levels defined for them that are backed up with enforceable service level agreements. While this may not be a significant problem initially, it can be a serious concern to organizations that want to adopt SOA as a strategic direction within IT. The nature of application development and maintenance changes since the development cycles, feature requirments, and service level requirements become decoupled.
While there are many potential impediments to SOA adoption, which I will post more on later, the discipline of governance and the implementation of robust service management is central to long-term sustainability of applications that rely on the services within an SOA. Here's why:
Subsequent posts will delve into each of these as well as other adoption issues. For now, we'd like to get your feedback on the list above and the subject of service management. What resonates with your experience and what doesn't? In particular, I'm curious about whether application performance issues represent an impediment to SOA. In my experience, this hasn't bubbled up as a tier one issue, but I invite you to prove me wrong.
All the best,
Erik, Application Platform lead, War on Cost Team