Who should lead SOA? Enterprise architects or business analysts?

Ouch -- double ouch -- here's an online spat I wouldn't want to get in the middle of:  James McGovern and Robert Mcilree are arguing about what kind of professional principles should be applied to the work of enterprise architects. Who said EAs aren't the types that roll up their sleeves and tussle like the rest of us?

James and Robert not agreeing on how to disagree reflects the great (and sometimes testy) internal debate that is going on within the EA profession, a debate that is also spilling over into other professions as well.

Enterprises are hungry for qualified people that not only are tech savvy, but can interface comfortably with the business. Enterprises need guidance before spending millions on new systems and applications and techniques to deploy that software. And they'd better get guidance if they're going to tear the entire business down into loosely coupled service components. Who can tell them what to do? Who should be the peacemakers, the protagonists, the bridges between the two colliding landmasses of business and IT?

That certainly pertains to the most important enterprise architecture initiative going on these days -- service oriented architecture (of course, what else was I going to say, right?).  The question that is now on many enterprise front burners is: who is best equipped to lead SOA efforts? Who should we turn to? 

Based on what I saw and heard at last month's Open Group conference, EAs really seem ready and raring to go on this SOA thing. (We also explored options at a panel discussion at the event.)

But let's throw another point of view into the mix. In a new post, Ron Schmelzer says EAs are taking the lead in many cases, but there is another emerging set of professionals we have been long ignoring that have also something to say about SOAs -- business analysts (BAs).

Frankly, we haven't talked a lot about the role of business analysts in SOAs at this blogsite, nor have I heard or read too much discussion about the changing roles of these professionals. So Ron is breaking some new ground here. Ron even points out that business analysts held sway with the business "before the discipline of EA got the visibility it has now." To some extent, EAs may have pushed BAs out of the SOA limelight in recent years. But part of the reason is because early SOA efforts have been entrenched in the IT sphere of influence, and BAs, according to this Wikipedia definition, tend to have a non-IT heritage.

That being said, with SOA increasingly taken on a business or enterprise hue, BAs may now have a lot to contribute to these efforts.

Is it simply a case of EAs versus BAs? Ron says, no, but the question is whether BAs as a group should be given specific roles in interacting with EA groups and SOA efforts, or should even be considered "simply another type of enterprise architect that should be rolled into SOA initiatives."

Ron notes, however, that many business executives and managers are more familiar with the role of BAs than EAs.And BAs are getting involved in SOA just as much as EAs:

"It would be unreasonable to assume that the EA role will usurp, replace, or otherwise impinge on existing BA capabilities. However, the future of EA and the future BA are clearly moving in complementary directions. To the extent that BAs are dealing more and more with requirements for agility, reuse, and reduced cost of integration, they will find themselves mirroring the activities of the EA groups in their organization. Likewise, the more that EAs find themselves responsible for translating ill-defined business requirements into architectural models and service definitions, the more they will find themselves filling a BA role in the organization."

In businesses seeking to cut, economize, and streamline IT activities as much as possible, it only makes sense to converge the roles of BAs and EAs even more closely. This BA/EA hybrid professionals can then take on "an expanded, strategic, and operational role for IT planning that plays more in the hands of business than it does in the increasingly commoditized hands of IT implementation and operations."

Hmm. Sounds good, but we better check with the EAs and BAs first...