Practical .NET

Insider: Thinking About SOA

Practical .NET columnist Peter Vogel ponders some of the assumptions and decisions that go into building out an SOA, and wonders if there might be better approaches.

• By Peter Vogel
• 06/27/2011

Bill Vaughn (author of "The Hitchhikers Guide to SQL Server") used to describe Microsoft Access as a virus because it encouraged so many people to create so many bad applications. (I disagree, but that's a different story.) I think that .NET's support of SOA is in danger of doing the same thing: making it easy for developers to create a random collection of Web services and then claiming that the resulting mess is, somehow, a Service Oriented Architecture (SOA).

A real SOA has several useful features:

• First, it serves the needs of the business rather than reflecting existing table or object designs -- it's more than slapping Web services front ends on whatever existing applications happen to exist (that is, it's more than "repaving the cow paths").
• Second, a true SOA is extensible and understandable. Because it is designed and architected, it's easy to find what you want in an SOA and to extend the architecture to add facilities not already present.
• Third, an SOA is efficient at a high level. I'm not talking about saving CPU cycles here (that's a real issue but it's also an issue for those implementing services that make up the SOA).

A good SOA doesn't force developers to do dumb things to make things work, it also takes advantage of the technologies available in the organization, and it ensures that re-use is built in from the start. There are other criteria for an SOA but, for me, those are the big three.

There are two reasons that I'm going on about this is. One reason is that I've been doing a lot of facilitation for clients to support them developing an SOA. The other reason is that Learning Tree (for whom I teach) asked me to write a course on SOA. That's got me thinking about the process I use when developing an SOA. You'll see two results of that introspection, as articles in Visual Studio Magazine: an already published article on how to use WCF to implement an SOA and an upcoming article on handling services that consist of a mixture of automated and people-driven processes.

The third result is that I've come to a better understanding of the process that I use with my clients. I hadn't realized, for instance, how much the process I use was influenced by the standard database design process. My process moves from identifying conceptual services (processes in the organization's value chain that function like services), modeling those services to better understand them, and then (for the services that can be automated either in whole or in part) developing the contracts for those services prior to turning them over to the implementation team to be built. While the database design model moves from conceptual to logical to physical phases, the SOA process I use (and teach in the course) moves from Conceptual to Logical to Buildable phases.

Another aspect of the process that I think I carried over from designing data architectures is the importance of involving both the business side and the technical side of the organization in designing the SOA. During the logical phase, the modeling tool I use is the Service Oriented Modeling Framework (SOMF), and I use it primarily because it's easier to get the whole team up to speed in SOMF than other, more powerful modeling languages. That makes it more likely that you can keep the "suits" involved in the process (and, as a result, the more likely it is that the project will deliver an architecture that really does serve the business). Besides, if the suits and the geeks design the SOA together, they end up with a common vocabulary that lets them actually talk to each other.

Fortunately, I won't be dragging you through that process (though feel free to take the course -- I get a royalty payment every time someone shows). But all that SOA work does mean that you get those two articles on implementing SOA with WCF. That's where all the fun is, anyway: building stuff and making it work.

Disagree? Is the real fun in designing the SOA? Do the suits (or geeks) just get in the way? Better question: Is an SOA actually valuable or is the organization better off building services as needed?