It seems that there is quite a bit of discussion about where business architecture belongs. Should it be placed in the business or in technology (EA). During these debates I have heard comments such as "whoever controls business architecture controls the strategy" - I wonder which strategy - or that the placement is important because we need standards or structure or a framework. What does that have to do with placement? What I haven't heard much of is how to best facilitate the needs of the business. To me, that determines everything.
This is an organizational design issue and any model can work. What you need is focused, dedicated, conciencious, capable, aligned individuals perfroming that role. Where you stick them is not nearly as important and depends more on how you choose to define and scope the role/discipline. An even more important factor in this decision is the culture, context, structure and dynamics of your current organization.
Will the business usurp the BAs whenever the need arises by diverting them to tactical, operationally focused tasks? Then get them out of the business - unless business architecture is a "get to it when you can" kind of discipline. What? Is that even OK? Well maybe not,but if your organization isn't involved in significant programs of change - or if its only plans to change are over a long horizon, then this may be OK. I know this suggests that the organization may not be prepared to adapt, and that the reality in today's world is a constantly changing landscape, but if that is the strategic intent of the organization you need to either sell the need to spend more time up front, find a way to demonstrate value early and often, or find a new job.
What if EA is a hard core standards driven dictatorial governance machine? If EAs idea of BA is to build frameworks and drive business to comply so that it is easier to build and manage an enterprise infrastructure, then the entire EA team should either be let go, OR you should get BA out from under their influence - ulness your idea of BA is building technical frameworks. Don't however expect the business care about these things unless they help the organization thrive. Whatever does not shoud be jettisoned.
So, will a framework help the organization thrive? Perhaps, but only if its structure allows for organizational flexibility, agility and adaptability. Only if it can help solve real world problems in a dynamically ambiguous, complex and unpredictable environment. If, however, you take years to develop your framework before it can be utilized, you are going to face strong resistance, and rightly so. Find a way to build it out iteratively and incrementally, adding value where it is needed most. The quickest way to win the hearts of the business is to help solve problems.
If however you help solve problems in ways that compromize the future (again, organizational flexibility, agility and adaptability) then you are part of the problem. Remember Senge said that today's problems were yesterday's solutions. But, you may argue, that is precisely why BA cannot be trusted to the business, because they unknowingly compromise the future while trying to solve the problems at hand. I agree, but technologists are equally culpable. This is one of my principal gripes against some agile methods, which I won't mention here (SCRUM). Being agile and adaptive by fulfilling the evolving/changing needs of the business with a blind eye to the future is irresponsible.
I guess this begs a question around whether it is better to constantly throw work away (because the future is constantly unfolding) or whether one can actually build an infrastucture that can adapt and evolve. The answer here is very complex I'm afraid. Remember that technology is a beast unto itself, ever evolving - take cloud computing as an example, all the rage right now. And while new technologies are fun and potentially useful, an organization can only absorb so much change before it goes daffy - and technology is only one thing that is changing in large and complex organizations. I would argue here that if you slow the pace of technology adoption you can accomplish more. This sounds silly, but its true.
I see I am off the point, but I like where I've rambled. The point is not so much who owns BA, but how the organization is collaborating to design the future. Remember that there are many other players: Subject Matter Experts, Process Consultants, Process Analysts, Enterprise, Data and Solution Architects, Program Managers, Technologists, Business Managers, Line Workers. ALL of these roles (and more) contribute to building a successful and sustainable future.
Collaboration is the key, that and a razor focus continuous improvement. Stop arguing, roll up your sleeves and open your eyes and ears. Now, how can you best build an organization that effectively learns, adapts and grows, an organization that thrives? That's the real question.
Join us at http://insidebusinessarchitecture.ning.com