Myriad unpredictable demands are being placed on enterprise application services as Service Oriented Architecture (SOA) grows in use. How will the far-flung deployment infrastructure adapt and how will all the disparate components perform so that complex business services meet their expectations in the real world?
These are the questions put to a live panel of analysts and experts at the recent TIBCO User Conference (TUCON) 2008 in San Francisco. Users such as Allstate Insurance Co. are looking for SOA performance insurance, for thinking through how composite business services will perform and to ensure that these complex services will meet and exceed expected service level agreements.
At the TUCON event, TIBCO unveiled a series of products and services that target service performance management, and that leverage the insights that managed complex events processing (CEP) provides. To help understand how complex events processing and service performance management find common ground -- to help provide a new level of insurance against failure for SOA and for enterprise IT architects -- we asked the experts.
Listen to the podcast, recorded live at TUCON 2008, with Joe McKendrick, an independent analyst and SOA blogger; Sandy Rogers, the program director for SOA, Web services and integration at IDC; Anthony Abbattista, the vice president of enterprise technology strategy and planning for Allstate Insurance Co., and Rourke McNamara, director of product marketing for TIBCO Software. I was the producer and moderated.
Here are some excerpts:
We are describing what could be thought of as insurance. You’ve already gone on the journey of SOA. It’s like going on a plane ride. Are you going to spend the extra few dollars and get insurance? And wouldn't you want to do that before you get into the plane, rather than afterward? Is that how you look at this? Is service performance management insurance for SOA?Listen to the podcast. Read a full transcript. Sponsor: TIBCO Software.
It’s interesting to think of [SOA service performance management] as insurance. I think it’s a necessary operational device, for lack of better words. ... I don’t think it’s an option, because what will hurt if you fall down has been proven over and over again. As the guy who has to run an SOA now -- it’s not an option not to do it.
I actually do look at service performance management as insurance -- but along the lines of medical insurance. Anthony said people fall down and people get hurt. You want to have medical insurance. It shouldn't be something that is optional. It shouldn't be something you consider optional.
It’s something that you need to have, and something that people should look at from the beginning when they go on this SOA journey. But it is insurance, Dana. That’s exactly what it does. It prevents you from running into problems. You could theoretically go down this SOA path, build out your services, deploy them, and just get lucky. Nothing will ever happen. But how many go through life without ever needing to see a doctor?
What we are seeing is that, as services are exposed externally to customers, partners, and other systems, it affects the ability to fail-over, to have redundant services deployed out, to be able to track the trends, and be able to plan, going forward, what needs to be supported in the infrastructure, and to even go back to issues of funding. How are you going to prove what's being used by whom to understand what's happening?
So, first, yes, it is visibility. But, from there, it has to be about receiving the information as it is happening, and to be able to adjust the behavior of the services and the behavior of the infrastructure that is supporting. It starts to become very important. There are levels of importance in criticality with different services in the infrastructure that’s supporting it right now.
But, the way that we want to move to being able to deploy anywhere and leverage virtualization technologies is to break away from the static configuration of the hardware, to the databases, to where all this is being stored now, and to have more of that dynamic resourcing. To leverage services that are deployed external to an organization you need to have more real-time communication.
With something like a Tivoli or a BMC solution, something like a business service management technology, your operational administrators are monitoring your infrastructure.
They are monitoring the application at the application layer and they understand, based on those things, when some thing is wrong. The problem is that’s the wrong level of granularity to automatically fix problems. And it’s the wrong level of granularity to know where to point that finger, to know whom to call to resolve the problem.
It’s right, if what's wrong is a piece of your infrastructure or an entire application. But if it’s a service that’s causing the problem, you need to understand which service -- and those products and that sort of technology won’t do that for you. So, the level of granularity required is at the service level. That’s really where you need to look.
A lot of the initiatives around ITIL Version 3.0 are starting to get some of those teams thinking in terms of how to associate the business requirements for how services are being supported by the infrastructure, and how they are supported by the utility of the team itself. But, we're a long way away from having everything all lined up, and then having it automatically amend itself. People are very nervous about relinquishing control to an automated system.
So, it is going to be step-by-step, and the first step is getting that familiarity, getting those integrations starting to happen and then starting to let loose.
We're dealing with organizations like Allstate, which have massive size and scale, with 750 services. What do people need to be considering, as we moving into to yet more complexity with virtualization, cloud computing, utility grids?
You need to make sure that, as you move from the older ways of doing things -- from the siloed applications, the siloed business unit way of doing things -- to the SOA, services-based way of doing things, you don’t ignore the new complexities you are introducing.
Don’t ignore the new problems that you are introducing. Have a strategy in place to mitigate those issues. Make sure you address that, so that you really do get the advantage, the benefits of SOA.
What I mean by that is with SOA you are reusing services. You are making services available, so that that functionality, that code, doesn’t need to be rewritten time and time again. In doing so you reduce the amount of work, you reduce the cost of building new applications, of building new functionality for your business organization.
You increase agility, because you have reduced the amount of time it takes to build new functionality for your business organization. But, in so doing, you have taken what was one large application, or three large applications, and you have broken them down into dozens or tens of separate smaller units that all need to intercommunicate, play nice with each other, and talk the same language.
Even once you have that in production, you now have a greater possibility for finger-pointing, because, if the business functionality goes down, you can’t say that that application that we just put on is down.
The big question now is what part of that application is down? Whose service is it? Your service, or someone else’s service? Is it the actual servers that support that? Is it the infrastructure that supports that? If you are using virtualization technology, is it the hardware that’s down, or is it the virtualization layer? Is it the software that runs on top of that?
You have this added complexity, and you need to make sure that doesn’t prevent you from seeing the real benefit of doing SOA.
No comments:
Post a Comment