There is little question that today's development teams are facing numerous new challenges and that often these challenges are being driven by business rather than technology considerations. Companies are under considerable market pressure to roll out new products or services, putting developers under increasing pressure to build and deploy the IT systems and applications necessary for success. Service-oriented architecture (SOA) promises to address many of these challenges by allowing developers to incrementally deliver new business capability while leveraging existing assets. But developers must beware: one of the most notable areas where roadblocks and bottlenecks can occur if development teams are not careful is in the quality assurance (QA) and testing process, which unfortunately, is one of the last considerations in the development and deployment of enterprise systems. By using agile practices during QA and testing, SOA teams can turn these roadblocks into opportunities.
Unfortunately for developers, businesses are finding that the market is more dynamic than ever, creating an ever-moving target and a consistently changing set of IT requirements. Fortunately for these stressed out developers, there are a few different methods companies are adopting to address these serious challenges and to promote greater IT and business agility. Development teams are increasingly distributed, taking advantage of in-house, outsourced and offshore resources to alleviate resource constraints and bolster productivity. In addition, the movement to SOA, which leverages the use of loosely coupled, reusable services to more rapidly build and deploy composite applications, is gaining momentum. However, neither distributed development teams, nor SOA, should be considered a panacea. If not approached thoughtfully and carefully, any loosely-coupled architecture and/or development organization can introduce even greater hindrances and roadblocks to the business and technical agility being sought.
SOA Addresses A Multitude Of Challenges
While there is little question that distributed development teams can alleviate resource constraints, the process can also introduce unforeseen problems. Geographically distributed {sidebar id=1} teams are often isolated from each other, working on discrete requirements without always having the benefit of knowing the larger scope of the project. Couple this with an organization moving to SOA, and you may be faced with a development team building services that will eventually be used by other services or end-applications that do not yet exist. In turn, these services will likely rely on other services and applications that are still in development. These dependencies between various components or services can result in serialized development, complicating the testing process and adding unnecessary delay to the entire project should any team fall behind schedule.
SOA is not simply about building reusable services from scratch. One of the considerable strengths of SOA is the ability to more easily leverage existing systems and applications in response to changing business dynamics. Key to the success of this computing model is the ability for functionality already present and working in the enterprise to be brought to bear against new business challenges. But this considerable strength can create complications in the QA and testing process if not prepared for in advance. Development teams building new applications and using new technology often find it difficult to test against systems that are already in production and to test across the multiple middleware technologies found in the typical enterprise. Add to this the complications that arise from system interfaces that are ambiguous, incomplete or out of date (or all three), and your ability to test new services against existing systems becomes increasingly complex.
SOA Eases QA And Testing
The good news for developers working in SOA environments is that the very principles that enable this computing paradigm to be possible can also significantly improve the testing and QA process, promoting faster development time and ultimately faster time to market. SOA, at its most basic level, is about hiding the complexity of underlying systems through an agreed upon set of contracts and interfaces. It is also entails thinking very differently about what developers are being tasked to deliver. The application is no longer the unit of deliverable work. Developers are being asked to now to deliver services that execute specific functionality and can then be assembled into a nearly infinite combination of "enterprise applications," with the contracts and interfaces defining how the services will interact with the larger system. Project specifications can be broken apart into logical, easily digestible pieces defining the services, contracts and interfaces for each development team.
But how does all of this allow for the improvement of the QA and testing process of companies undertaking a migration to SOA? One of the key tenets of SOA is the agreement on interface service contracts generally defined in Web Services Definition Language (WSDL), independent of the actual technology used to implement the service. One of the key tenets of an agile development methodology is "test first." The possibility for an improved QA practice lies in combining these two approaches: taking advantage of the rigorously defined interface definitions to enable early interoperability testing for consumers of services.
The first step is to establish a process for formalizing interface agreements for the various services comprising an application using WSDL. This can be augmented with text design documents, but having these interfaces specified in a formal language is critical. These contracts (both WSDL and text documents) need to be managed in a repository that is accessible by the various development teams, regardless of their location.
The next step is to generate, for each service contract, a simulator that can be used by consumers of the service to verify that their use and assumptions conforms to the published contract. Generating these simulators (complete with dummy data sets) is made possible by defining the interfaces using WSDL since the combination of WSDL and XML Schema actually provide enough information to drive either code generation or interpretive simulation. These simulator "kits" should then be available for download from a common repository, or the organization can choose to set up one or more test servers on which these simulators are deployed.
Agile SOA Development
Clearly, any process must allow for iterative development - the reality is that interfaces will change during a development cycle. However, by establishing a process and culture whereby development teams are thinking in terms of services and service contracts and taking advantage of repositories, RSS and other collaborative development technologies, it is possible to set up an agile SOA development process.
The idea is simple and it can be no more than test first methodology being applied to SOA. The challenges, as always, are more organizational and social than technical. Without a mandate for each team to deliver well-documented interface agreements and simulators or alternatively, funding a centralized group to ensure that the agreements and simulators are in place, this approach will clearly not work. Our experience with leading IT organizations has shown, however, that this approach results in faster time to market with lower defects, so there is a tremendous ROI benefit to adopting it.
The ongoing adoption of SOA and distributed development models promises greater productivity and greater capability to respond to changing business dynamics. However, these changes can also introduce new bottlenecks that can easily wipe out the benefits of agility and time to market. By thinking in services at all phases of the development lifecycle, and focusing attention on the contracts and interfaces that are the foundation of SOA, development organizations have the power to automate QA and testing much earlier in the process and provide better opportunities to truly reap the benefits of SOA.
About the Author
Stephanos Bacon joined IONA (www.iona.com) as Vice President, Product Development in 2005. Prior to joining IONA, Mr. Bacon served as Vice President, Engineering for Avaki Corporation, a provider of Enterprise Information Integration products. Mr. Bacon has also held senior product engineering positions and managed distributed engineering teams with companies including Broadvision, Object Design and Bachman Information Systems. He gives special thanks to Tony August for help in writing this article.
