The ITKO Blog: Service Virtualization and Application Lifecycle Optimization - CA Technologies

iTKO Chalk Talk - Test Data Management

Here's a new feature of the iTKO Blog we hope you enjoy - a series of educational "Chalk Talk" short videos covering topics like Software Quality, SOA Governance, BPM Validation, Testing, Cloud Computing and more. This first one features our founder and Chief Geek, John Michelsen. He has a way of pushing a marker that really makes gritty enterprise software topics seem very approachable, so here's his first installment on the challenges of Test Data Management:

One topic that has been on the tip of most of our discussions and recent posts these days is that of virtualization as a solution for Test Data Management (or, "vDTM" as I like to call it...). This form of vTDM is important because it allows your test and development teams to virtually manage test data outside of the system of record.

We hope you find our new Chalk Talks engaging and informative, and look for more video from iTKO soon. If you have any topics you'd like us to cover in the future, send us a note at info@itko.com.

Virtualizing Over-Utilized Systems: Part 6 - Customer Examples & Conclusion

This is the sixth post in our series based on the new whitepaper "The Next Frontier for Virtualization: Over-Utilized Systems" by iTKO (Ahrens, English). In this issue we cover how companies are applying Service Virtualization to solve for over-utilization of core systems and services needed for testing and development.

Examples of how SV Answers the Challenges of Over-Utilized Systems:

Solving a Common Bottleneck – When each team can get their own replicated test environment and data provided as a Virtual Service at minimal cost, there is no longer a need to compete for testing time during a small availability window, much less secure a capital expenditure just to get access to a hosted service-based system.

Customer Example: A leading US airline replicated much of the functionality of a partner’s reservation system that charged high per-use fees when used for testing purposes, as well as restrictions on usage due to the fact that millions of transactions needed to be handled on the system daily. Switching to a virtual service model of the system allowed multiple teams to have their own stable environment and data for test scenarios, as well as saving millions of dollars annually (up to $12M)  in non-revenue-generating access fees for the live service.

Solving Improper Capacity – Trying to pinpoint the reason for functional errors and performance problems in a modern distributed software architecture is becoming increasingly difficult. IT departments can seek to throw more hardware and software at the problem, but that cannot solve the costly and time consuming software setup and configuration effort of enabling test and pre-production environments for multiple distributed teams to use.

Customer Example: A leading bank which has grown by acquisition found that they could not effectively load test middleware which tied more than 70 acquired systems together using their existing tools. They had several developers attempting to hand-code “stubs” and “responders” to replicate the environment for 2 years, with little success. Using Service Virtualization techniques, two test engineers configured realistic models of the current bank middleware systems.  They replaced the multi-year “stub” project in a few months and grew the practice to include another half-dozen teams across the bank. They have avoided up to $30M in costs for provisioning new environments over the course of a year.

Solving Inefficiency – Every business faces increased pressure to meet customer and regulatory demands with greater agility, and leveraging distributed software components and integration frameworks can add agility to our ability to deliver expected business outcomes. At the same time, the service-oriented approach to delivering software makes it harder to ensure service level performance and quality, due to an increased rate of change in the environment.

Customer Example: A US Federal agency needed to prove that their technology selections and architecture elements were performance ready, before they were put in place in the live environment. By virtualizing the rest of the environment and its expected response times and load variability, they were able to compare benchmarks and select the appropriate technology for their architecture, without needing to “bang” on critical live systems used for weather, air traffic and defense purposes.

Summary

Hardware virtualization is becoming ubiquitous in large enterprises, offering immediate cost savings and efficiency. While the concept of desktop and server virtualization has great value for optimizing less utilized systems, it is challenged in replicating heavily utilized or constrained systems such as mainframes, incomplete components, or third-party services.

Consider how much you invest in “under-utilized” hardware and desktop OS infrastructure, versus the high cost of integrating and maintaining traditional software test environments. There's a high probability that the development and integration cost of those traditional test environments exceeds your hardware costs by several orders of magnitude. The prohibitive expense of software test environments means applications are not tested early or often enough, which leads to even costlier failures in production. Virtualization of the behaviors of over-utilized systems can address this serious shortcoming.

Instead of copying the contents of a hard drive or replicating a piece of software running in an OS, Service Virtualization focuses on modeling the communication paths “between the boxes” – components such as web services, databases, RESTful services and asynchronous messaging. This lets teams break their dependencies on the bottlenecks which are preventing them from getting their jobs accomplished.

Development and testing teams need access to an ever-increasing number of services and systems of record that are not readily available. Service Virtualization is a strategy for letting teams take the principles of virtualization beyond the data center, simulating more distributed, complex environments, where significant value remains to be realized.

This concludes our series on SV and Over-Utilization. I'd like to thank Ken Ahrens for coming up with this unique way of looking at virtualization. We hope you find parallels of over-taxed and unavailable systems within your own environment that offer similar opportunities for efficiency improvement.

Virtualizing Over-Utilized Systems: Part 1 - A new concept

One of our really savvy Architects Ken Ahrens recently had an Aha! moment while visiting a financial institution. The customer was asking how our definition of virtualization was different than the more commonly known types of hardware and desktop virtualization already happening in most IT shops.

That's when it hit him: You are already familiar with virtualizing under-utilized systems -- servers and specific desktop OS configurations that don't need as much dedicated hardware and capacity as expected. That's certainly useful for trimming some IT costs.

But what about the over-utilized systems -- those critical and costly applications, services and mainframes that are just too big, or too remote to be replicated on a VM? The over-utilized systems represent a lot of cost, and big constraints for our ability to deliver and test software. Surely there must be a way to virtualize these too?

Well after a lot more analysis on this topic with Ken, we have a new iTKO whitepaper, "The Next Frontier for Virtualization: Over-Utilized Systems," that addresses how companies can identify and start to virtualize these over-utilized systems.

We'll be posting some additional notes and excerpts from the paper explaining the concept here in the future as well.

HP to Resell LISA Virtualize - The News

iTKO and HP recently signed an agreement which created a significant piece of news: "iTKO's LISA Virtualize Software to Be Resold by HP to Reduce Testing Costs and Accelerate Time to Market for Modern Applications"

There is a lot of value to capture here. In every major enterprise IT shop we go into, we find that there are a growing number of constraints to testing created by what the industry is calling "modern apps" -- highly distributed, componentized, loosely coupled applications that no longer reside within a company's four walls. Call it SOA, SaaS, Cloud, pull in BPM, legacy migration, etc. and you have a recipe for quality chaos.

Many of the systems we need for software development are supporting live transactions, contain critical customer data, are inaccessible to the team, and perhaps even charge significant fees for each access. IT shops can literally spend 40-60% of their development time trying to configure test beds, code "test responders" or stubs of needed services, and massaging data into and out of the system before and after each functional and performance test. Faced with these constraints, companies simply do not test as early or often as they should, and quality and performance suffers.

We are familiar with virtualizing servers and desktop apps, but what about the above highly constrained pieces that make up a modern app? These systems are resistant to hardware virtualization, but they can definitely be virtualized behaviorally with LISA, so now HP test and development team members can get access to them on their terms.

This functionality is complementary, but very different from the well-known practice of hardware-based virtualization, in that it is not imaging a hard drive or desktop OS as a VM. Instead it is an automated software-based solution to virtualize the behavior of downstream dependent systems, services, data and components that may not be under a team's control. There are huge benefits to be gained in terms of faster delivery cycles, fewer production errors, and much lower cost and effort of managing test environments, coding stubs and managing test data.

It's a fact that there are more performance and functional testers with HP's testing software installed than any enterprise solution on the planet. And every one of them could stand to benefit from having robust test environments that are readily available to work with. We think this is great news for the software lifecycle when the world's largest technology companies are working to solve some of the largest problems out there.

Stay tuned for more news about this partnership here.

Recent coverage of the announcement (in progress):

• Dana Gardner in ZDnet: HP Partners with iTKO on LISA Services Testing Suite for SOA, BPM
• Virtualization Journal: We particularly liked an article from Maureen O'Gara: "HP's Got a New Girlfriend Called LISA"
• Vance McCarthy in IDevNews: "HP To Sell iTKO LISA for Virtualized SOA, Apps Testing"
• eBizQ "iTKO's Virtualize Software to be Resold by HP"
• StickyMinds.com News
• Official iTKO release on BusinessWire.

Talk about Service Virtualization at HP Software Universe '09

At this year's HP Software Universe we're thrilled to be talking about a quality practice where we've seen incredible strides made over the last two years. The concept sounds simple enough: Virtualize away my upstream constraints and dependencies so that the test lab (for instance HP LoadRunner and Unified Functional Testing) solutions have a self-contained environment for testing.

However when you look at how complex and interdependent today's applications are, you begin to understand why replicating these complex behaviors -- such as unavailable or secured systems, third-party Services and components that are still under development -- has been resistant to replicating via conventional hardware virtualization means.

