Starting with the business architecture that means picking your approach to defining the business services. Now you could use my approach or something else but what ever you do it needs to be consistent across the project and across the enterprise if you are doing a broader transformation programme.
On requirements its about structuring those requirements against the business architecture and having a consistent way of matching the requirements against the services and capabilities so you don't get duplication.
These elements are about people processes and documentation and they really aren't hard to set up and its very important that you do this so your documentation is in a consistent format that flows through to delivery and operations.
The final area are the technical standards and this is the area where there really is the least excuse. Saying "but its REST" and claiming that everything will be dynamic is a cop-out and it really just means you are lazy. So in the REST world what you need to do is
- Agree how you are going to publish the specifications to the resources, how will you say what a "GET" does and what a "POST" does
- Create some exemplar "services"/resources with the level of documentation required for people to use them
- Agree a process around Mocking/Proxying to enable people to test and verifying their solutions without waiting for the final solution
- Agree the test process against the resources and how you will verify that they meet the fixed requirements of the system at that point in time
So with REST there are things that you have to do as a project and programme and they take time and experience and you might get them wrong and need them updating. If you've chosen to go Web Services however and you haven't documented your standards then to be frank you really shouldn't be working in IT.
So in Web Service world it really is easy. First off do you want to play safe and solid or do you need lots of call-backs in your Web Services. If you are willing to cope without callbacks then you start off with the easy ones
- WS-I Basic Profile 1.1
- WSDL 1.1
- SOAP 1.1
Next up you need to decide if you are going WS-* and if so what do you want
- WS-Security - which version, which spec
- WS-RM - which version, which spec
- WS-TX - your kidding right?
The other pieces is to agree on your standard transport mechanism being HTTP. Seriously its 2010 and its about time that people stopped muttering "performance" and proposing an alternative solution of messaging. If you have real performance issues then go tailored and go binary but 99.999% of the time this would be pointless and you are better off using HTTP/S.
You can define all of these standards before you start a programme and on the technical side there really is little excuse in the REST world and zero excuse in the WS-* world not to do this.