Rants
Questions
Soapbox
Best Practices
Apply today for a FREE subscription to CIO Magazine!
Sun, Dec 23, 2007 20:32 EST
|
Posted by: John Michelsen in Best Practices Topic: Architecture
Current Rating: |
One of the most difficult obstacles to attaining enterprise-ready SOA is the sheer scale of the systems and data that need to be managed. To test the actual results of an SOA application, we need a very realistic set of data – both positive and negative – to input, and then get out of the environment under test.
True, we can map much of our interaction with other Services according to the metadata we set forth during architecture and design processes. But when you get past that ideal model of connecting the endpoints, you still have the nitty-gritty of a CRM mainframe, or an SAP or Oracle Financials enterprise system, and the administrative owners of that system, to contend with. The data and business logic embedded at these layers has been added to and customized over the course of several years.
So why can't we just have developers and testers work against the live SOA system?
Well, those system administrators might be reluctant to provide access to key business systems in deployment. Beyond that challenge, getting a bed of realistic test data in place can be more than difficult – and hardware virtualization doesn’t scale to replicate the terabytes of data such an implementation requires. Implementing a complete mirror image copy of the system to test requires another enterprise license and implementation team – far too costly in scope.
The best practices for overcoming the data crunch isn't by any means an easy road, but it has to be done.
- It still starts with good architecture - mapping out realistic business workflows, and the metadata relationships that define them.
- Next, we need to capture as much of the data as we need to provide a realistic test environment for SOA. There isn't a way to replicate all of it, but we need to obtain enough to encompass most of the workflows we've defined. Virtualization of test beds, and the behaviors of apps as Virtual Services, can help you get to the point of reaching the 80/20 rule for the data you need most often.
- Finally, we need a strong SOA Governance approach to staging, promoting and deploying the application, which includes continuous testing and validation of the expected behaviors, and underlying data. No amount of simulation in development can account for all of the unforeseen consequences of changes in the deployed system.
Obviously, there is much more to this process than I can cover in a post, but I hope you will seek out leaders and solution providers that can help you accomplish all three of the above goals.