The single reason that you use IT within your organization is for service enablement. IT has proven itself to be essential to provide the levels of service that customers demand. Implemented well, the operating costs of IT systems provide many opportunities to serve customersâ€™ needs and provide operating margins commensurate with the profitability demanded by the organizationâ€™s stakeholders. Now, the concept of business services is being embraced by enterprise IT organizations through the adoption of the Service Oriented Architecture (SOA) paradigm. SOA is ITâ€™s response to the demands from the business that IT be more in tune with the needs of the business. By moving from a software systems development paradigm to a business service development paradigm, it is hoped that IT departments and business units will become more aligned. This holds out the promise of business and IT being able to cooperate and manage together using a set of shared principles and a common understanding of the overall business objectives. If you are implementing, or considering implementing, a Service Oriented Architecture (SOA) within your organization, there are some simple questions you must ask. Firstly, what does SOA mean to you? Secondly, what are the business benefits you expect to accrue from your SOA implementation? Finally, if you are currently implementing SOA, how do you know that the implementation is on track to deliver the promised business benefits, on time and on budget?
What does SOA mean for you?
If SOA is the vision and the way forward provided to you by your suppliers, then â€˜caveat emptorâ€™ (buyer beware!) applies to you. We all want to have â€˜A Good Thingâ€™ and SOA does have a lot of potential to be â€˜A Good Thingâ€™ but SOA has become a rolling bandwagon, taking many to a place where they really should not be. There are many IT products and solutions currently in the market that lay claim to the SOA tag. With most, they could be useful for building out SOA but they are not a complete SOA solution. SOA is not simply an enabling technology that solves myriad business problems, nor is SOA lead by the technologies used in its implementation. Fundamentally, SOA is an IT implementation strategy that aligns the provisioning of IT services along the lines of the structure of the business. In many organizations the development, procurement and provisioning of IT systems are governed by policies which address technology issues. Corporate or Business Unit standards are created that try to bring commonality to both IT infrastructure and development by mandating particular databases, application servers, development languages, network components and so on. While many of these initiatives are perceived as sensible, cost-effective approaches to the containment of IT budgets, they do not actually relate the activities carried out in IT departments to the wider organizationâ€™s business imperatives.
SOA is seen by many as the first integrated approach to building IT systems that reflect the structure of the business and allow IT managers to relate better to the needs of the operational business managers. While this may be true, and the benefits touted by SOA solutions vendors may be achievable, there should be a sober understanding of the risks and issues that can arise when an enterprise embarks on re-engineering its IT strategy, and project delivery mechanisms, around SOA. Nowhere better to do this is within the IT QA and test processes. There are only two places within any enterprise where the IT systems can be shown to meet, or fail to meet, their business and operational requirements - either during the operational phase or in the test phase of the software development lifecycle. In the past, individual projects stood or failed on their own. Potential delays in the delivery of the system would be evaluated on their individual merits and, where delays threatened the viability of the business plan that was relying on the system, projects would drastically reduce the testing and move to the operational phase. The increased risk of operational failure was accepted, as the failure to deliver anything was seen as an unacceptable option which would simply guarantee business failure. So, in a distributed development environment, delivering low quality systems on time was often seen as more acceptable than delivering high quality systems late. This mind set must change with SOA. The QA and testing function must stand as the gatekeeper into IT operations. Quality objectives must be set corporately and adhered to, as poorly operating services risk bringing the entire organization to its knees.
Changing the Testing Landscape
Moving to SOA is a seismic shift in IT strategy for most organizations. It should come as no surprise that the landscape will change as SOA is embraced across the whole of an organizationâ€™s IT. Do most people know what the new landscape will look like? Almost certainly not. The early adopters have the potential to reap rewards while the IT majority take stock of the situation. However, the first movers have limited experience to rely on and must mobilize to mitigate against the unexpected. This is why appropriate QA and testing strategies must be created, some of which are highlighted here. The Testing Center of Excellence In other areas of IT, the Center of Excellence (CoE) concept has been applied quite successfully in many organizations. This approach can also be used as a test strategy, where testing for both the SOA service providers and the service consumers creates a central capability where test assets can be maintained, managed and reused across different projects. No longer do different test teams need to spend redundant time relearning service interfaces across the enterprise. The Testing CoE can be structured so that there is a single repository of requirements, specifications, tools and test assets to understand and test the entire enterpriseâ€™s SOA services and supporting infrastructure.
Read the complete white paper Ensuring Service Enablement from SOA.