When will we focus on Service Design?

Over the last few years I’ve written a lot on service design, and while there as been a few good articles around this topic, I’m finding it interesting that so much time and energy is spent on ESB and governance, and not on the foundations of SOA…services. While I think I understand why this is the case, software design is just is not sexy, I can’t believe that we are implementing SOA without a clearer approach to this important activity.

I understand that there are many interface standards at play here as well, but that does not get around design just add requirements to it. Just to be clear, I’m talking about:

• Understanding the core requirements of a service.
• Understanding how to normalized, or combine or break apart services.
• Understand the core design of the service, including structure and interfaces.
• Understand how the service will leverage enabling standards and technology.
• Building services with systemic security.

So, what’s the approach? It’s really logical when you think about it. Services, at their essence, are really small granular and autonomous applications. Thus, the design patterns need to follow that notion. A good way to look at them is very much like transaction systems of days-gone-buy where you have small bits of autonomous software running within a container to form a system. However, today the software is implemented as services, they reside on different systems, and the container is now architecture.

Indeed, we need to get better at service design, and dig a bit deeper down on the concepts, and understand better how this is changing the software development game. I understand that many SOAs today are JBOWS (Just a bunch of Web services), and as such, just a matter of liberating existing systems as a group of services. However, going forward more systems are going to be either scratch built or are in need of redesign, and our ability to design, test, and deploy services will make or break many SOA projects.