This simple cheat sheet contains all the key goals, principals and design patterns that you should be aware of when designing SOA services and contains helpful links to places where you can find more in-depth information on each topic.

When I was studying for my SOA Certified Architect exams, I kept notes on all the best bits from the course material. After 9 months and several hundred hours of study, I found that there were certain key pieces of information that I kept referring back to time and time again, such as…

• How do you define service-orientation?
• What are the goals and strategic benefits of having a service-oriented business?
• What are the design principals you should apply to SOA service design & SOA governance?
• What are the characteristics of SOA based businesses – how can you recognise one?
• What are the most useful SOA design patterns and how are they grouped?

I thought it might be useful to bring all this information together into one place, so in collaboration with SOAGrowers we have published a free PDF cheat sheet on SOA Service Design which you can print out and keep close to hand so it’s there whenever you need it.

It’s not meant to be an exhaustive guide – it’s just a set of place-holders to remind you of the topics that may be of relevance to you when designing services. However, it should prove useful to any service architect or developer who’s interested in service design or anyone who is going through the same certification programme as I did – even if you just use it as a check-list or aide-mémoire.

None of it is particularly technology specific. The same set of goals, principals and patterns can be applied equally to SOAP based web services, RESTful services or any other kind of distributed components – that’s the beauty of service-orientation, it’s vendor and technology neutral.

In the sheet I’ve also highlighted something that often get’s overlooked when technologists have the lead on SOA implementations:- SOA has some very attractive and unique business benefits that can only be fully realised when you apply the design paradigm correctly. For my money, it’s this outcome oriented viewpoint (the business case if you like) that really differentiates SOA from other tactics like EAI/ESB, but all too often this message gets lost in the melee.

We hope you find it useful.

To get your copy of the SOA Service Design Cheat Sheet, just click on the image below. If you like it please share it (there are handy share buttons on the page below).

Click on the image to download the PDF

Get involved.

Did you find this useful? Is there something you think could be added or removed? Did you notice how ESB is just a small fraction of the bigger picture? Let me know your thoughts in the comments below.

Updated: 18/09/2012.

I’ve now added a small section on contract first service design, just because it so fundamentally underpins many of the most important goals, principals and patterns used to deliver successful SOA. For more information on contract first, see Spring-WS’s excellent whitepaper.

Contract-first isn’t just a SOAP thing by the way. ‘Contract’ in a SOA design context means operations, data types, policies and anything else to do with the service’s public facia. So although rest has an implicit contract with predetermined operations (GET, PUT, POST, etc.) it still has data type’s and flexible URL’s that convey some meaning.

Therefore, if you want to make a REST architecture more interoperable and less brittle for clients, it helps to plan these datatypes and URL’s in advance if you can so they become better standardised and therefore more reusable.