Apply today for a FREE subscription to CIO Magazine!
Thu, Dec 20, 2007 22:46 EST
|
Posted by: John Michelsen in Best Practices Topic: Applications
Current Rating: |
The SOA (Service-Oriented Architecture) strategy of application delivery can create profound competitive value by aligning and integrating technologies more flexibly around business goals. Enterprises strive to align development, integration and testing activities in an agile way to achieve expected cost and time-to-market benefits by collaborating and sharing technology assets across teams.
However, realizing the value of SOA on a larger, enterprise-wide scale can be difficult, if not impossible, without also leveraging Virtualization. Once you split up development teams to deliver SOA, you realize that all these teams still need access to the system to complete their development and testing jobs if you are going to realize that cost and agility benefit. Like SOA, Virtualization is not something you simply buy -- it is something you must do.
Let's take a look at the 4 ways IT departments are currently leveraging Virtualization:
1. Hardware Virtualization, which is the most often mentioned type of virtualization, is the process of running multiple copies of the operating system as Virtual Machines (VMs) within one physical hardware device. This offers some great cost, flexibility and risk management benefits for the internal applications running in the data center.
2. Test Bed Virtualization is an extension of virtualizing hardware, by Replicating a target server as a test environment, which can enable a given server to quickly be re-provisioned for a team's use, and/or "rolled back" to a previous Virtual Test Bed version if a problem arises with the current application. This is extremely valuable, though it is intended for use within a controlled server environment - attempting to replicate all the distributed components and apps that make up SOA would be tough.
3. Virtual Endpoints allow the SOA to define virtual locations for Services that need to be invoked, when in fact you’re completely shielded from the actual end point of the service itself. This is ideal for the dynamic processes inherent in SOA applications, as the physical address (or URL) of a Service may need to change dynamically depending upon when and how it is used as part of a given workflow. Often the Virtual Endpoint and necessary lookup information is stored as a definition in a centralized UDDI Registry, so the address can be routed according to the specific needs of the workflow.
4. Virtualized Services are the last and most SOA-centric instances of Virtualization. Virtual Services are either constructed synthetically from WSDL, or modeled from existing Services and underlying implementations. This newer use of Virtualization attempts to streamline development and deployment practices as a whole, by allowing teams to simulate the behavior of the distributed SOA application. This becomes important with SOA, as teams seek to collaborate on delivering and consuming a changing live application environment that is becoming increasingly constrained.
So, we can see that Virtualization happens at the data center, but it can also happen within your application design, development and deployment process.
Often when people ask me about virtualization, they are only thinking of the hardware benefits - when there are a lot more ways to leverage it in enterprise architectures to streamline the rest of the application lifecycle. I'll post more articles on Virtualization and SOA in the near future, and your questions or comments on this topic are welcome.
A number of items in your post raise some interesting points. However, SOA, in my judgement, does not fully address the newest business demands. I would suggest that Software as a Service, utilizing components of SOA is a more effective business approach. It is not the critical point of platform or virtualization, it is that service or facility if you will is available upon demand. In many cases, the IT world looks at one aspect and while it seems to address the business at large as a partner, there can be and are many times gaps that are not addressed with respect to the service. I usually give the example of electrical service, while there may be power in the wall, the light bulb is burned out. The real request was to be able to read.
All that being said, I believe you have excellent points but would offer there is yet more and IT in general needs to address the real understanding of what the business is looking for, hence the service.
I keep hearing SOA proponents talk of "profound competitive value"... How is 2,3 or 4 producing "competitive value" that can be described as profound?
These are development-oriented techniques which may provide competitive value to ISVs. Only item 1 seems to offer enterprise value from a production or operations perspective.
Colin A. White
www.colinwhite.net