What is really cool is how we've seen customers of HP and iTKO bring this particular challenge under control. If you are planning on being in Las Vegas for this year's HPSU 2009 - June 15-19 - we invite you to take an hour to join HP Senior Product Manager Jeffrey Meyers, and iTKO Founder/Chief Geek John Michelsen to find out how these Virtual Test Environments can eliminate constraints (and costs) in a big way.

Session 1497: Thursday, June 18 - 10:30am - 11:30am
"Eliminate testing constraints and test earlier in the lifecycle: using service virtualization to drive testing momentum"

Here's the abstract of the session:
If your IT team is struggling with obstacles outside your organization, then join HP and iTKO and find out how HP testing solutions, combined with the iTKO LISA Virtualize platform, can minimize external dependencies and help you test earlier in the development cycle, before a complete test environment is ready to meet your testing objectives. You’ll hear how the combined HP and iTKO solution works in complex shared environments of modern applications, agile development techniques, and volatile data sources to make your testing efforts constraint free.

If you are planning on being there, look us up on Twitter as well: http://twitter.com/itko and drop us a note or feedback on your thoughts.

It seems in June we really catch the "last gasp" of interesting IT events, and this month is no exception - besides attending this excellent summit, we are bringing in the summer next week presenting sessions in Chicago at Technology Executives Club and a Federal roundtable at GTRA in Virginia. Hope we see you at one of these key events soon.

Showing some ERP mettle for SOA with SAP

So many of our customers have large-scale ERP packages like SAP or Oracle that form the IT foundation of the enterprise.  While at the outset this sounds like a simple architecture, given that you are working with a single vendor over a longer timeframe, in fact these systems are themselves rife with complexity and heterogeneity.  And so many applications now connect into the ERP via various forms of adapters and message buses, that you end up with the classic alphabet soup of technologies at play.

"iTKO/SAP Whitepaper: Validation & Virtualization of SAP Enterprise SOA Applications with iTKO LISA"

This new paper iTKO co-authored with SAP, after working with them in their labs, helps customers see just how valuable a service validation and virtualization offering can be in these environments.  By SAP’s own calculations, customers spend millions of dollars every year standing up and maintaining development and test labs for SAP, even when running on virtual hardware.  And when they need to perform complex integration and load tests with other systems, millions can become $10s of millions to support these environments.  

Our strategy of virtualizing the services layers of these complex applications in a VSE (Virtual Service Environment) like LISA offers is a great way to eliminate those costly constraints, and make it practically zero cost to stand up. This approach is great for our software partners like SAP, and especially for the end customer. After all, we all want to focus IT budgets and especially our integration and innovation efforts toward technologies that contribute revenue to the bottom line, and not manual support and configuration costs that aren't repeatable.

Yes, even big ERP is getting nimble for SOA. We expect even more collaboration with SAP and other software partners to better improve quality and agility for customers with Virtualized Services. You can also find the paper posted by co-author Joerg Nalik Ph.D. on SAP's Developer Network and COIL blog here: https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/14083.

Updated iTKO Website - 3 minute intro, new solutions areas

A quick note: We’ve made some significant improvements to the iTKO website (www.itko.com) today that will provide clearer starting points for learning more about testing, validating and virtualizing today's distributed enterprise apps.

As a highlight, look under Next Steps, where there is a cool new 3-min Flash movie that summarizes the benefits and capabilities of LISA in the context of the 4 C’s. Take a look:  http://www.itko.com/site/demo.html

We’ve also expanded the Solutions section to covers several new categories including ALM, cloud computing, outsource optimization, and others. We think the updated UI is a little cleaner and hope you agree. Let us know what you think!

 

iTKO LISA 4.6 Released

Ok- this post is about ourselves - but we do have cause for celebration. We are thrilled to announce the release of LISA 4.6 Suite today. We believe this latest edition takes LISA miles ahead in terms of Service Virtualization capabilities and breadth of support for heterogeneous technologies, rich internet UIs, and ease of use.

You can read the official iTKO press release here:

iTKO Releases LISA 4.6 Product Suite with Third Generation Service Virtualization Capabilities, Enhanced UI Testing, and Expanded Policy Validation and Governance Support
LISA 4.6 Suite Proven at Key Enterprise Customers and Reviewed by Analyst Firm Butler Group

Congratulations to the LISA development team, and many thanks especially to iTKO's beta customers who stepped up to validate this release and provided us with insightful feedback over the last months.

Additional coverage on LISA 4.6:

• Infoworld: iTKO touts Web 2.0, virtualization in test product

Butler Group Conducts Independent Audit of iTKO

The Butler Group, a UK-based IT analyst firm, recently completed a third-party technology audit on the LISA product suite v4.6. The audit is fairly broad as it covers product functionality, operation, and deployment along with commentary on product strategy and future directions.

Butler Group technology audits are free to their members, however we paid a fee enabling us to have limited distribution rights. You can download a copy on our site: see - Butler Group View - LISA 4.6 Technology Audit. Although we paid a fee, Butler Group performed the audit objectively and authored the content.

Butler Group is the IT End User division of Datamonitor and is a leading provider of Information Technology research, analysis, and advice. Founded in 1990, Butler Group is respected for the impartiality and incisiveness of its research and opinion. We are pleased to offer this report. Here is the abstract:

The iTKO LISA Suite, comprising LISA Test, LISA Validate, and LISA Virtualize, provides capabilities around testing, validation, and simulation of services in a distributed, multi-tier, component-based infrastructure. The code-free nature of the solution enables QA teams and developers to easily conduct unit, functional, regression, and load testing in test environments consisting of either live deployed services, or services that are unavailable or yet to be built. These tests can be performed in a simulated virtual environment that mirrors the behaviors and capabilities of an actual production environment. LISA is capable of running tests and tracking metrics at multiple underlying technology layers (for example, the Web UI level, data integration level, ESB messaging layer, Java objects/EJB and so on). The solution is targeted at Global 2000 organizations with significant investments in SOA, BPM, integration suites, ESBs, or any component-based architecture, looking to streamline their test and development processes for composite applications.

If you would like to see the entire report, it is available at Butler Group View - LISA 4.6 Technology Audit.

Minimize IT Outsourcing Risk with Collaborative Quality - Part Three

This is the third of a four part series that summarizes the key points of our paper on Minimizing IT Outsourcing Risk with Collaborative Quality. You can click on the title to get the complete white paper.

In the last post in the series, we started to look at how to meet the risks and challenges of the outsourcing of IT development. In this post, we will look at how you can handle the changing components and dependencies and achieve validation on an ongoing basis. We will also look at how iTKO enables parallel development and testing without constraints.

In a SOA environment, a change to any service can create "unintended consequences" by causing unexpected failures on other dependent services. Throw in third parties through outsourcing and you compound the risk. To mitigate this risk, you need to continuously validate that delivered components have accounted for other elements in the workflow, and declare those in your tests, providing other team members with visibility into those dependencies.

Now, we need to "coat dependencies with testing" from this perspective, to prevent unintended consequences and run automated tests as needed on an ongoing basis. As a best practice, teams often use our solution to segment continuous validation activities along business process lines. To achieve maximum efficiency, distributed teams need to decouple their own environments from dependencies on live or incomplete systems, so they can continue working in parallel, rather than waiting on each other.

Think about many services engagements, and the amount of effort wasted on providing test access on a live transaction service or critical data source to a service vendor. Often there is a very limited window of time that can be offered by the companies IT ops team. Service Virtualization solves this bottleneck by allowing teams to design, develop and test their own components against changing environments by capturing and modeling the rest of the system (services, data, mainframes, etc) as running Virtual Services that simulate the behavior of the needed target environment.

Now multiple teams can design and test services in parallel and thus eliminate the constraints and dependencies of accessibility, availability and security for incomplete components and live service implementations. In the fourth and last post in this series we look at best practices for the outsourcing consumer.

2008 - Record Year for iTKO

You might have noticed, on this blog we usually stick to topics like IT and industry best practices for SOA, BPM, Virtualization, Governance and the like, rather than talk about ourselves.

However, we have just put out a press release on a very successful 2008 for iTKO, and we couldn't be prouder to be able to continue this level of success in a challenging market, so please give us a pass to reflect on this progress for a moment here.

Thanks to all our customers and partners for helping us achieve another record revenue year for iTKO. The fact that companies are still making the decision to move forward now to realize the benefits of SOA quality and Service Virtualization means that LISA solutions have been identified as a key way to uncover new value, while eliminating risks and cost from the software delivery lifecycle.

iTKO revenues were up more than 100 percent, from both new customers and increased LISA adoption in our customer base. We released version 4.5 of our flagship iTKO LISA product suite, which added service virtualization for load and performance testing, and other customer-driven enhancements. In November, iTKO brought LISA Eclipse Edition to market, for more comprehensive test coverage within the application lifecycle.

