Here is part two of my recent interview with host Mike Lippis of the Outlook Series. We have broken the 45 minute podcast interview into five parts for easier reading. This section covers SOA testing best practices.
Mike: “Service Oriented Architectures really have been around for a long period of time, and it’s really not a certain thing but more of a style of doing something. If it’s a style, there’s going to be different kinds of approaches -- lots of interdependencies and something that’s going to continuously change and evolve. What are you doing in the area of SOA testing and addressing those kinds of structure flow issues?”
John: “That’s a great point because you’re right; the concept of component-based applications has been around for a long time. I’m going to show my age here, by the time we come to the end of this conversation, you’ll know that I’ve been around a little while…
“Our approach is basically the same as it has been for many years: let’s take business logic and let’s encapsulate it into objects so that they can be leveraged across applications. Let’s start to layer systems by their responsibility or domain so that we can build applications that are specific in terms of their interface. For example, I might have a voice response unit for telephone callers and I might have a call center application for users on the phone but I don’t have to rewrite all of that logic every time, and I can make changes to business logic more quickly that way. We’ve been talking about that concept since the late 70’s. What makes SOA different today is that we are accomplishing it more than we ever had in the past due to the commoditization of middleware. The fact that there is highly available, very reliable and also very understandable and cheap middleware means that it is possible to build these applications today. So we are actually accomplishing it more than we used to in the past.”
Mike: “I’ve seen in some of your collateral that you talk about the three C’s for some time now. Can you tell us what those three C’s are and educate us as to what you have been doing and kind of describing the problem in that framework?”
John: “The 3 C’s are our framework for best practices for SOA testing. What we say is that if you have those 3 C’s right, than you are in good shape for having sound SOA test strategy. And, you can imagine our product LISA is a great way to accomplish these three C’s. However you do it, you need them because essentially this is the standard now, so how do you reach it?
“The first of these three C’s is “COMPLETE” and it essentially acknowledges the fact that this is a heterogeneous layering of technology. We must support a concept that we call Invoke & Verify. If I invoke at one layer of technology I have to actually verify the outcome I am expecting by going to a different technology layer. For example, if I go to an ATM and I deposit the money in the ATM and if I trust the receipt that it prints, that’s not really testing. The way I test the ATM is by calling the bank teller or by going to my web site and looking on the web -- I go around the actual device that I am testing so that I can prove the outcome that I’ve expected.
“The second of these three C’s is COLLABORATIVE. Collaborative basically requires us to do more parallel activities and to leverage assets more rapidly than we had in the past. Agile and SOA are usually tightly aligned. In fact, most CIO’s tell me ‘I’m going SOA so that I can become agile.’ They are very linked at the highest level in most of our accounts. Because of that, we need to do more in parallel and more shared.
“The third of these three C’s is CONTINUOUS. This essentially acknowledges the fact that we can’t test as an event along a life cycle anymore, and think that this is enough. The fact that I’m dependent on let’s say your services Mike, means that I may test my applications today -- deploy this Friday and the following Monday you update a service underneath my application and threaten or risk – there’s our word - risk failure of my application in doing so. So our strategy calls for a continuous validation of functionality, performance and certain policies on a continuous basis, - that’s the
third ‘C’.”
Mike: “You have a product that’s called LISA. How does LISA specifically achieve these three C’s that you just described?”
John: “Breaking it down a bit, we support all of those different technologies from a COMPLETE point of view. Whether it’s web technology, Thick UIs, messaging layers, web services, older protocols like CICS and CORBA … all of those kinds of things; we support all of those different technologies from the same test case. It’s very important that you be able to do this in one test with one product. If you buy three or four different products to accomplish one test scenario, that is way too much effort and it is very difficult to try to integrate a bunch of testing tools to make one test. It’s really not feasible to do -- you need to have all of these technologies covered in one workflow. That is why we differentiate in many ways on the ‘COMPLETE’ C.
“For COLLABORATIVE, we provide the ability to do Development type testing, (whether that’s Unit testing or Service level testing), Functional and System type testing, Performance Testing, even Functional Monitoring all as one unified test from one product. We’ve got to leverage each other’s assets more. Developers need to start the testing process, QA needs to consume and extend, if you will, with development based testing, etc. so that’s how we support the COLLABORATIVE.
“For CONTINUOUS, we actually provide both continuous integration support so we integrate continuous integration-type tools … build tools like ANT and CruiseControl and all those types of things. We also provide our own infrastructure for integration labs, for production, for pre-prod type systems enabling us to provide our own infrastructure for continuous validation. Therefore, we specifically support those three C’s in our product development and design, so we can accomplish these best practices for our customers.”
Mike: “It really sounds like SOA testing is a key part of overall IT governance then.”
John: “You know testing clearly is -- it’s gotten much more relevant in the last few years. It used to be just a step along a time line: ‘we make sure we test it before we let it go into the wild’ -- and that was just fine. Today, because we have a greater degree of reuse expected, and because we have a more distributed development force -- where they are not even always us -- sometimes it’s ‘us & them,’ unfortunately, where I’m supposed to trust people I don’t even meet or know. Because of that, the need to test has become greater and the possibility of failure becomes greater along with it. So testing has become a much more critical focus of both development and even of governance. In many ways test is the means to instill trust which is, of course, the goal for governance.”
[This concludes part two. In our next post we cover performance management and testing.]
Comments