Ensuring Service Enablement from SOA
Submitted By: Ashok Mani
AppLabs
Introduction
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.
While there may be additional effort required to plan and manage test asset and resource allocation, the benefits to be realized from the additional control and visibility of the testing across the enterprise makes the creation of the Testing CoE a desirable outcome in most instances. However, test process maturity across the enterprise may not always be consistent. Before embarking on a Testing CoE initiative, it is advisable to conduct a review of the test processes used to identify process deficiencies within individual areas of the organization. Equipped with the results of the test process review, senior management can plan the creation of the Testing CoE, providing those parts of the new CoE with the required training, tools and support to meet the quality standards demanded from the CoE as a whole.
Test Early, Test Often, Test Everywhere
In an SOA environment, QA and testing activities take on a new dimension. SOA blurs the line between the business and IT and between the business analyst and the developer. This carries on into QA and testing. The QA policy must embrace both technical, developer led, testing and business user focused testing. Business applications built from SOA components will still require user acceptance testing but the resolution of defects that arise from acceptance testing needs to be smarter and quicker. The only way to do this effectively is to have full traceability of the testing back from the user interface through to code level unit testing.
Integrated test management, planning and execution allows SOA implementers to have confidence that a defect found at any stage in the development and deployment can be quickly identified, analyzed and resolved. This can only happen if a full suite of tests can be applied across every service used within the failing business application. Without this capability, the underlying cause of the failure will remain uncovered for an extended period, which inevitably gives rise to finger pointing and an endemic blame culture. A mandatory, robust QA policy is required to provide every stakeholder with the confidence and the capability to engage in the defect resolution process in an unbiased and professional manner.
Performance Matters
In the last few years, the performance of IT systems has become one of the top areas of concern for IT executives, and also for business managers struggling with functionally robust and rich systems that simply cannot cope with the operational load placed on them. There are two major reasons why this has occurred. Firstly, no one thought to define the performance requirements of the systems at the definition stage. Even if performance objectives were considered, they frequently never got more thought than "The system must perform adequately". In hindsight this is not a requirement, it is a hopeful wish more often honored in the breach rather than the observance. Secondly, developers had no pressure placed on them to consider the performance options when designing and coding the system. It is virtually always the case that the quickest route to implementing a specific service can be shown to be a poor choice if performance is also factored in. However, developers rarely have the time to examine the solution space for multiple functional solutions to the same service development. Given one chance to implement, it is usually a poorly performing algorithm that is the quickest to create. This may not actually be a problem in the overall business applications built from this specific service, but the time has now come to add performance at the unit testing level. This is not actually a difficult task. Good developers will already be using unit testing frameworks to exercise their code functionally. They simply need to collect and collate the execution times of their tests so that these profiling results can be used to help perform root cause analysis when other forms of performance testing, such as load testing, start to indicate problems at the business application level.
Security is Good for Business
The security of IT systems has become a regular source of news stories for the media. While the idea of anonymous employees struggling with poor quality IT systems is unlikely to cause upset, the thought that your own personal data, such as medical or financial details, could easily fall into the hands of criminals is something that journalists are only too keen to exploit.
Good QA and testing practices cannot completely remove the security threat and it would be a false premise that security testing that finds no vulnerabilities proves that your IT systems are secure. However, rigorous and comprehensive security testing is a statement of intent to maintain your IT systems at the highest level of integrity. While security testing should be a given, it is also the case that increasingly tight regulatory and compliance regimes imply that organizations must show that they are proactive in their security posture and that failure to show traceability of security testing may be taken into account when considering the culpability of organizations trusted with personal data.
With regards to SOA, there are two aspects to consider. For those enterprises that are using SOA as an enabler for extending the provision of their business services to other enterprises, the internet is the obvious choice of providing access. However, the public nature of the internet means that not only will authorized users of your services access them, but that hackers of all levels of ability will try to gain access to the systems behind the public services. Even if there is no intention to externalize business services, the security threat internally is potentially higher in an SOA environment. The centralized nature of SOA governance and configuration management tends to promote the development of a homogeneous technology implementation. In the past, project-lead development gave rise to a varied technology inventory, now a top down SOA strategy will lead to a more uniform landscape. There are many benefits to this approach, but it also increases the potential damage that a security breach could incur. Should an intruder gain access to your systems, it is more likely that the knowledge that was used to gain initial access will also provide access
to more areas of the IT infrastructure. This is somewhat akin to virus writers relying on the ubiquity of the Windows platform to enable their creations to spread.
The need for security testing is not just an SOA issue, but SOA implementers should pay particular attention to the topic. Operational security measures such as encryption, intrusion detection systems, firewalls and physical security are essential to prevent potential vulnerabilities from being exploited but the best form of software security is to remove the vulnerabilities from the system by thorough security testing prior to deployment.
Model Driven Testing
The recognition of SOA as a holistic approach to the provisioning of IT lends itself well to the concept of Model- Driven Development. This is a software development method where the business services themselves are modeled completely and unambiguously within some form of modeling environment. The model itself contains enough information about the required business services, and the technology components needed to develop the software underpinning the business services, such that the model data an be transformed automatically into actual software that provides the required business services. This is in contrast to more traditional software development techniques that rely on a concept of "design by elaboration", where the software design is an abstract model of the solution and is only realized as a concrete software solution by the additional information captured by individual software developers "elaborating" the design as they write actual lines of software code. It is this manual coding process that leads to the introduction of the many and varied coding "bugs" that arise in most software systems.
In contrast, the promise of Model-Driven Development is that a single, complete model of the business can be captured once and managed centrally thus providing a single point of reference for software designs constructed to extend the business services provided. In theory, developers no longer have to write large amounts of programming code for each business application, instead they write a small number of "transformation rules" that extract information from the model and create application software services directly. While simple coding defects can be virtually eliminated by this process, in practice there are new pitfalls to avoid. Misunderstandings in the requirements for new business services invariably arise and a single error can be replicated throughout the SOA components generated from the model.
Fortunately the time and cost savings derived for the creation of software business services using Model-Driven Development can also be applied to the testing of the software. Using both the business requirements and the transformation rules used in the creation of the application software, skilled test engineers use the same process as the development team to automatically generate test harnesses and test data that can exercise the automatically generated application services software. The test harnesses will exercise the software services automatically and report on discrepancies between the behavior of the software services, as expected by the test harness, and the actual behavior of the services as created by the software developers.
Summary
Have we reached the summit of the IT mountain with SOA? Probably not, but it does seem to be going in the right direction and giving IT a clearer view of the business landscape and a new set of tools to solve business problems. With that in mind we must not lose sight of the fact that IT can have its own problems; overpromising business benefits and under delivering IT capability has been the Achilles' heel of IT for decades now. Building the right services is a business issue but building the services right is firmly in the IT court. It is a truism that the bit that breaks is the bit that was not tested. With SOA, bits that break impact wider than a single line of business and the impact that a failure can have is magnified. Obviously, the solution is to have fewer failures. Only by implementing modern QA and testing best practice and insisting on high quality delivery can an organization be fully prepared to meet the challenges of SOA implementation. If those challenges can be met, there is every chance of reaping the rewards expected.
|