Thanks also to the analysts and media who tracked our progress and engaged us in conversations this last year. We picked up a few awards also. LISA was honored in April by TechTarget's SearchSOA.com with a Gold Award for Service Performance Product of the Year. LISA was also selected as a Finalist in the Great Indian Developer Awards 2008, and just recently LISA Virtualize was voted the Best Integration Solution by SYS-CON's Virtualization Conference & Expo 2008 delegates.

Chris Kraus Quoted in Processor Magazine on Cloud Computing

Processor Magazine published the article, Cloud & Virtualized Systems – Development and Testing Challenges, by Kurt Marko in today's (January 16) issue. Kurt interviewed several subjects for the piece, and it makes for an interesting blend of perspectives from the analyst and vendor community.

Kurt's article begins with the forecast, “The consensus forecast for cloud computing is definitely sunny” and adds, “After several years of hype, cloud computing is poised to make the jump from vaporware vision to mainstream IT solution; however, moving enterprise applications to the cloud is anything but a turnkey process.”  The article then goes into detail on the process of successfully implementing cloud computing.

One of the challenges covered in the piece is the difficulty of replicating the number, diversity, and geographic distribution of needed clients when testing. There are two strategies for solving this problem: behavioral simulation and synthetic virtualized test environments. The article mentions that Chris Kraus, product manager at iTKO advocates functional and load simulation of the application, as well as the 3rd party cloud services that represent costs and dependencies:

“You want something that looks enough like the cloud for your test purposes,” Chris says. These simulations can monitor the cloud vendors’ performance and service levels, but Kraus stresses that verification must be done regularly, if not continuously, to ensure vendors meet SLA uptime requirements and performance levels under all conditions.  There are more interesting ideas here and it is worth looking at the entire piece.

Join Our ITKO Facebook Group on SOA testing and Virtualization

We have started an informal Facebook group on SOA testing and Virtualization for anyone interested in SOA and IT quality, validation and virtualization techniques. Bloggers, fans, LISA users, and anyone else interested in what iTKO is doing welcome.

John Michelsen interviewed by ebizQ at Gartner AADI

We were recently at the Gartner Application Architecture, Development & Integration Summit (AADI) at Vegas. Peter Schooff of ebizQ stopped by our booth and did a podcast interview of John Michelsen, our co-founder and chief geek. You can listen to the podcast at the ebizQ site, Beyond Testing to Validation: Live Podcast With iTKO.  

John mentioned that we are in the final stages of deploying LISA 4.6, which is the latest edition of our test, validation, and virtualization product. Peter asked what will this do for enterprises. John replied that currently enterprises have trouble increasing their pace of change through new application development and implementation. 

LISA is designed to address this need through enabling the faster, higher quality delivery of new applications. LISA also helps with continuous validation to ensure ongoing data integrity. In addition, LISA Virtualize can capture and simulate the behavior of interconnected systems and services, thereby breaking down development constraints by eliminating the barriers caused by physical dependencies.

John also discussed new analytics that will be available in 2009 through the Pathfinder feature. It traces SOA interactions across the enterprise, and exposes dependencies. John explains this in more detail and the benefits. In addition, John said that he will be looking closer at data management to address more challenges in this space.

Follow ITKO on Twitter

I encourage you to follow our company's Twitter feed, http://twitter.com/itko, for recent updates, whitepaper offers, observations from conferences, ITKO news, upcoming speaking engagements, forum attendance, and other stuff that fits into 140 characters. 

