Practical .NET
Insider: Facilitating SOA
Peter Vogel describes why he doesn't design service-oriented architectures for his clients: he "facilitates" them.
In an earlier
column I mentioned that lately I've been facilitating SOA design for my clients. I was then deluged with e-mail asking if I didn't mean that I was "designing an SOA" for my clients. So, here's what I meant.
I'm a programmer. As such, I've always been deeply suspicious of "system analysts" -- the idea that someone can hang around a business for a couple of weeks and then say "Oh, I know what you need" before inflicting some automated system on a defenseless set of users. Business systems tend to be living, complicated things that reflect (and respond) to a variety of pressures in the lives of their users. They're not something you can understand in two weeks.
I'm also deeply suspicious of "mega-projects" designed to implement all-encompassing solutions that will manage the organization (or a significant part of it). Organizations and the world they live in are changing all the time so, by the time a mega-project completes, changes in the organization and its world have invalidated the project. In addition, as the team advances through the project, they get smarter -- they can make better decisions about later parts of the project after building earlier parts. Designing later parts of the project at the start, when the team is dumb (relatively speaking) about the project, is foolish.
Imagine, then, my suspicions toward a project that involves building a complete architecture (of any kind) for a living organization that I'm not part of.
Designing an SOA, like designing an organization's database, is done best by bringing together two parts of the organization -- not by bringing in an external consultant. The two parts are those with a deep understanding of the organization's processes and goals (because they execute them every day), and those with a deep understanding of the organization's technical recourses and capabilities (because they build them every day). Or, to put it another way: the suits and the geeks.
Designing an SOA also works best if it's targeted at developing, in detail, only a part of the organizations' SOA -- a part driven by a particular project or department with well-defined objectives and needs. The design process can sketch out those parts of the SOA that will be built later by other teams on other projects.
Fortunately, there's a well-understood process for bringing together suits and geeks and taking advantage of both their contributions. Most companies can do this on their own but, for the first time (or first couple of times), they sometimes want help. And that's what I do: I help set the scope of the project and work with the team as they work through the process the first time (typically, it takes two to three days). The output of the process is detailed specs for the part of the SOA to be developed in the first project, and a sketch of the overall SOA. Ideally, the detailed outputs are service contracts that can directly drive the development process for both services and consumers.
Subsequent executions of the process will provide that level of detail for the parts of the SOA required by other projects. Those projects will extend and fill in the SOA (and, perhaps, determine that some parts of it never need to be built).
So that's what I do: help people design their own SOA. On occasion, I even get invited to stick around and help build some of it.
About the Author
Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at http://blog.learningtree.com/tag/ui/.