September 16, 2009

Design Principles: guide rails for service design

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.

When your manager asks

Can you answer these tough questions?

They're really asking about

Do you think the clients will mind if we …?

Move the server? Upgrade the interface? Re-implement in Ruby?

Loose coupling

Haven't we done this before somewhere?

Why do I have 4 customer profile applications in my call centre?

Service-orientation

How expensive is it to make changes?

What do you mean changing the UI forces us to refactor the data access layer?

Clean separation of concerns

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.