A lot has been written about Twitter recently (e.g., Guy Kawaskai – How to Use Twitter as a Twool, Hutch Carpenter - Why Professionals Should Continue to Blog in the Era of Twitter, and ReadWriteWeb’s - Discovering the Power of Twitter’s Real Time Search. Dell even said it made a $1 million in the last year and half through its Twitter feed. We may not be that ambitious yet, but we find it is a useful way to stay in touch.

We see Twitter as a complement to this blog and certainly not a replacement. Twitter allows us to make a quick comment on anything and everything in Burma-Shave style little text blurbs. The blog is where we will develop ideas and go beyond soundbites.

There is even an excellent blog on Twitter tips, TwiTip, that makes this point with its tag line, Twitter Tips in 140 Characters or More.  So join us on our Twitter feed (see recent messages below) and let us know what you think through Twitter or comments on this blog post.

Gartner AADI Summit 2008

We're here at the Gartner Application Architecture, Development & Integration Summit (AADI) will in Las Vegas on December 8 – 10. The subtitle is: SOA & Modernization: Beyond Business & IT Alignment.

The event site says, “Service-oriented architecture (SOA) is a reality no organization can afford to ignore. It fundamentally reshapes how you think, build and deliver applications. But SOA is not pursued in a vacuum, it needs to be part of a continuous IT modernization strategy that seeks to optimize your resources, and dynamically align with the rest of your business.”

We're looking forward to some of the discussions we'll have on SOA as it relates to bringing applications into the modern world, and will post some of our thoughts from the show here. iTKO will have a booth. iTKO's Chief Architect/founder John Michelsen will also be here, so come visit us at Booth M and schedule a talk if you are attending.

There are five new tracks focused on the 3 SOA maturity levels, Modernization, and Next Generation AD, and we are certain to hear more about Cloud Computing as well - we certainly wouldn't mind someone putting a stake in the ground on that definition.

There will be a special keynote by author and trendspotter Malcolm Gladwell, and a complimentary copy of his book Outliers will be provided to all keynote attendees.

But first, where's the coffee...

Agile SOA Across the Lifecycle - Part Six: Conclusion and Index of Links

This is the last of a six part series of posts on the Agile SOA life cycle. Here we will provide our conclusions. As the development lifecycle has changed from traditional waterfall development and testing, to agile, spiral and scrum models supported by ALM, the need for continuous testing throughout the lifecycle has become self-evident. In order to evolve these processes, and achieve the business responsiveness and cost benefits of SOA, there is a need for vastly improved processes in how we build, implement, and test systems.

This series only covers some broad brushes of how Lifecycle Quality can be embedded into your testing, ALM and Governance processes. We see customers using these same capabilities in new ways every day – for instance, using LISA Virtualize to create virtual service environments, Virtualization of the behavior of services, mainframes and data enables teams to get up to speed in managing and testing against a realistic environment that would be too costly to reproduce otherwise. This increases agility by moving teams into more parallel development cycles, through eliminating the constraints of services and components that are not available for testing.

Real cost savings are available here and this should resonate well with companies in today’s tight economy as we have discussed in recent posts, We also agree with Jeff Schneider’s post, Talking to the Business about SOA, that it is okay to talk to the business about these benefits. Most of those who commented on his post agreed, as well.  We are seeing strong business interest continue in these tough times.

Companies have invested significant cost and effort in establishing solid processes with market leading tools – and we need to bake quality and enforcement capabilities into these tools, without dictating the process. iTKO LISA’s automated testing, validation and service virtualization works alongside test management, ALM, IT Operations and SOA governance platforms to provide an exponential gain in application quality, development agility, and most importantly, trust across producers and consumers of today’s heterogeneous, interconnected applications.

This concludes our six part series on Agile SOA Across the Lifecycle with LISA. You can download this complete series at our ITKO LISA resources page. Below are links to the individual posts as they appeared on this blog. 

Agile SOA Across the Lifecycle with LISA - Part One: Introduction

Agile SOA Across the Lifecycle with LISA - Part Two: Test & Quality Management

Agile SOA Across the Lifecycle with LISA - Part Three: Application Lifecycle Management

Agile SOA Across the Lifecycle - Part Four: IT Operations, Monitoring & Performance

Agile SOA Across the Lifecycle - Part Five: IT and SOA Governance

Agile SOA Across the Lifecycle - Part Five: IT and SOA Governance

This is the fifth of a six part series of posts on the Agile SOA life cycle. Here we will at look at IT and SOA Governance.

With the introduction of agile, spiral, and scrum development methodologies, the traditional waterfall development approach of testing a near-finished app at the end of many Agile development cycles won't be agile at all, as the elements of the application are constantly changing.  Traditional models of IT governance will also not work.

To aggravate testing, the service-oriented architecture (SOA) design pattern is used to make IT  more responsive to changes requested by business. New process tooling has been introduced to specifically assist in the cataloging of service assets, and organization of policies governing SOA.

This new set of tooling created to support SOA revolves around governance platforms like HP Systinet / S2, SAG Centrasite, SOA Software, TIBCO ActiveMatrix and Oracle Fusion. These SOA Governance tools manage the collection and cataloging of metadata about services, and organize the interdependencies they have with each other, along with the documentation of SOA Policies to define how combined services should meet business requirements. 

Within the Governance toolset, SOA Registry/Repositories provide a new platform for LISA to automate testing and validation.  The traditional system requirement and functional testing will still occur, but in a SOA there are more opportunities to automate the validation and enforcement of policies.

The current thinking around SOA Governance is largely siloed and specialized around design-time WSDL validation, runtime performance, and security policy enforcement.  As SOA Governance matures to support robust and widely diverse SOA initiatives, this thinking must expand dramatically. One of the greatest values a SOA Governance platform must provide is the proof that policies written in human or business terms are in fact implemented in the system, on a continuous basis.

Validation with our LISA solution takes the form of positive and negative tests on the use of these policies, which are executed continuously at change and runtime, as services and their underlying technologies and data are constantly changing and evolving. The validation of the LISA test becomes a demonstrable artifact for exposing and enforcing SOA Policy, within the changing workflow of the SOA Governance framework.

Example Scenario of Validating SOA Policies

Let's look at a sample deployment, a series of web service definitions, as WSDL files, are loaded into the UDDI registry.  The relationships of the services to each other, and the documentation of how they can be tied together to create a business process is documented.  For a new employee introduction, there may be a series of services from the human resources package to identify the employee's location and managers, there are services that provision IT resources like computer and e-mail, and services to a external partner for insurance and benefits enrollment.  These services would be documented via their WSDLs and stored in the UDDI registry.  A HR-to-payroll business process will be defined utilizing these assets.

This all seems simple as long as each participant in the business process provides a well documented, functioning, reliable, and secure service.  The policies around the structural, behavior, and performance of these individual services are documented the governance tool.  For example, the business analyst will write policies in a tool like CentraSite ActiveSOA, describing the behavior of the services. 

The IT service will accept a new employee's name and id number and return an e-mail address, domain login, and default password.  The security service will accept the manager and role and provision the appropriate access control to systems for the new employee. The security manager will specify that the services must only run if encrypted and signed data is sent to them.  The signature must be validated against the companies master certificate provider to prove that the request is from only authorized HR personnel.  Lastly, the IT operations team will provide policies around how many transactions per second (TPS) the service should handle, and the maximum response time the service will take, so the component will be a good participant in a decomposed transaction.

That's far too many steps to carry out if it's a strictly manual validation process. The execution of the tests needs to live within the SOA Governance process.

Testing, Validation and Policy Enforcement Solutions

Given all of the processes enterprises must employ to manage the design, construction, integration and management of the IT environment, it makes sense to have a common, reusable way to apply validation and enforcement across these processes. SOA Validation becomes “the long arm of the law” with reusable and rich testing that merges into the workflow of each of these processes, and the tools that support them.

The Validation arm shown above (with our LISA as the "long arm") provides capabilities to run test cases to verify different rules and policies defined in leading IT process tools. The policing action is accomplished by tying automatic running of tests to the expected behaviors and policies in the workflow of the process tool.  The invocation of  tests from a governance platform to ensure SOA policy is similar to the policing action done for test management solutions, the biggest difference is the context and stage in the lifecycle of the component that needs to be verified. 

In a traditional test of a waterfall development there is a specific point in time in which the system is tested and deemed ready for production.  In today’s services-based applications, there is no longer one point in time in which we can identify a test run to ensure quality of the application.

In a SOA lifecycle, we think of design time, run time, and change time as the three stages of a service or business process being constructed within these loosely coupled systems.  In the example above some of the services are interactions with packaged applications (HR system), some from home grown systems (IT user and security provisioning), and other from external partners (benefits).  The development and release cycles of these three areas will be different and will not be coordinated for a single big bang release.  One advantage of SOA is the ability to decouple systems and utilize services created by different parties instead of building everything yourself.

At design time, a test will be run to make sure that WSDLs are WS-I compliant, that they follow an RPC or doc-literal call structure, and that a customer-specific XML tag is used for service identification.  Based the on passing of a compliance test, the WSDL will then be made available in the Repository for developers to code the functionality behind it. 

Once the developers have created the necessary code to implement the service and its underlying technology components, the behavior and security of the service needs to be validated.  The only way to verify if the code behind a service is working properly, since there are no hard-coded responses in the real world, and that security is respected, is to invoke the service, then verify that the underlying systems of record are updated properly.

Again, a test case is used to invoke and verify that the business requirements and the behavioral and security policies have been implemented. If the candidate Service can pass these Policy tests, it can now be published in the registry for a consumer to use.  If these tests fail, the service should not be promoted for availability to consumers in the registry.

As a best practice, the individual services should undergo load testing once they are made available. Far less risk is introduced if we test for load while the components are being built, when something can be done to improve performance issues, rather than waiting until the system is deployed, when issues are much more costly to repair. Progressive development shops start their load testing once the service functionality has been verified, so that developers can make code changes, and optimize logic and data access before consumers start utilizing the service.

In run time, the service is now promoted to the Registry, along with a test that demonstrates its functionality, and made available for consumers to leverage as part of their own application workflows. These consumers also bear responsibility for validating that their intended use of the service is actually supportable. The best way to do this is to create an executable test asset to validate that the structural, behavioral and performance aspects of the overall consumer’s workflow are supported when the service is leveraged. This will pay big dividends when the test is run continuously as part of the governance process.

The final stage is change time. This is when the true advantages of SOA and agile development come into play. If a new service needs to be added, or a modification to a existing service needs to be made to respond to changing business requirements, the policies for the service must be re-verified.  Not only do we want to update any behavioral policy with the new expected behavior, but the regression of existing policies must occur.

Put yourself in the place of the consumer of a service. How can you trust that changes will not create unintended consequences (e.g. failures) for a service you depend upon, and break your existing business processes?  Each consumer needs to place their expected behavior as a policy in the registry, with an accompanying test, so that it can be automatically validated before that change is made.  The automated structural and behavior policies in the test represent the consumer’s rights – and their responsibility for using the services as defined. When these tests run automatically as part of SOA Governance, trust between service consumers and producers is achieved. For more on SOA governance see Joe McKenrick’s posting of the full transcript of a recent eBizQ SOA governance panel that John Michelsen participated in.

In our next post, we will provide our conclusions. You can download this complete series as the "Agile SOA Across the Lifecycle" at our ITKO LISA resources page. 

Agile SOA Across the Lifecycle - Part Four: IT Operations, Monitoring & Performance

This is the fourth of a six part series of posts on how SOA works within the Agile life cycle. Here we will look at IT operations, monitoring and performance. Once an enterprise application is in deployment and under use, ensuring its continued availability, performance and accuracy becomes critical to the business. IT Operations teams may be part of the overall test and development team, or grouped as a separate function in many enterprises to offer a measure of impartiality to ensuring that required Service Levels are met within the live application environment.

Operations Management and Monitoring

The leading monitoring frameworks can be supported by directly testing and validating the systems under management, and feeding rich metrics and test output directly into the team’s IT Management dashboard, such as Wily/CA Unicenter, TIBCO Hawk, HP OpenView, IBM Tivoli, and others. As an example, our LISA tests can be run continuously at runtime and act as a listener for both functional errors, and server metrics from components including JMX, SNMP, Windows Perfmon and LISA’s own types of metrics.

The Operations team can set thresholds or boundary conditions on these continuous tests and have the Testing framework alert them if an issue occurs. For instance, if performance is too slow, or memory usage or a certain database table increases in an unexpected way over time, the test should report a failure to the management dashboard, and send an SMS message to the admin, along with the test case for root cause analysis and correction. LISA can also output this data as reports into the team’s management tools or data store to provide the ability to perform audits.

Performance & Load Testing with Leading Tools and a Virtual Service Environment (VSE)

Also key to the Operations team is ensuring that delivered systems will meet expected Service Level Agreements (SLAs) for customers. For today’s highly interconnected applications, the leading Test and Performance Lab solutions on the market were left out of the lifecycle of applications until near the end, when an interface or a complete system environment was available to test. A Virtual Service Environment (or VSE) provides teams using Performance Testing tools like LoadRunner and SilkTest the ability to get involved in ensuring performance much earlier in the lifecycle, at up to a 90% reduced cost per test environment.

The VSE captures and simulates the expected behavior and response times all of the dependent systems within your target environment. As component load tests are conducted earlier, teams can optimize their use of system resources, find memory leaks and fix the root causes of errors, at a much earlier stage in the design and development lifecycle, without needing access to the live system or all of the interdependent components needed in the test environment. The ability for multiple teams to conduct their own performance testing processes in parallel, prior to solution delivery, pays huge dividends in productivity and quality in deployment.

Behavioral Service Virtualization in this sense is by no means a replacement for virtualizing hardware and network resources to save costs in IT operations. But it does represent a huge way to reduce the dependencies and costs that can't be touched by virtualizing a given set of servers - after all, there are many third party or shared Services in the cloud, or heavy transaction systems and partner systems that can't be virtualized by conventional means.

Michael Vizard of eWeek writes about the role of virtualization in his post, Network Management Gets Virtual. He writes that many vendors are saying that, “it's become critical to extend existing network and systems management tools into the realm of virtualization. They argue that IT organizations don't need to invest in learning separate management tools for physical and virtual environments and the impact of decisions in one environment can be devastating on another unless the management infrastructure for both are tightly coupled.”

This tight coupling can occur under LISA. Using a VSE, teams can either model incomplete components, or capture live services, and simulate their behavior on a running server. Functionally and under load, these Virtual Services hosted in LISA’s VSE act and respond just like other services, databases and systems you connect to in the live deployment, including expected response and transaction times. Without requiring access to critical live systems, the team can connect their component to the rest of the virtual architecture in LISA Virtualize, and conduct performance and load testing with their tools of choice.

It is important to note that most companies have significant investments in test lab tools, and supporting them with robust target test beds makes those labs much more productive within the software lifecycle. Of course, our LISA Test & Validation solutions can also be that load and pefromance testing engine, and LISA test suites are executable and interoperable with the Test Management, ALM and SOA Governance processes mentioned in this series.

In our next post, we will look at IT and SOA governance. You can download this complete series in the Whitepaper on "Agile SOA" at our ITKO LISA resources page. 

Mike Kavis Talks with John Michelsen about Successful SOA Testing

Mike Kavis writes the blog, Enterprise Architecture and Other Enterprise Topics. Mike is currently CTO/Chief Architect at technology startup and has his own consulting company called Kavis Technology Consulting where he provides advice, training, and professional services on key technologies. He is also known as the "Mad Greek" in blogger and Twitter circles.      

 Mike recently talked with ITKO’s John Michelsen about questions to consider before building a SOA testing team. His questions came from a recent post he did on CIO.com, Six Questions to Consider Before Building a SOA Testing Team. Mike’s first asked John to identify some of the characteristics of successful SOA implementations from his customer base. John said that integrating testing into the entire development lifecycle is the key. Successful SOA implementations stay away from old waterfall methodologies and involve QA at the earliest opportunity. In many cases, testers work side by side with developers.  

Mike referred to another of his posts, SOA Skillsets: Part 4 - The Testers, that provides a similar viewpoint. He recommends that the Test Architect become a member of the EA team. In this post, he goes on to describe the skill sets for SOA Test Architect, SOA testing leads, business process testers, integration testers, user interface testers, and data service testers. In their conversation John stated that “most QA folks are still business analyst types and it should stay that way. If QA gets too technical then they lose the focus on testing.” Mike agreed and John added that this sets up the requirement that SOA testing tools should let less technical people perform technical tasks. 

John then went on and described LISA Continuous Validation Service and Virtual Service Environment which both accommodate the requirements they discussed. There is much more in Mike’s post and we appreciate him posting the conversation.

Agile SOA Across the Lifecycle with LISA - Part Three: Application Lifecycle Management

This is the third of a six part series of posts on how SOA is becoming merged with the Agile life cycle. Here we will at look at Application Lifecycle Management (ALM). As Forrester’s Cary Schwaber writes, the newest ALM platforms will improve the development process by providing common services to practitioner tools.  This current generation of ALM software is doing even more to tie requirements, test cases, bug tracking and issue resolution together in one application suite. You can see a simple illustration of this cycle of sharing Tests as collaborative assets below.

The process of converting business requirements into software is being automated through ALM tools, by tracking completion of coding and storing source code, execution of test cases to ensure functionality, and documenting product bugs and enhancements for development to prioritize.  Automated testing has been traditionally plugged only into the “test execution” phase of ALM. This provided statistics on code coverage or relaying the success or failure of a build. However, stronger testing can add value at every stage of the lifecycle managed in ALM tools.

For instance, developers can check in tests alongside their source code in the ALM’s repository, as simplistic “happy path” tests that demonstrate the intended functionality of the delivered component. Then, QA teams can be alerted to these new assets, and run and iterate on those tests to prove out a larger set of possible activities. Still another team can use all the tests from Dev and QA in the process of integration and deployment, tying multiple tests together to ensure that the overall regression and functional coverage is high with less effort. Finally, as the business team and Support teams get involved, they can run, modify and check in tests to the platform to signify issues or define requirements for the next phases of the ALM lifecycle. When shared in this way, tests become collaborative assets for SOA, and increase the agility and speed of each iteration cycle, while better ensuring the success of end-to-end business processes.

This practice can be employed with any testing tool, whether you are coding JUnit or using a more automated, no-code testing tool. The advantage of using a no-code testing environment, that automates the execution of tests without requiring coding skills, is it allows non-developers to get involved in the cycle above. Of course, our LISA provides a very robust way for developers, QA/QE, business analyst and support participants to get involved in the Agile SOA lifecycle. LISA tests are easily stored and shared within ALM repositories as XML files, and they are executable from the command line or JUnit of a build script, as a double-click from the ALM interface, or automated as part of a check-in or validation cycle for each deliverable. The LISA test then passes back the results to fail the build or update the status in the ALM system. Integration of LISA to ALM and related SCM (Source Code Management) and RM (Requirements Management) tools from vendors such as MKS, Borland, Rational/IBM, Compuware, and others, allows tests to help teams achieve the predictable delivery timelines and quality they expect, while using they process tools they are most comfortable with.

As shown in the above example, everyone should be involved in contributing and executing tests as each iteration at the component level is introduced, and these tests are rolled up into a broader workflow and business process. An Agile organization allows both developers and non-developers, in multiple teams, to collaborate on contributing testing components into the application long before the end of development. This ensures continuous testing at each iteration cycle and a more reliable course correction and release process.

For instance an Insurance company may have a requirement to match the Zip code with a certain type of auto policy coverage. The developer creates a component and checks it in, along with a simple test case that shows a few matches of Zip and coverage. The QA team can then iterate on that test with a dataset of all needed Zip/coverage matches, and make that test a requirement for each successive build. If the developer later updates the component and the required LISA test doesn’t pass, it reports it to the ALM system with the root cause analysis, and the build is failed and communicated back to the relevant teams for correction, according to the issue resolution rules of the ALM system.

For more on ALM, we recently found a nice report at BusinessWeek’s technology Research Library on Application Life-Cycle Management.

In our next post, we will look at IT operations, monitoring and performance. You can download this complete series at our ITKO LISA resources page. 

Agile SOA Across the Lifecycle with LISA - Part Two: Test & Quality Management

This is the second of a six part series of posts on the Agile life cycle for SOA. Here we will at look at SOA test and quality management.

In the past, test “scripts” in TM tools were largely recorded as actual step-by-step instructions (in a Word doc or Excel spreadsheet) for a manual tester to point-and-click through a finished interface to test the application. When tests were completed, the tester would then “check a box” in the test management UI, to indicate that the test had passed or failed. With so many changing components and middle tier systems in today’s enterprise apps, that form of manual testing is no longer enough, so teams are trying to define (and run) far more sophisticated tests that can actually test behind the user interface, where the business logic lies.

In addition to deeper functional testing, teams using TM tools are asking for a higher degree of automation from their test suites. A thousand manual test scripts can delay cycles by days or weeks while they are executed, costing the team serious agility, and making the testing less valuable over time due to repetition and human error.

Therefore functional, regression and load/stress tests need to be stored directly within the TM tool – for instance as executable command line or XML scripts that launch a test from a ready server-side tool. In this way, a sophisticated set of tests can be executed with just one click in the TM tool, and the pass/fail and other results and issues are automatically written back into the TM tool.

In this way, the whole team gets to use the test process they are familiar with, while getting much deeper tests that can talk to middle tiers, and as much as a 95% improvement in test execution time compared to manual tests. In addition, quality is improved as the teams can focus on testing new functionality, instead of repeating the rote execution of tests against existing functionality.

We are asked for this kind of functionality at virtually every customer engagement - so I'll mention our solution here. iTKO LISA provides connectivity to Test Management (TM) tools, such as HP TestDirector for Quality Center (formerly Mercury TestDirector), giving them a key point of automated test execution, enforcement and test feedback. A welcome “byproduct” or end result of this integration between LISA and test management software is auditable documentation of the test, with details about the status of the many systems under test – showing that at a specific point in time, the system was working as expected, or not working as expected. The testing tool has then fulfilled the requirement of being the "long arm of the law," by spotting the issue, enforcing or “making judgment” on it, and reporting the issue to the TM tool.

The overarching goal of this process is to allow better Collaboration on testing, by sharing and iterating on tests across Development, Testing, business analysis and IT Operations teams. This increases the level of reuse in SOA and enables faster release cycles, as all teams can focus on delivering quality into new features, instead of repeating test creation and execution manually with each new release. In our next post, we will cover application lifecycle management.  You can download this complete "Agile SOA Across the Lifecycle" paper at our ITKO LISA resources page. 

Agile SOA Across the Lifecycle with LISA - Part One: Introduction

This is the first of a six part series of posts on how ITKO LISA works across the Agile life cycle. For years, testing was an siloed activity that used different and unconnected tools within specific phases of the application lifecycle.  First, a development team would run a suite of JUnit tests as part of a build process. Then a QA team would manually create and run a suite of functional tests against a user interface. Performance teams would use a separate set of load tests to exercise and monitor the completed application.

In this old world, there was not much sharing of information and test assets among these teams, beyond the occasional text “bug report” that carried little context into the root causes of problems that occurred. This occurred largely because the available test tools created scripted test assets that were incompatible, and largely irrelevant to the next team’s process in the chain. Unit tests were good for developers to test for structural bugs in code, but those tests didn’t translate into any business context for the QA team. The QA team would instead script their own UI tests, which don’t exercise components or code in a way that developers can use to track down root causes.

This was not a very efficient process so companies began to align their people around better process tools that reach across the silos to better manage development, integration and management of their applications.  Agility is not just about delivering faster, it also bumps up the reliability of enterprise applications, by instilling a higher degree of collaboration and control across these suites of application lifecycle tools and processes. Agile promises many development efficiencies and increased flexibility. See Chris Spagnuolo’s post on Embracing Change with Agile Practices for a nice description of the flexibility in agile ad the ability to make mid-course corrections. However, if testing and validation is not handled right, risks will emerge compromising these gains.

In this series we are going to look at four aspects of the Agile lifecycle: test & quality management, application lifecycle management, IT operations, monitoring and performance, IT and SOA governance.  But first, let’s take a look at a sample of leading application process tools we often encounter within iTKO customer sites.

The goal of all application process tools is to enforce some kind of workflow into an aspect of the software lifecycle, be it around testing, development, operations or governance and integration of the overall IT infrastructure. Direct testability and validation of most SOA and enterprise software components that are managed by leading process tools is a must.

By supporting the workflow of these tools with executable test assets, we provide a higher degree of predictability and performance from the resulting application, while allowing development, testing and operations teams to better manage their process with the methods and tools they prefer. While many of the above vendor solutions might work across different domains (for instance ALM might include some Test Management), we’ve provided the above table as a sample of the tools encountered in typical IT customer environments. Key to Agile development practices is the tight interaction of testing with development activities, for faster delivery time of prioritized business functionality.

In essence, a test or validation is an asset that is stored in, launched from, or provides feedback into the above process and automation tools, contributing to the goal of Agility for SOA. In our next post, we will cover the test & quality management phase.  You can download this complete series on "Agile SOA" at our ITKO LISA resources page.

 

OutlookInterview Part Five: Conclusion and iTKO Overview

Here is the final installment 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 ITKO and concludes the interview.

Mike:  “Can you share a little background with the audience about iTKO’s general ecosystem, and as part of that could you give us have a use-case that you could share with us about how a given company may have used this LISA solution and benefited from it?”

John:  “I can even try to tie both of those together for you. 

“Our product LISA is especially suited for these complex heterogeneous type environments where there’s a variety of technologies at play, and the demands on these applications are extreme. That’s obviously companies like the financial sector and the insurance sector, and so we’ve done really well there, and in logistics and travel and a number of industries.

“For example, as in the US Department of Defense where they have the ‘everything’ problem, you layer in security and you layer in a lot of complexity there obviously, and a variety of different technologies and lots of legacy integrations.  We do really well when the problem gets harder and harder.  You know, any time your testing and your validation tool are trying to dumb-down the problem so they can get it tested … you should realize that this is signing you up for the harder part -- so that’s why we’ve gone to the approach that we have. So what’s that done from a customer base, has given us the most difficult areas of the largest companies and that becomes our target market. 

“We get partnerships from two different types of companies.  We get partnerships in the system integrator types, like Accenture, and Perficient who resell our product in areas, or any number of the largest outsourcing companies like Infosys, TCS, Patni, Satyam, Cognizant, Wipro, Mindtree, and I apologize to those listening who I haven’t mentioned -- I love every one of you guys so please don’t get me wrong… 

“From the services side:  we get a lot of help and that’s a major piece of our ecosystem because, quite frankly, those are the folks that are responsible for making something work for their customer and they are looking for the best practices way of doing this, and so they seek us out in many cases to do that. 

“Then the final part of our ecosystem is the actual ISVs -- the vendors who produce these SOA platforms, people in the integration space [e.g. TIBCO, Software AG, SAP, Oracle, Progress, etc.]. Of course that’s been a really good area for us as well, because again we’re uniquely suited in many cases to be able to do the proper testing, validation and virtualization of their platform.

“Just as an example of that:  TIBCO themselves use LISA throughout R&D in TIBCO to do the test and validation and virtualization work, so that they can decouple the independent components -- all of these different products that can be put together to create TIBCO solutions. They need to test them independently, and they need to validate them independently and so they do that and use us in all three ways.  Of course that helps TIBCO customers in many ways. 

“A number of our customers are on TIBCO, and on webMethods [Software AG] and on and on (here I go again when naming one I better be careful – (I love all of you guys so please don’t get me wrong) -- and a number of software companies are our partners because of that.”

Mike:  “Is there anything else that you would like to add to our discussion before we wrap up for today?”

John:  “If there was just one thing, it would be:  let’s bring it all the way back to the beginning and realize that this is really about a very key condition and that’s RISK.  That’s business risk and production outage. 

“I have yet to see the customer who is dramatically reducing their level of production outage, in fact it’s going up in many cases and this is a serious concern. Many companies that didn’t even measure risk as much in the past are now obligated to, through compliance regulations.  Because of this they are seeing that so much of their budget is caught up in maintaining the things that are already running, and the expense in keeping it limping along is so great they need to do something about it. 

“That is what we mean by this risk of failure that has been introduced; by so much more complexity and so much more rapid change.  That is why we are in the space that we’re in.  Every time you go SOA -- or every time you introduce some large-scale integration project -- or every time you bring in a new ERP system or you merge with another company -- you are agitating both the complexity and the pace of change.  If you do that without a consummate reaction on the risk mitigation side, that’s why your failure rate is going up, that’s why the cost of maintaining systems is going up.

“So for every one of those activities you are doing, you need to respond with a better, more appropriate, best-practice driven test, validation and virtualization process.  With that you’ll accomplish the change you are trying to make, and you’ll do so without increasing that level of production outage or cost of maintenance.”

Mike:  “Where can our audience go to learn more about iTKO and your LISA initiative?”

John:  “All things LISA and access to white papers and stored webinars and all sorts of things you can find at our web site which is: www.iTKO.com.  And I blog quite frequently and a few other folks with me blog on: blog.itko.com.  You can certainly look at what we’ve been talking about there and you can comment; we’d love to get back to you.”

Mike:  “I certainly appreciate your joining us today, and wish you the best of luck with your future endeavors.”

Outlook Interview Part Four: Virtualization and Testing

Here is part 4 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 virtualization for SOA and how it affects the development and testing teams' productivity.

Mike:  “With this virtualized service edition of LISA.  What are you doing in the area of parallel development and test cycles?”

John:  “What we do is enable that parallel development, because we’re trying to decouple those service providers and consumers from each other during their lifecycle. 

“So a very reasonable approach towards meeting this kind of objective is that I might go through a requirement phase and a design phase and as I start development, I can discover my dependent systems, virtualize those dependent systems and then execute my development plan against my virtual services.  When I do this, I am decoupled from all of those constraints on my peers or on all those other services.

“The reason that I do this is because:  we’ve all heard our development leads say, ‘by the way I haven’t been able to do anything today because the “so & so system” is down.’  Or, ‘remember…they gave us a new build yesterday? Well the new build doesn’t work … they broke one of the major operations. So my team hasn’t had any productive time during the last two days.’ 

“We hear this all the time … this live connectivity to everybody (remember that white board I just mentioned a minute ago?)  Live connectivity to all of these boxes creates a large amount of friction or construction barriers, if you will, in the road. 

“What we can do, by isolating ourselves from that through virtualization, is we can parallel that development activity and, of course as a part of our final integration testing we go from virtual back to live services.  Once we are all live, we can obviously make sure that everything inter-operates the way we expect.  The value here is that instead of having to wait for my dependencies to complete, I can run in parallel with my dependency and get it done faster. 

“A quick example of this is:  If I’m asking you to implement a new feature in your service, I have two choices:  I either ask you to make that change and wait for you to make that change, test that change, produce that change into a build for me and make it available, or I can use a virtual service.

“I can make the change in the virtual model very quickly (we are talking minutes to do this with our product) … and I can be developing in parallel against the virtual version of your service just an hour or two later.  Meanwhile, you’ll take weeks to produce a new version but I’m developing against the new version in parallel in a virtual world.  Once your service is complete, I can point my application away from the virtual edition, and instead to the live edition, and we can make sure that it actually works as we expect.”

Mike:  “When it comes to testing in this area, we certainly want to simulate as many data set combinations as possible to see how effectively that this solution is working; how robust would release be in that area in terms of being able to simulate data set combinations?”

John:  “We’ve spent a lot of time on this.  It turns out … as we embarked on this virtualization strategy, we knew that virtualizing data layers would be a big thing, but I can’t tell you how many times I’ve heard our customers say “this is the big thing.”  It’s because of all this data synchronization, and all of this volatility of data – every team wants to reset the database every time they run their test and every time that they do a development cycle, and that means that no two teams can be sharing the database at the same time, and it’s always a mess!  We’ve spent a lot more time here than we’ve even thought and we’ve solved a lot of problems here.

“A classic example of this is:  When you are working on the purchase ordering system, and the supplier system is your partner, you don’t actually produce the supplier’s service, but you talk to a supplier … and yet you’re supposed to build an application that tightly integrates with your supplier … how do you do this?  Well again, you virtualize either at the behavioral layer or the data layer.  And, why do you virtualize at the data layer?

“Think about it … the supplier could respond to a PO request by supplying all of the requested goods at the requested date with no issue; but the supplier could just as easily split the order, could partially cancel, could respond to you that these items were no longer carried, could warn you with a credit check, could warn you … The number of possible data scenarios in the response to a requested PO -- it reaches the point where we wonder how we can possibly test all these out. 

“Since we can’t drive data scenarios in live systems, we can’t drive data scenarios with our partners -- at least we can’t effectively -- we need to virtualize that database so that we can drive all those.  I can make certain that every kind of possible response to a PO request is available to me all of the time.  That’s what data virtualization does for us.  It makes me able to make certain that every time I need the stars to align a certain way for me to make a certain condition occur, I can do that.  I’m certainly not strong enough to literally make the stars align but, in a virtual world I can, so in that way I can always make sure that everything works the way I expected.”

Mike:  “There are a number of load and performance testing tools such as LoadRunner or SilkPerformer, and a lot of companies have made investments in those technologies, so how can they leverage those investments that they’ve made and expand on those with LISA Virtual Service Edition?”

John:  “That’s absolutely true Mike, there’s plenty of successful LoadRunner shops and SilkPerformer shops and others, and LISA does load testing, but we’re certainly not interested in trying to fix what’s not broken.  We’re certainly quite comfortable with working with companies who are doing load testing with LoadRunner.  A number of our virtual services environment customers are doing exactly that.

“In fact, if you picture in your mind:  the left-hand side of the graphic is Load Runner generating a load on a system in the middle of this graphic and on the right-hand side of this graphic is LISA Virtual Services environment.  What we do is enable more and better load testing even with the tools that we did not provide.  What we’re doing is we’re freeing the system that you’re testing from its constraints.  We’re not eliminating that system nor are we trying to affect the load test product itself.  We’re actually trying to virtualize away the constraints on the right hand side of the graphic. 

“So, it’s LoadRunner, versus the System Under Test, which can be LISA … and that triad, if you will, makes for a very powerful load testing combination.  What we have found is that you have to have production hardware or at least a reasonable production performance lab for your own application. 

“Our customers understand this, what they have trouble with is:  ‘Wait a minute, my application no longer lives on its own island, it now goes and invokes its own transactions on a main frame or it now integrates between a TIBCO-based system or this web message-based system and it goes and talks to this ERP system.’ 

“In order for me to performance test my application, my performance lab just went from a half million-dollar investment to a five million-dollar investment … and that’s what they can’t do.  So when you go Load Runner/Your Application/LISA, you eliminate the five million-dollar investment. You literally eliminate it.  What you go from instead is the half million-dollar investment in your hardware platform -- what you have to run your application and your service on, and we virtualize away all the heavy iron that you have to connect to.  We put that on a commodity box, what would be a rounding area on a half-million dollar investment -- we would run on a $20,000 server.”

[This concludes part four. In the next post we wrap up the interview and provide an overview of ITKO.]

Outlook Interview Part Three: Performance Management and Testing

Here is part three of the 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 performance management and testing.

Mike:  “When it comes to really achieving business value from IT investments, lots of folks will really look at performance.  Can you give us some background on some current performance management strategies that are out there?”

John:  “I can compare that to what our traditional approach to performance management has been and again, if in the old world, entire applications were produced and then they were performance-tested in a lab and released for production.  This worked okay when the thing we built was a 100% self-contained thing. 

“But now back to an analogy of a service-based architecture, where I am producing applications that consume services from you, Mike.  What do you do to performance test or to manage the performance of your service?  You are no longer a complete application.  I can’t ask you to produce your service, and send it individually into the performance lab if the performance lab hasn’t retooled?  I’ve got to think about performance testing at the services layer.  I’ve got to think about the performance testing even at the orchestration layer.  By that I mean there may be two or three services that collaborate to make one business process or even one sub-process of the business function. 

“Once we start to think about performance management, now that I’ve broken my big box application into a number of components; I’ve got to do the same thing with performance.  I’ve got to break my run-time SLA into the component-level SLA  (Service Level Agreement) that’s basically my performance and resource expectations that I’ve put on my applications.  So, Mike, I might need to do something that we call decompose the SLA where my application must run at 2 seconds or less response time for the user.   

“If 2 seconds is what I have -- I need to get your performance under 2 seconds so that I can meet my SLA.  Your response time is a component of my response time, because I am invoking you -- I am dependent on your service.  What I need to do is negotiate (for lack of a better phrase) your SLA with you--we call that decomposing the SLA.  You need .5 seconds, then my application can consume 1.5 seconds, and therefore, I can meet my overall SLA.  This is in many ways a new way of thinking about performance than previously.   We used to just think about 2 seconds -- we dropped the application in a lab to see if we had 2 seconds.  Now Mike’s team has to go to the lab and has to meet .5 seconds, and my team has to go to the lab to meet not 2 seconds but 1.5 seconds. I’ve got to make sure that my 1.5 seconds will combine with your .5 seconds.
Make sense?

Mike:  “Once you have an application completed, a lot of times they are difficult to tune for performance.  What are you specifically doing to address that?”

John:  “This notion of taking our SLA apart into components actually helps us do this.  It does for a couple of reasons the biggest is:  if we can performance test within the life cycle, if we can do our testing as a part of our own development than we can find and resolve our performance issues much more quickly.  In my experience, and I bet many people in the performance field will nod in agreement, so many times if we build an app that does not scale and then try to tune it into scalability, the best we’ll do is 10 or 20% improvement.  You can’t add hardware and make a product that is un-scalable all of a sudden scalable--it just doesn’t work.  If you had known earlier where those scalability issues are--than you can build in the scalability along the way a whole lot easier.

This is essentially the same reason why we iterate from a requirements definition standpoint, because the more we iterate thru the scope of our work the better we are at delivering on it and the faster we are   The same is true with performance, we have to iterate and we have to do performance testing at the component level in order to get that performance up and the scalability up.”

Mike:  “Are you doing anything to address the challenge of discontinuous development cycles?” 

John:  “Yes.  Because of the fact that you may be building your component at a different lifecycle pace than my application even though I am a consumer of your component, (usually we call that service) our challenge is that I got to have access to your service maybe at a time you don’t even have it ready for me.  You might have down stream dependencies of your own.  As soon as I think of you as “Order Management” -- you might turn around and say: Yes, I do order management but I sit on top of the customer database that I don’t own, and I sit on top of the ERP system that I don’t own either.  So, you have your own set of dependencies.  So if we actually fit it on a white board, most large-scale enterprises would literally fill a white board with very small little boxes all interdependent on each other and they are all iterating on their own life cycle.  It drives me nuts just thinking about how anything actually works!

“So in order for us to support this kind of distributed lifecycle, we’re doing a lot more virtualizing of the components underneath each other. 

“What we mean by this is:  since I am invoking your service, I am dependent on your service, but what if your service isn’t available to me yet, what if I need you to change your service and your changes aren’t ready yet?  What if I need to do performance testing of my application on an interim basis but I don’t have scalable production quality hardware to run your service on?  Or, maybe worse, maybe your service talks to the mainframe, but I don’t have availability of mainframe resources to do this?  All these are what we call constraints.  These are real world constraints which we are dependent upon. 

“What we do is:  we virtualize the behavior of these things.  What I will do is construct a model (our LISA Virtualize product is really good at doing this) -- it constructs a model of the behavior of your service, and once that model exists I can run that model in a virtual environment, it doesn’t have to have the real world constraints; it’s a virtual thing.  So, if I need it early, I’ve got it. If I need it to scale to 500 transactions a second, I can do that. Even though I don’t have production type hardware for your real service, I can virtualize it and get the kind of performance that I’m looking for.” 

Mike:  “It sounds like you would be able to provision the right hardware and platform for a given solution then.”

John:  “Right, because what we do is that we dramatically reduce what that requires.  A classic example for one of our customers is:  I’ve got an application that is a portal-type application that invokes a set of services.  Some of those services talk to SAP.  SAP is a great ERP system and many large organizations use it; but of course we don’t want a lot of performance and load testing type transactions against that system.  We don’t always have availability when we need it.  We don’t always have the data in the database when we want to -- SAP testing is a very complex field -- so there are all kinds of real world constraints.  What we do is we virtualize the behavior of SAP and in doing so, your portal has access to what it needs 24/7 and I don’t have to provision the entire SAP environment to do it.  All I have to do is provision my own application, we can’t virtualize away you --but we can virtualize away your dependency. and once we do that, we decouple you away from a lot of the challenges that those constraints have.”

Mike:  “When it comes to performance labs, it seems like a lot of them really rate data management as a very big problem.  What can you tell us about dealing with that challenge in leveraging LISA?”

John:  “One of the great challenges with data in performance labs … is really two challenges. One is that you can never talk to just one database in a performance test. You are usually dealing with multiple data sources.  For example (as I mentioned a minute ago), order management is dealing with a customer database in one system and with the orders database, let’s say, underneath SAP -- so here’s two completely independent systems that are now interdependent on each other with regard to data.  Now here I am in a performance lab and I’m trying to support hundreds of scenarios of real world use of my application.  In order to do that, I need the data between those two databases populated in a certain way and synchronized between each other and whatever changes are made in one database, I need those changes to be reflected appropriately in the other database.  Do you know how often this happens? Much, much less frequently than Christmas! 

“What we have is a dynamic that we see all the time, you’ll go into the performance lab wanting to do some 100 different scenarios of use, these are all the use cases you want to be sure are performing and scalable in your application; but by the time you figure out just how to get all the data to synchronize between these two systems, the best you’ll come out with is about 20.  Now the problem is that you’ll performance test just 20 scenarios, but you’ll go to production with all 100.  You’ll find out the hard way whether the other 80 are a problem or not, because your real world users will be doing those other 80 (the one’s you couldn’t performance test) and the problem is:  if you have scalability or performance or resource issues in those other 80 … then you have a problem.”

Mike:  “When it comes to best practices in the area of performance and load testing, what can you tell us about decomposing performance expectations?”

John:  “I gave a quick example of this earlier, I’ll elaborate on this a little bit. 

“If the production SLA for a particular application; let’s say mine is 2 seconds…that’s the example that I gave previously … where my response time to my user is 2 seconds … but one of the things that my application does is to consume services from your team, Mike, I need to negotiate your response time as a part of my response time.  So what I do is decompose that SLA.  What I’ll do is say, ‘okay, I’ve got to make sure that I can get Mike’s service calls in a short enough amount of time so that my application overall’ -- once you add up all of the time consumed – it doesn’t trip over our expected response time. 

“So we help by giving the customer the ability to do two things.  The first is:  we’ll help them do performance testing at the component level.  Mike, you can performance test your service.  You can say, ‘hey John, I can hit my half-second response time metric independent of you.  I owe you the right functionality at the right performance.  I can functionally test this system to make sure it works and I can performance test my service (independent to the rest of the world) at .5 seconds so I have done my job.’

“Now, I come into the picture and I can do performance testing on my application and make sure I hit my SLA as well.  In order for me to hit my SLA, I have to take you out of the mix. That’s why we talk a lot about virtualization in the performance lab. 

“So second, I can simulate your service’s behavior and I can even simulate your behavior at .5 seconds.  I can say, ‘alright Mike’s virtual service; I want you to behave like Mike’s virtual service, and I want you to take .5 seconds whenever you respond to me.’  By the way, I can even say ‘what if.’  What if your response time takes .6 seconds, what does that do to my overall response time? What if you’re actually running a little faster at .4 seconds …what does that do to my response time? 

“Sometimes the fastest way for me to get better scalability is to negotiate you a little faster so that my application hits its SLA:  stuff like that.  So that’s why performance testing as a component and virtualizing married together really give you a solid foundation for performance management in SOA.”

Mike:  “We had mentioned provisioning before, how does that come into play in terms of optimizing provisioning relative to managing performance; should one be done before the other and how is that relevant?”

John:  “The relevance is that we need to be able to capture virtual services as a part of the provisioning activity.  Where in the past, I needed the entire SAP system to be available for provisioning, now I just need the virtual services that encapsulate the behavior of SAP; I need that to be the provision item instead of the whole SAP system. 

By the way, when you think about these large-scale applications, often there are not only many servers with a very specific and complex kind of configuration, but there are huge databases underneath these big systems.  So very frequently we have customers tell us that they can’t do development work against this massive system because it’s got a terabyte-sized database underneath it.  In order for me to get access to it, I have to wait till midnight to 2 a.m. because that’s the only time they will give me time on the system. When I try to do performance testing, they refuse to let me because in order to avoid impacting production, they limit the amount of non-production activity on that particular system.  All of these kinds of constraints are those very same kinds of things. 

“So, back to provisioning, if I need access to this particular database or this particular large application that spans many servers, I encapsulate all that behavior into one virtual service and I can provision that one unit to represent that entire set of systems.”

This concludes part three. In the next post we cover virtualization and testing.

Outlook Interview Part Two: SOA Testing Best Practices

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.]

Chris Kraus

Chris is an expert testing and architecture strategist, with an 18 year background in computer software development, product management, and sales support for enterprise software.  As Product Manager for iTKO's LISA suite, Chris applies both project management and development experience to refine LISA features to best suit customer quality needs throughout the software delivery lifecycle.

Chris was previously a Retail and Manufacturing Industry Manager at the enterprise software platform firm webMethods, overseeing requirements, customer presales and training for the $16M annual group. At supply chain software provider i2 Technologies he worked in i2's infrastructure group, with responsibility for the release of business process, workflow and monitoring engines. Prior to i2 at Software AG, Chris specialized in cross platform product installation and administration.  As a software engineer, project manager, and solution architect, Chris has a great breadth of industry knowledge from working with companies like Citi, TD Ameritrade, Lenovo, Tandy, Rubbermaid, TI, and TxDoT to ensure quality application delivery lifecycles. 

iTKO LISA 4 Released, and here's my speech...

Warning: I'm taking a break from my usually pitch-free blogging to talk about our latest product release.
I tongue-in-cheek tell people that my day job is to run R&D for iTKO. It's true, but given that I am writing this blog on a flight that is day one of 6 weeks of covering the globe to discuss SOA Governance, Testing, and Validation with customers, prospects, conference attendees, and analysts, I think I need a better analogy than 'day job'...

Yet despite my inability to see my team face-to-face, my team continues to deliver an amazing amount of product enhancements; the latest release of LISA 4.0 is just another example of that.

We are always listening to customer feedback and incorporating changes. If you are an iTKO LISA user and have provided comments on a way we could improve our technology, I would bet most every one of you will be pleased to see your input reflected in this release.

And while we are certainly doing a significant amount of tactical improvements, we have delivered major improvements in one area and two whole new product capabilities unique to the market. See why I love these guys?

Load Testing: There is a product in the load testing area of our space that is quite dominant, and for good reason; it's a great product. In fact, many customers who adopted LISA for all their functional test and validation needs still kept this existing load testing product. We have been working with them to ensure that this is no longer required. Some still will and that's just great, but many will prefer to take that Collaborative 'C' to heart and perform all their testing from the same product.

LISA VSE: We have introduced the LISA Virtualized Service Environment, or VSE. Wow this is way more than just a new TLA. If you've been reading this blog long you know I'm all about leveraging virtualization for SOA. I'm working on a white paper with Jason English for publishing in the next few weeks on this, as it goes beyond what VSE does when you apply it as a business development practice. In short, it's a dramatic improvement in how teams can better decouple for agility and how to eliminate the contention on all those shared resources during design/dev/test time. I highly recommend you ask us what we are up to
here.

And finally, we have produced a technology for getting much better visibility into the transactional behavior of business processes we call Pathfinder. This is one of those see-it-to-believe-it things, so again, check it out.

Maybe the best part is we are so far from done I can't help but want to turn the plane around and start telling the guys what else to get started on....

SOA is still an immature technology pattern. Most teams I find are still struggling to get it right. And so much of what the market is still using are no more than repackaged traditional tools. No wonder it's harder than you think it should be ;)

Pardon the LISA commercial. You'll see I do very little of that in this blog. Yet I'm convinced that SOA is scary without LISA on the team. For those who can do the math on an ROI, you owe it to yourselves to check out the full-featured LISA 4 SOA Testing & Validation suite.