Read a full transcript of the discussion.
The real value of IT comes not from the systems themselves, but from managed and agile business processes in real-world use. Yet growing integration complexity, and the need to support process-level orchestrations of the old applications and new services, makes quality assurance at the SOA level challenging.
SOA, enterprise integration, virtualization and cloud computing place a premium on validating orchestrations at the process level before -- not after -- implementation and refinement. Process-level testing and validation also needs to help IT organizations reduce their labor and maintenance costs, while harmonizing the relationship between development and deployment functions.
iTKO, through it's LISA product and solutions methods, has created a continuous validation framework for SOA and middleware integrations to address these issues. The goal is to make sure all of the expected outcomes in SOA-supported activities occur in a controlled test phase, not in a trail-and-error production phase that undercuts IT's credibility.
To learn more about performance and quality assurance issues around enterprise integration, middleware, and SOA, I recently interviewed John Michelsen, chief architect and founder of iTKO. [See additional background and solutions.]
Here are some excerpts from our discussion:
Folks who are using agile development principles and faster iterations of development are throwing services up fairly quickly -- and then changing them on a fairly regular basis. That also throws a monkey wrench into how that impacts the rest of the services that are being integrated.Listen to the podcast. Download the podcast. Find it on iTunes/iPod. Learn more. Sponsor: iTKO.
That’s right, and we’re doing that on purpose. We like the fact that we’re changing systems more frequently. We’re not doing that because we want chaos. We’re doing it because it’s helping the businesses get to market faster, achieving regulatory compliance faster, and all of those good things. We like the fact that we’re changing, and that we have more tightly componentized the architecture. We’re not changing huge applications, but we’re just changing pieces of applications -- all good things.
Yet if my application is dependent upon your application, and you change it out from under me, your lifecycle impacts mine, and we have a “testable event” -- even though I’m not in a test mode at the moment. What are we going to do about this? We have to rethink the way that we do services lifecycles. We have to rethink the way we do integration and deployment.
If the world were as simple as we wanted it to be, we could have one vendor produce that system that is completely self-contained, self-managed, very visible or very "monitorable," if you will. That’s great, but that becomes one box of the dozens on the white board. The challenge is that not every box comes from that same vendor.
So we end up in this challenge where we’ve got to get that same kind of visibility and monitoring management across all of the boxes. Yet that’s not something that you just buy and that you get out of the box.
In a nutshell, we’ve got to be able to touch, from the testing point of view, all these different technologies. We have to be able to create some collaboration across all these teams, and then we have to do continuous validation of these business processes over time, even when we are not in lifecycles.
I can’t tell you how many times I’ve seen a customer who has said, “Well, we've run out and bought this ESB and now we’re trying to figure out how to use it.” I've said, “Whoa! You first should have figured out you needed it, and in what ways you would use it that would cause you to then buy it.”
We can’t build stuff, throw it over the wall into the production system to see if it works, and then have a BAM-type tool tell us -- once it gets into the statistics -- "By the way, they’re not actually catching orders. You’re not actually updating inventory or your account. Your customer accounts aren’t actually seeing an increase in their credit balance when orders are being placed."
That’s why we’ll start with the best practices, even though we’re not a large services firm. Then, we’ll come in with product, as we see the approach get defined. ... When you’re going down this kind of path, you’re going down a path to interconnect your systems in this same kind of ways. Call it service orientation or call it a large integration effort, either way, the outcome from a system’s point of view is the same.
What they’re doing is adopting these best practices on a team level so that each of these individual components is getting their own tests and validation. That helps them establish some visibility and predictability. It’s just good, old-fashioned automated test coverage at the component level. ... So this is why, as a part of lifecycles, we have to do this kind of activity. In doing so, we drive into value, we get something for having done our work.
Read a full transcript of the discussion.
No comments:
Post a Comment