BA and EA

Building and maintaining relationships are a VERY important part of the ongoing ability of Enterprise Architects to do their jobs. Take a look at Figure 7. this IBM document -- it kinda says it all.

If EAs don't have their finger on the pulse of the organization, including business requirements and strategic direction, then it will be impossible to validate architectural requirements and strategic context.

I've just returned from a four day Business Analysis Boot Camp (ASPE) in which it really became apparent that BAs are engaged in many of the same relationship building and requirements gathering activities as EA. Business Analysis even involves an "Enterprise Analysis" phase. Kinda spooky. By the way, the boot camp was great! If you do the course, see if you can get Bob Keith as the instructor -- top notch!!

The stakeholder interview and documentation approaches offered in the BA class (and in my earlier Systems Analysis and Design courses) are very similar to what Dana Bredemeyer and Ruth Malan teach in their EA workshop.

BA is a strong presence in the Business environment and even has it's own Body Of Knowledge (BABOK) like Project Management's PMBOK (can't get it for free anymore) and offers certification through the IIBA. In many aspects, it's been around a lot longer and has a lot more exposure than EA.

So, what is the difference between EA and BA?

The Answer: Context.

While BA and EA both claim to be the "bridge" between "the Business" and "IT" and do rely heavily on iterative requirements gathering and validation, the fundamental raison d'être of each discipline is quite different. BA seems to get engaged because of a project or initiative or idea; EA is engaged despite projects, initiatives, or ideas. While BA's Enterprise Analysis phase certainly looks at strategic context, its a snapshot in time relative to the project at hand; EA's enterprise approach is to provide living context across projects and across time. If an EA is involved in requirements gathering in a project, you can bet that project is a strategic differentiator for the organization. Governance of architecture through formal frameworks (like TOGAF, or E2AF is also a unique aspect of EA.

Its not surprising there is confusion regarding the differences and overlaps of EA and BA. Wikipedia even says that BAs can be architects!

Here's an interesting back and forth between EAs and BAs, including a comment from yours truly.

It seems like one challenge for Enterprise Architecture -- especially in immature organizations -- will be staking a claim on the piece of requirements gathering and relationships that belongs to us, while not bruising relationships with our friends in Project Management and BA. BA can be a valuable partner with EA programs, if the relationship is established early.