Read Blog Post

Read Blog Post

Contributed on September 16, 2009

3.3K

1.1K

Design Principles: guide rails for service design

Blogger: Richard Watson

Clients often ask us for help with their governance processes. We help them design surveys for their development teams to access the maturity of their applications and design practices with regard to sound architecture principles.

Given the problems we in the industry have had producing a formal definition, service oriented architecture (SOA) is best described as a set of design principles that support the goals of building flexible and maintainable systems. The fundamental design principles for SOA are clean separation of concerns, loose coupling, and service-orientation. These principles are not secret sauce to be poured on – if you are building systems that live and breathe these principles – you’re doing SOA.

Anne Thomas Manes will publish a report later this quarter detailing the motivations behind, techniques for, and consequences of applying these SOA design principles.

How principled are you?

With any governance processes like these, clearly articulating the motivation for the principles is crucial. No professional, developers especially, like to be told to – just do it – it’s good for you. Discovering the impact of abusing the design principles is not difficult to find. Think about these conversations you might have heard in the office.

These are just 3 examples of questions addressed by the SOA principles. If you cannot answer questions like these, you have some work to do in your service portfolio to enforce the principles more cleanly. If we continue to build systems that abuse service design principles, desired outcomes will suffer. If the service granularity is wrong or if interface and implementation concerns are badly separated, then the service will be less reusable. If business logic and infrastructure concerns are blended, developers can’t make changes to systems quickly and easily. Tightly coupled systems are going to get in the way of manageability. 

It’s the outcomes, stupid

If SOA is about contributing to business outcomes, then measuring the value of services must start with the desired business outcomes. To be credible and repeatable, metrics must be underpinned with measurements from your runtime infrastructure and service repository.  In her forthcoming paper, Anne will frame the principles and techniques with the benefits from applying each principle and with metrics for demonstrating the impact of applying or neglecting each of them. Stay tuned.