Friday, April 21, 2006

*-First Development

Just yesterday I was having a conversation with a developer about ‘contract first’ development. The individual was heading down the path of creating a contract prior to writing the code, as he had been instructed. But as a .Net developer, he interpreted this request as creating a ‘.Net contract’, not a ‘WSDL contract’. Naturally, I let this person know that I was interested in a ‘WSDL First Contract’, not a ‘Microsoft First Contract’. And as you might expect, the developer told me how there was no need to go ‘WSDL First’ because if he went ‘Microsoft First’, he could then generate a WSDL. As if I hadn’t heard that one before…

And once again, I had the same-ole discussion about how in SOA we would be creating interfaces completely separate from implementation – often with different groups of people – in different parts of the world – leveraging different reusable message components that would be related back to services front-ending multiple implementation platforms. He got it. ‘Microsoft First’ won’t work in an enterprise setting.

This discussion prompted me to ask some of our consultants if they were having good results with ‘WSDL First’ and the responses were positive. However, one consultant communicated that he has been pushing this concept into the requirements gathering phase. He called it, ‘Spreadsheet First’. Most I.T. Business Analysts will not be comfortable with creating WSDL’s and we continue to have an ‘analysis impedance mismatch’ between ‘legacy, silo-oriented Use Cases’ and ‘client cases / service cases’. His solution was to use a simple spreadsheet to layout the operations, messages and constraints. He would then use the spreadsheet as input in design phase, where he’d bundle the operations into port types and services and translate the field types.

One of the things I really like about SOA is having the service as unit of work. A service is right-sized for requirements gathering and specification. It is also right-sized for ‘Test Driven SOA’, but we’ll save that for another day…

No comments: