So, does testing change with SOA? You bet it does. Unless you're willing to act now, you may find yourself behind the curve as SOA becomes systemic to all that is enterprise architecture, and we add more complexity to get to an agile and reusable state. If you're willing to take the risk, the return on your SOA investment will come back three fold…that is, if it is a well-tested SOA. Untested SOA could cost you So, does testing change with SOA? You bet it does. Unless you’re willing to act now, you may find yourself behind the curve as SOA becomes systemic to all that is enterprise architecture, and we add more complexity to get to an agile and reusable state. If you’re willing to take the risk, the return on your SOA investment will come back three fold…that is, if it is a well-tested SOA. Untested SOA could cost you millions. Truth-be-told, testing SOAs is a complex, disturbed computing problem. You need to learn how to isolate, check, and integrate, assuring that things work at the service, persistence, and process layers. The foundation to SOA testing is to select the right tool for the job, having a well thought out plan, and spare no expense in testing cycles else risk that your SOA will lay an egg, and thus have no creditability. Organizations are beginning to roll out their first instances of SOA, typically as smaller projects. While many are working fine, some are not living up to expectations due to quality issues that could have been prevented with adequate testing. You need to take these lessons, hard learned by others, and make sure that testing is on your priority list if you’re diving into SOA. So, how do you Test Architecture? The answer is, you don’t. Instead you learn how to break the architecture down to its component parts, working from the most primitive to the most sophisticated, testing each component, then the integration of the holistic architecture. In other words, you have to divide the architecture up into domains, such as services, security, governance, etc., and test each domain using whatever approach and tools that are indicated. If this sounds complex, it is. Indeed, the notion of SOA is loosely coupled complex interdependence, and thus the approach for testing must follow the same patterns. What is unique about a SOA is that it’s as much a strategy as a set of technologies, and it’s really more of a journey than a destination. Moreover, it’s a notion that is dependent upon specific technologies or standards, such as Web services, but really requires many different types of technologies and standards for a complete SOA. All of these must be tested. You can group the testing domains for SOA into these major categories: Service Level Testing Security Level Testing Orchestration Level Testing Governance Level Testing Integration Level Testing The categories or domains that you choose to test within your architecture may differ due to the specific requirements for your project. Moreover, there are other areas that need attention as well, including quality assurance for the code, performance testing, and auditing. At the end of the day you’ll find that SOA testing incorporates all of the testing technology and approaches we’ve developed over the years for other distributed systems, and adds some new dimensions such as services, orchestration, and governance testing. Those who understand testing will have to expand their skills and understanding to include those new dimensions. Many failed SOA projects are directly attributable to lack of testing…many assuming that the new technology would work flawlessly. Unfortunately, that’s just not the real world yet. Software Development