Webservices - Contract first or Contract last?

You are using some shortenings I am not familiar with like ejb and wsdl. I am used to danish terms in generel, thou I am very familiar with the discussion about contract first or last.

I have worked as Project Manager for a long time, and on all kind of projects.
The paradigm is based in the different roles in the organisation, and in this case sales and development.

Sales are responsable for getting customers to sign and are measured on turnover and often have bonussed based on it.
They are usually all for the contract first, because it shorten the time from first dialog to signed contract, so the customer doesnt go some where else.
The company runs a bigger risk of being of on the price if the project is laided out in the contract and sign first.
If it is only a frame contract with a number of hours at a specific price, it maybe an advantage.

Development is responsable for delivering what the customer where promised and holding the projectplans.
The better the analysis before contract is signed, the more precise the estimats for the work are, and that also means a more precise price and plans.

What it comes down to is this: the type of the project and a Business decision based on risk.

Evaluation should be made based on: known/new development, contract sum and contract text to give a picture on the project profile.

Is in 90% known stuff and 10% new - low risk financiel risk on contract first
Is it 10% known stuff and 90% new - high financial risk on contract first

Is the contract sum big compared to the company annual turnover - high financial risk on contract first
Is the contract sum small compared to the company annual turnover -  low financial risk on contract first

How well can you make reservations in regards to extra payment for the unknown and new stuff in the contract text, if plans runs wild.
Are you running a high risk financially because you cant.
Are you running a low risk financially because you can.

My own rule: There should never be more than one high of the above three catogories, when doing contract first.
In all other situations - contract last.

Depending on the kind of company it may also be relevant to streamline internal processes to the maximum due to a lot of employes and assigments changing hands due to specialist areas etc. To streamline one approach is chosen and used in all project types, and will in nature always be contract last.

Darrich, I think you're thinking of a business contract, which is something else.

EJB=Enterprise Java Bean
WSDL=Web Service Description Language

The WSDL states what methods your webservice exposes, and how they should be called. It is therefore a contract between the server and the consumer.

To put it simply, contract-first means that you decide what you want before you actually code it, whereas contract-last means you decide it after you've coded everything.

You could compare it to the paradigm about writing unit tests before code; you define the results you want before you implement them. By extension, coding according to contract-first shows that you've thought about what is required of the webservice.

Contract-last, on the other hand, takes an ad hoc approach to web services; you write code to process and return some stuff, and then generate a web service from that.

This doesn't necessarily mean you have to write the required info in the WSDL before implementing the method, as long as you have documented what the WSDL will contain and end up writing exactly that into your WSDL. However, writing it beforehand helps to ensure you're actually implementing the right thing.

Writing a WSDL isn't hard, but it can be a bit time consuming, especially if you're not used to working with XML Schemas. Various tools exist to help with this.

You may want to read section 2.3 in http://static.springframework.org/spring-ws/sites/1.5/reference/html/why-contract-first.html.

Hello guys!

Thank's booth of you for answers.

I think you booth should answer so I can reward you for particepating!

best regards
Fredrik

an answer :o)