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

comments powered by Disqus


  • Death of the Dev Machine?

    Here's a takeaway from this week's Ignite 2020 event: An advanced Azure cloud portends the death of the traditional, high-powered dev machine packed with computing, memory and storage components.

  • COVID-19 Is Ignite 2020's Elephant in the Room: 'Frankly, It Sucks'

    As in all things of our new reality, there was no escaping the drastic changes in routine caused by the COVID-19 pandemic during Microsoft's big Ignite 2020 developer/IT pro conference, this week shifted to an online-only event after drawing tens of thousands of in-person attendees in years past.

  • Visual Studio 2019 v16.8 Preview Update Adds Codespaces

    To coincide with the Microsoft Ignite 2020 IT pro/developer event, the Visual Studio dev team shipped a new update, Visual Studio 2019 v16.8 Preview 3.1, with the main attraction being support for cloud-hosted Codespaces, now in a limited beta.

  • Speed Lines Graphic

    New for Blazor: Azure Static Web Apps Support

    With Blazor taking the .NET web development world by storm, one of the first announcements during Microsoft's Ignite 2020 developer/IT event was its new support in Azure Static Web Apps.

  • Entity Framework Core 5 RC1 Is Feature Complete, Ready for Production

    The first release candidate for Entity Framework 5 -- Microsoft's object-database mapper for .NET -- has shipped with a go live license, ready for production.

Upcoming Events