April 14, 2009, 2:11 PM — 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.
Enterprise Architecture
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.
Virtualization
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.
Security
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.
