To understand the need for a SOA test, imagine your organization has an SOA system already
in place at the departmental level but wants to make that SOA applicable for use throughout
the entire enterprise. How are you assured that the SOA system will work? Obviously, you
need an SOA test first.
This becomes a problem of scalability then. It means that the scale of design, application
and implementation of the SOA solution will range from minor to major (to put it at its
simplest.) It means that the SOA solution designer has to contend with client needs like
performance, monitoring, security, business performance management, catalog support and
extensibility, and integration brokers when trying to increase the scalability of the SOA
To see if this is possible, your organization may opt for cross-departmental design first.
Then SOA test follows. If it works, great – if not, back to the old drawing board. It is
logical that a smaller scale of testing is easier to introduce and monitor than an
enterprise-wide SOA test simply because of the number of variables being set in play.
The client needs will dictate the scalability being sought, rather than having the SOA
developer create a solution and impose this on the client. It should never be technology
for the sake of technology, but rather a healthy combination of IT with business functions.
It may even be necessary for the SOA developer to inform the client if he needs or does not
need an enterprise-wide solution. There may be clients who are just riding on the IT
bandwagon and want an SOA solution because everyone else is doing it. A prudent SOA
developer should inform the client at once if this is a doable project or simply wishful