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

Sizing the Opportunity for IT to Cut Carbon Emissions

A recent McKinsey report, How IT can cut carbon emissions, reported that the carbon footprint associated with IT, including laptops and PCs, data centers and computing networks, mobile phones, and telecommunications networks, could make them among the biggest greenhouse gas emitters by 2020. IT now accounts for 0.86 metric gigatons of emissions a year, or about 2 percent of the emissions added to the atmosphere globally. However, the McKinsey report predicted that the increasing need for IT could significantly drive up that figure.  They write, “by 2020, they (IT) will account for about 3 percent of all emissions: 1.54 metric gigatons, or twice what the United Kingdom produces today.” The report adds that, “the adoption and use of information and communications technologies in China, India, and other developing economies will account for much of this growth.”

As a Baylor alum I recently had a chance to attend a BBN talk with HP's CEO Mark Hurd, and he put it in an interesting light. Our hunger for accessing, using and storing data is increasing exponentially every year - and it is moving faster than Moore's law - the exponential increase in how much data our processing systems can effectively manage. That puts a lot of attention on innovating to reduce heat in high-powered processors, and the energy consumption associated with trying to keep it down. We will need to continue to innovate in reducing the energy cost of all of that data in the data center with more efficient systems.

On the good news side the McKinsey report said that there is the potential for IT products to help abate far more emissions in the general economy than their own production and use generates. The authors looked at things like smarter use of energy in buildings and greater efficiency in motors used in manufacturing. However, they also studied the possibility of reducing emissions by “dematerializing” physical goods and processes through telecommuting, video conferencing, Internet shopping, and downloading content rather than physical objects using paper, CDs, DVDs and found that there are great opportunities here also.  They concluded that information and communications technologies that promote abatement will “create attractive growth opportunities for those companies.”

