In my opinion the principles driving service oriented architecture are a great evolution of software design.  I have been working to apply many of those principles in work we are doing to update our core offerings as services.  While the principles are widely published I wanted to add some of my own value to them from recent experience and reflection.

Services should enable business processes. If process can’t be completed "on paper" or no one understands it exposing it as a service may not be successful.  Services should expose that business process in a meaningful way that replicates the paper process as closely as possible.

Services aid in loose coupling between systems.  By exposing services with standard contracts that represent their messages in a canonical format you reduce coupling between systems.  The schemas and WSDL become the contract by which clients and the service communicate.  As long as that contract is not violated the service can do whatever is necessary to fill requests.  Changes to data stores or processes should have no impact on those contracts.

Services exchange messages. I have seen several services which were passing encrypted byte arrays that were strings which were cast into a byte array, encrypted, and serialized  by the service then deserialized, decrypted, and cast into a string and transformed to an XML document on the receiving end.  While this offers security through obscurity it violates other principles including meta data exchange and contract first design which uses that meta data so all clients know what messages to expect.  Services should use messages that are exposed in a canonical format via schemas and WSDL’s (for web services).

Messages should contain all the elements required to complete the business process.  This is a great principle I found via Nicholas Allen’s Indigo Blog in a white paper published by Ythos.  This will allow you the most flexibility in situations where that message will be routed to several services to fulfill the business process.  In a real world context I can think of few, if any, processes where you fill out multiple parts of a form and send it to different entities for processing.  The form contains all the data needed and you send to one place and are not concerned if it needs to be routed to several locations to complete your request.

If systems need data from each other they should ask for it.  This is one of my favorite principles gleaned from Clint Edmonson.  The simplicity of this principle is also its source of elegance.  A good service offers meaningful ways for clients to request the data that service knows about.  The requests should require minimal amounts of "state" or "context" and be flexible to allow for data to be requested multiple times if one attempt fails.

Exposing processes as services lets you focus on the process and build several different UI’s to consume those services.  I have not yet reached a point where this is a reality at my employer but we are very close to getting there.  As you build more services and more processes are enabled in standard ways you can begin to design different types of UI’s to interact with those services.  Do you have a core service exposed as a web service using SOAP but are concerned that is too much lifting for your AJAX clients?  No problem, expose a wrapper service that uses REST and a lighter message format and have that translate to your internal web service.  This keeps your functionality in a central location but has the flexibility to meet special needs for clients.

These are some practical things I and others have been working to apply with great success.  A key to building an SOA from the ground up is to start with simple services and keep them simple.  The trick is to keep an eye to the future and be sure your services will be governable and promote reuse of data models, etc.  While a ground up approach is not always the best in some situations that is where the call to services needs to begin.  Good architects will be looking out for what will better align IT with the business, add value to the processes, and save on costs due to a more maintainable infrastructure.