the promise of SOA

But how to create a software module model was the next thing the architects battled over. Integration of differing vendors, agnostic software was the buzzword. Best of Breed, ASP, package software, and COTS applications began to take the markets by force. Why have an army of custom coders writing your GL/AP/AR finance systems when they all do the same thing. Buy the commodities, build the software that makes you unique.

Eventually it became obvious that software produced by vendors needed a common language interface. In the Microsoft world COM/DCOM was born. Everywhere else it was CORBA and XML. Interfaces became the "contract" by which software communicated with itself internally as well as other software externally. Infrastructructe to support this model became important. High availability hardware was espeically important. Now the problem of multi-vendors for hardware and software became a nightmere for the IT Support Staff. To reduce the complexity they demanded each vendor to support multiple OS and multiple hardware stacks. Software became increasingly complex because of all the testing on the various iterations of these systems.

In the end, building software requires doing the simplist thing. Build for the common denominator. Make the module "black box" and expose only the interfaces needed, version them, and build a test harness. As each version is rolled out, add to the test harness. The test sequence should include:

1) create the data for the test cases (database should be empty before this step)
2) run the scanarios
3) delete the data

If you are running load tests add one step before #1, load the database with volume data. This will give a production environemt to the tests. Remember that the full production data doesn't need to be loaded but only a factor of should be.