Joe McKendrick uses my "sometimes testy" (and I agree) "dialog" with certain enterprise architects (cough cough...) to ask the question of who should "own" and lead SOA efforts in organizations. He also quotes extensively from an article by ZapThink's Ron Schmelzer contrasting the roles that EA's and business analysts (BAs) play in SOA and related business-IT initiatives. I like Ron's take on the situation from a number of perspectives.
First, a BA is much more business domain-specific than most EAs. A good-to-great BA is very well-versed in the nuances of specific business issues, processes, and requirements. EAs generally (and in my opinion, must) take a wider view in order to unify the input and requirements of BAs into the whole. Joe suggests that '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.” '
I have issues with these statements. In large organizations with complex operations and business processes, expecting to find such depth of knowledge in one or two, or even a small group of individuals per business unit is asking a lot - probably too much, of most BAs and EAs. IT implementation and production is, to a certain and growing extent, commoditized. However, the translation of organizational/business strategy into requirements and process, and unification of all strategies and parts of an organization into an enterprise architecture requires collaboration between EAs and BAs working as a team. This currently cannot be commoditized like development and production can - and won't be anytime soon. In addition, even if one could develop an awesome EA/BA 'hybrid', the context-switching that would occur in such a scenario leads me to believe that forward, positive direction on an architecture would be limited, many mistakes made from time-crunch or expertise standpoints, or silos emerging from competing business and IT interests. The disciplines are complimentary and are best exploited within organizations at the intersection of their domains, not the combination of them into a single entity - especially into a very small group of people.
This argument is very similar to Todd Biske's commentary on roles between architects and project managers (example here). The roles are complimentary, but the domains, expectations, and work products are very different, and the outcomes between the two is a collaborative effort, not sole reliance on one or the other to deliver or compensate for the services and expertise of the complimentary discipline.
What matters in the end is what BAs, EAs, solution architects/team leads, and project managers collectively bring to the table and how collaborative efforts result in solid business analysis, architecture, and project execution. Expecting this to be concentrated in the hands of one, or a few, is setting up for unrealistic expectations and in the end, disappointment or even failure with respect to eventual outcomes.
I'll have more thoughts on leading collaborative efforts regarding SOA (or any architecture) between these domains in a later post.
Comments