This is good news as Virtualization (another way to say dematerializing) is a major opportunity for SOA to help with the global warming crisis. We have written about the opportunities for greater business efficiency with virtualization (e.g., Outlook Interview Part Four: Virtualization and Testing and  Can Virtual Environments take Performance & Load Testing?  This all leads to energy efficiency as less power is used by factors of ten or more when you can virtualize aspects of testing and validation. Here is another positive impact that may increase market demand for more environmentally friendly technologies.  Joe McKendrick recently discussed the cost saving side of SOA in his post, Service Oriented Architecture on $10 a day, and how it might do well in today's down economy. "Web services were forged in the dot-com era, but were, quite simply, pressed into service as a very low-cost way to work around very complex integration projects with reusable code."

Joe goes on to provide some good advice on SOA in a down market. This all can start by starting “with the smallest business process you can find that is the most inefficient, where the inefficiency is caused by an aspect of continuous change (a lack of agility) and the business is nevertheless forced to continue to invest in that inefficient business process.”

Of course all of this is an adjunct to the things we can personally do to reduce environmental impact. Especially in business - companies are now more compatible than ever with telecommuting, and "virtual meetings" which can have a dramatic impact on our carbon footprint.

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. 

Finding the Blind Spots in SOA Testing

Colleen Frye recently wrote about the consequences of overlooking SOA testing blind spots at SearchSoftwareQuality.com. She reported on an interview with ITKO’s John Michelsen, and Crosscheck's Rizwan Mallal, Green Hat's Madeline Bayliss, and Scott Barber, chief technologist of testing services at PerfTestPlus.

John said that unintended consequences result from failing to test the dependencies in SOA applications. The solution is not to retest all the services that have already been individually tested, but to conduct a test of the business process in context. Then you have to do continuous validation at all phases to guard against the effects of changes to a service.

Another potential blond spot mentioned in the article is the reliance on HTTP return codes to determine the success of an operation. You need to perform deeper content inspection. Another blind spot can occur when testers ramp up load by simply sending duplicate WS-Security-enabled message. Scott said that testers need to be careful to test all kinds of potential malformed data input and this is often overlooked. He added that testers need to look more carefully when third party services are in use.

John concluded that while quality still belongs in QA, the development team and the IT governance group also have responsibility. It was a rich conversation and there is more at Colleen’s post.

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. 

Application Development in the Clouds - Mike Vizard and John Michelsen

Mike Vizard at eWeek recently hosted a podcast with ITKO’s John Michelsen, on "Application Development in the Clouds." In this conversation, John and Mike talk about how cloud computing is going to upend the way IT organizations think about SOA and application development in general.

Mike started by mentioning the increased number of dependencies that SaaS brings to SOA testing. John said Mike really nailed the problem - it is something we are seeing in every engagement that relies on third party or shared services environments. The traditional waterfall method, and its assumptions, are now all undermined, and so much rethinking needs to be done. But the effort is worth it.
Mike, as seen on the left, next discussed the increased reuse happening in SOA. This broadens the need for trust. John, as seen below on the right, said that SOA requires good governance policies. In most organizations vertical trust already exists, as teams within groups and authority domains inherently trust each other.

Now with the need to go across the enterprise, and even to third parties and partners, horizontal trust comes into play and this is usually not in place. Service level governance can handle this issue and there are good frameworks available (in the form of SOA Registry/Repository solutions like Centrasite and Systinet). However, each organization will have to customize these frameworks for their unique environment, and think about how those teams can have a common way to validate that expectations are being met.
 
John added that SOA Governance needs to extend to the consumption of services, and this is where most organizations fall short. There is "no free beer" in consuming services - so if you have an intended workflow, that also needs to be validated. After all, is the business use case realistic, and how will the provider of services be compensated?

Mike asked about how these services be validated on a continuous basis, as the services may be constantly upgraded after deployment. John replied that LISA includes continuous validation since many applications allow for ongoing modifications. You need to test for the "unintended consequences" of these modifications.

Mike asked the need for visibility into services. John responded that this need is at the Behavior level to see if the desired behavior remains the same after changes in the application. This is where continuous validation can generate trust and allow for SOA in business critical functions.

How much time needs to devoted to validation, versus building applications? If there is too much time required for validation, developer productivity falls down. John said that this is where automated testing can play a key role and it needs to address dependencies.

Mike asked how developers can be encouraged to adopt this new thinking around continuous testing. Will a new generation of developers be required? John said that this approach is more evolutionary than revolutionary. However, most test organizations need to think in a new way.

Fortunately, there is greater awareness of this need than was in place a few years ago, when much of the SOA Governance conversation was only around Structural testing, for WSDL standards, WS-Security, WS-I etc., which are very important, but just one piece of the puzzle. The idea of design, change and runtime policies that incorporate behavioral and performance Policies and SLAs are now in focus. 

I have touched on the highlights. Go to the complete podcast for the details.

Real time from SOA/Cloud/Virtualization World - Plaques

Hey, we are here in San Jose for SYS-CON's "super connection" show of SOA World / Virtualization Conference / Cloud Computing Expo (and probably a few others). Rajeev is going on in about an hour to talk about "Peeling the Onion" of SOA.

I just got down to the booth and had 2 surprises:

• (uh-oh) Where's my signs? (I'm sure we'll sort that out in a bit.)
• (great) However, HEY, the nice folks here gave us 2 nice pieces of decor which really brighten things up - award nominations for LISA Virtualize:

- SOA World Show Awards 2008: Best Integration Solution
- Cloud Computing Show Awards 2008: Best Cloud Management Solution

Much thanks to SYS-CON for brightening our week here. We have been excited about the capabilites and future for LISA Virtualize - going far beyond our known presence in SOA testing & Validation.

SOA in Action Virtual Conference Preview - Panel tomorrow

I recently had a chance to talk with Peter Schoof at eBizQ about the upcoming SOA in Action Virtual Conference (free signup here) on November 19. You can listen to our discussion and/or read the transcript at this post, The Acceleration of SOA: iTKO Explains.

I mentioned here we had a very productive SOA governance conference last month with John Michelsen sitting on that panel – see SOA Governance Panel Recap: Federated SOA for the Day. We had a lot of good questions as a result but they're mostly around how do I manage or architect my services.

We are part of a Roundtable session on "Disillusionment in SOA" that should both support and debunk a few rumors about the real issues companies are struggling with as SOA acheives more adoption.

I imagine the discussion might go a lot more to the brass tacks like: How do I actually test multiple layers of SOA, how do I orchestrate these services, what constitutes a Policy, and how am I actually validating that that policy is being met as the services are constantly changing?

The roundtable closes out the session at 2:00PM. iTKO's Chris Kraus (LISA Product Manager) will be on the panel with Joe McKendrick, Phil Wainewright, Dr. Chris Harding, Jignesh Shah, David Bressler.  Keynote speakers throughout the day include Yefim Natis, Gartner Research; Maneesh Joshi, Oracle; and Randy Heffner, Forrester Research.  

Please join us - no travel needed. Thanks to Immo Hüneke for mentioning it. If you are walking the "virtual floor" come by before or after the roundtable, and ask us a question or grab a virtual tchochke.

iTKO talking at SYS-CON's SOA - Virtualization - Cloud Computing Event Nov. 19-21

SYS-CON Events announced today that more than 40 Cloud technology providers, as well as Virtualization and SOA companies will exhibit at the upcoming First International Cloud Computing Conference & Expo on November 19-21, in San Jose, California. It's co-located with SOAworld West and Virtualization Expo - so attendees can pick and choose topics from all three agendas. We will be there and we're looking forward to seeing how practitioners will bridge these three disciplines.

iTKO's Rajeev Gupta, Director, Solutions Delivery will present at 9:00 AM on Thursday, Nov. 20 - on "Peel the Onion, Lose the Tears: Test, Validate and Virtualize Every Layer of SOA" at the Virtualization Conference. The session will provide best practices and real-world examples of our customers that are testing, validating and virtualizing every component of the architecture, across multiple teams, on a continuous basis, to ensure trust and reliability.

A lot of the Cloud is seeping into the practice of both SOA and virtualization. This makes a lot of sense, as SOA is by nature decoupled and leverages distributed software components and logic, much of which will be hosted in the Cloud (see eBay, Google, SalesForce and others we use every day). At the same time we are seeing a need to Virtualize the behaviors of critical Cloud-based services such as transaction and inventory systems, to help teams reduce the cost and dependencies of developing and testing against them.

SYS-CON points to the growing market in cloud computing. Over the next five years, IDC expects spending on IT cloud services to grow almost threefold, reaching $42 billion by 2012 and accounting for 9% of revenues in five key market segments. More importantly, spending on cloud computing will accelerate throughout the forecast period, capturing 25% of IT spending growth in 2012 and nearly a third of growth the following year.

LISA Eclipse Edition released - TVV in the IDE

Developers are increasingly being asked to provide more test coverage, and design more testability into the components they are delivering to the business. So why not provide a side-by-side way to code and build apps - and - create and execute tests against them, within the same development environment?

Tomorrow we are officially releasing LISA Eclipse Edition - it's a real edition of our LISA 4.5x product running inside the Eclipse UI. We've had a lot of customer demand for LISA as a first-class-citizen of Eclipse, and it joins our cross-platform Java standalone version of LISA that runs in Windows, Mac, and Linux/Unix client flavors.

I had a chance to talk with SD Times' Jeff Feinman in advance of the release, about some of the benefits of having the IDE of Eclipse working hand-in-hand with LISA's live testing and validation capabilities. Jeff posted a good article on the topic today here: "iTKO integrates Eclipse into LISA, allows for more testing"

Enough of my product marketing hat for now... Many kudos to the LISA development team and here's the official press release: "iTKO Releases LISA Eclipse Edition for Complete Test Coverage within the Application Lifecycle"

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.