What do enterprise architecture, virtualization, security, business intelligence, and organizational culture have in common with each other and with SOA? If you answered "very little to nothing at all," then think again because each one of these can make or break your SOA implementation.
To be fair, if all you are trying to do is implement a simple application as an SOA, then you might not need to consider the above items but the rules of engagement quickly change the moment you start expanding your SOA initiative beyond these simple boundaries. So, how can these five items elevate your current SOA implementation to an enterprise-level SOA? Let's take a look.
To identify the "right" services you must start from the business strategy and business processes and move down towards the applications, data, and technology as opposed to the other way around. As shown in figure 1, enterprise architecture is what will guide you on that top-down journey. Enterprise architecture is the blueprint that translates an enterprise's strategy and operating model into an executable architecture of processes, applications, data, and infrastructure. This blueprint is also where you will find candidate services for your enterprise SOA.
Figure 1: Enterprise architecture guides services in an SOA
SOA is a software architectural style that focuses on creating reusable, deployment/location independent, and standardized business services. But to truly create an agile environment your infrastructure must match the agility of your application and data layer. After all, why should you limit your SOA-based application layer by a monolithic infrastructure layer? Virtualization is the key to transforming your infrastructure layer to a service-oriented infrastructure (SOI) and "impedance matching" it to your SOA. Figure 2 shows an SOA application layer deployed on a virtualized SOI.
Figure 2: SOA impedance matched with SOI
Most SOA based systems tend to be highly distributed. Although, there is nothing inherent within SOA that mandates this distributed nature, it is probably due to the fact that SOA based systems tend to be complex and multi-dimensional. While distribution leads to many benefits such as increased scalability, such systems also tend to have a higher "surface area." Logic dictates that the more surface area of a system, the more vulnerable it becomes. Thus, the distributed nature of SOA systems becomes the "proximate cause" of their potential higher insecurity.
Then there is what I call the SOA security paradox... An SOA is by its very nature designed to be highly flexible, extensible, and maintainable. Now, think about the classic principle "security through obscurity." Therein lies the paradox -- a conflict between the inherent goal of SOA and the implication of this goal on security.
Finally, poor SOA governance can also increase system vulnerability. In the absence of strict governance -- design and runtime -- SOA systems tend to suffer from service proliferation similar to a virus spreading through its host. These unchecked services often expose previously hidden security loopholes. As an example, consider a service that is always called by a client on the extranet through an authentication service. One day, as part of an enhancement, a new rogue (i.e., ungoverned) service on the intranet calls this same service without the use of the authentication service. Now, consider what happens if this rogue service is called by an extranet client. Oops! Did we just bypass the authentication service? This simplistic example plays out more often than one might think.
Figure 3: Closing the SOA open loop with BI
SOA is an architectural style that strives for business and IT alignment. However, SOA by itself is an open loop process because it achieves this alignment based only on the current business state and lacks the feedback mechanism to constantly ensure and optimize this alignment once it has been achieved. That is where BI fits in by providing historical, current, and predictive views of business operations. BI includes a broad category of applications and technologies that gather, store, analyze, and provide access to data aimed at helping the enterprise make better business decisions. As shown in figure 3, these "better" decisions are what close the open loop SOA implementation by providing the feedback to ensure the continuous alignment between business and IT.
SOA is an architectural style that strives for business and IT alignment by the creation of reusable business-oriented services. For SOA to truly be effective at an enterprise level, it must be introduced with this enterprise-view in mind and with the full commitment and backing of executive management. Many failed attempts at SOA implementations can be traced back to a bottom up approach where too much attention was paid on technology details (Web Services, XML, ESBs, etc.) rather than the business side of breaking down functional silos, leveraging enterprise-wide capabilities, or creating an enterprise-wide shared vision of the end state.
Furthermore, SOA can be a disruptive force within an organization by not only changing the traditional view of ownership of systems, applications, and data but also by inverting the dynamic of IT constraining business capability to one where business defines IT services. Without realizing the impact of the organizational culture, the SOA implementation team could be blindsided by the (often powerful) resistance to change.
Much has been said about SOA as an architectural style, the associated technologies, and the post-implementation governance but achieving a truly effective enterprise level SOA requires one to step outside and look beyond the confines of the typical SOA box. To do so, one must take a holistic approach to implementing SOA by leveraging enterprise architecture, impedance matching the SOA with an SOI, addressing security early on, closing the open SOA loop with feedback from BI, and dealing with the realities of one's organizational culture. Do these things and you will be well on your way to taking your SOA to the next frontier!