07.27.07

The Loneliness of the Long Distance SOA Developer

Posted in Application Development, BPM, SOA & Web Services at 2:24 am by Tony Baer

It’s been an interesting week as we’ve had a chance to dialog with enterprise architects and the BPM community at back-to-back conferences presented by The Open Group and OMG, respectively. And as we hinted during our last posting, where we conversed live via blog (and later on stage) with Dana Gardner, Todd Biske, Beth Gold-Bernstein, and Eric Knorr from the Open Group EA Practitioner’s Conference, was how isolated SOA developers appear to be from both groups.

Specifically, that the folks doing the SOA projects are perceived to be estranged from the enterprise architects who are supposed to (depending on the organization) enforce or promote technology standards and best practices across the enterprise. And they are seen as equally estranged from the domain experts and process owners in the business who manage business processes. Regardless of whether you are an EA or business analyst, chances are, you view SOA developers as just the latest generation of cowboy programmer.

In the case of EA, it’s that programmers make de facto architectural choices in delivering projects that could wreak havoc down the road when it comes to reusability, maintainability, or the accountability with enterprise compliance policies. According to Gold-Bernstein, most web services being exposed today are rudimentary data services that in many cases are conventional remote procedure calls (RPCs) with web service interfaces that are SOA in name only.

Adding insult to injury, SOA developers are accused of unleashing web services with scant awareness of the subtleties of the business process(es) that they are exposing.

Of course, it’s easy to dump on developers because they are the poor folks down on the front lines who actually must deliver tangible results for sponsors who are rightly concerned about their own projects. And lacking the right funding mechanism, project sponsors are not exactly willing to bear the costs alone of generalizing their solutions for the rest of the enterprise. Although it might be reasonable to expect developers to observe enterprise architectural standards, you can’t knock them for failing to develop reusable assets if nobody’s going to pay the necessary surtax.

In the case of business process management, SOA developers are similarly estranged from process owners. In this instance, it’s a matter of reconciling who makes the architectural decisions for integrating business processes. A couple days after the Open Group, we presented our take on the cultural divide between business process and SOA architects/developers at OMG’s BPM Think Tank.

You can download our presentation, BPM’s from Venus, SOA’s from Mars, here.

In a nutshell, our take was that the divide constitutes the latest battleground between business and IT. Both sides use different tools (BPM’s building blocks provide the process context that is executed, but not necessarily represented by web services), and that both groups are fighting over whether to integrate processes through the BPM tool, or through dynamic BPEL web services orchestrations. In the vendor community, the sides are polarized between the J2EE integration platform vendors (e.g., BEA, IBM, SAP, and others, who tend to dominate Oasis) vs. the BPM pure plays (Lombardi, Savvion, Metastorm, Pegasystems and others). World peace wasn’t exactly helped by the recent BPEL4People proposal by the J2EE/Oasis players, which met a wall of silence from BPM pure plays.

We shared the stage with consultant Brenda Michelson, coordinator for OMG’s SOA Consortium, where CIOs share their pain and gain over SOA practices. Her message was also one of overcoming isolation – in this case, that to realize the promise of SOA, that architects and developers alike should cross train in the language of business. She pointed to one organization’s success story, where the resident SOA geek who only spoke WS-speak subsequently spent roughly a year immersing himself in night business courses and studying what made his organization tick. Today that SOA architect speaks the vocabulary of the business, and has become someone whose advice is now sought after by the very people who formerly avoided him.

Maybe there’s hope.

Leave a Comment