As a student of physics, Albert Einstein is one of my personal heroes. Aside from being one of the most brilliant minds to ever contemplate the universe, Albert had a way with words. One of his quotes strikes me as particularly apropos for this month's issue - "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction."
This month we're focusing on two subjects that actually tie in together much more than most people actually anticipate - SOA Testing and Service Design. I'll get to how they tie together in a moment, but let's see how Einstein relates to SOA first.
With SOA, it's very easy to buy the plumbing. You go out and get an ESB, a rules engine, something to do BPEL or BPML, and something to do basic services management and you're ready to tackle that great big world of SOA.
Of course, at that point you are in the same circumstance as you were 20 years ago when you finally made that step away from ISAM and selected your first relational database. You bought all the goodies, got it installed and then you sat. And then you realized that your great big shinny database was empty. So you started designing tables. Maybe you thought about normalizing, maybe you didn't, but before you knew it you had umpteen tables and performance was in the toilet. What was so great about RDBMS anyway?
Naturally, there was a learning curve, and some bitter experience with normal forms and what level is reasonable. The question then was, and yes, I'm finally getting back to the point, what was the right approach to database design?
Fast forward to today and we're asking the same questions about service design - is it a customer service or a customer edit service? Maybe it's all part of the account service. Because after we get over learning about what WSDL is, we still have to figure out what to make with it. We still have the same issues - if we make the service too fine-grained, we have too many of them and eventually someone will come along and aggregate them anyway - and perhaps not in a way that's optimal. If we make the service too coarse-grained, we risk creating EDI all over again - one method with 80 parameters, all optional. There's even the added complexity of standards such as ACORD - importing and using the whole schema adds tons of elements, many of which you may never use. Like the man said - it's easy to make it bigger and more complex; it's hard to go the other way.
One way to try to swim against that tide is to start designing with the concept of testing in mind. Rather than wait until the service is coded before you begin to design the test cases that will check to see if it works, why not start with them. Do the design from the perspective of testability and functional completeness, and you may have a jump start on how to handle your actual service design.
There's no silver bullet that I'm aware of to magically adjust your service designs until they're optimal. Service Management provides needed tools to take a look at QoS and establish service SLAs that will allow for meaningful investigation of your service design, but the fact of the matter is you won't get it right the first time, so allow yourself time and budget for refactoring. You should also note that conditions will change over time and what was once optimized and working properly is now in need of some TLC. This is where performance testing and predictive modeling can help in anticipating capacity planning for services. Once again, an ounce of testing is worth a pound of code. You can quote me on that - I may not be Einstein, but I did stay in a Holiday Inn Select last night.