Analysis and architecture

Note: I originally titled this post “Analysis vs. architecture” but deliberately changed it based on the tone of the post as it emerged.

So, I’m not quite sure what inspired this post from Nick Malik but it certainly provoked reactions! Kevin Brennen from the IIBA responded very quickly with a detailed post citing numerous instances from the BABOK pointing out a lot of similarity between business analysis and architecture activities. In a comment to the original post, Tom Graves also pointed out that it may be the thought processes or weltanschauung that differentiate (or align?) the two roles.

In a follow up post the following two questions are asked of business analysis and architecture:

a) Is it better or worse for these roles to be independent?
b) When both roles exist in the same organization, how do we prevent confusion, clarify accountabilities, and make both roles effective?

Better or worse?

Setting aside time as a constraint, my response here is: someone who has the clearest view of the architectural needs is already well placed to steer the analysis towards meeting those needs. I agree with Kevin that the business analyst and architect role are not quite as far apart in terms of skill-set as is sometimes claimed. It does require that single person to be able to look “up” to analyse the strategy and capabilities and to then look “down” to the detailed implementation of their realisation. In my view, however, that is more a difference of mind-set (and experience) rather than skill-set.

But… I now come back to my caveat about the time constraint. I’m currently in a team of 4 business architects working with a team of around 30 business analysts. My current assignment is as an architect for a 2 year program of 4 projects (although the inevitable “phase 2” is being talked about!) working with a team of 7 business analysts. Would it be better or worse if I tried to do my own job and that of the 7 business analysts? Would it be better or worse if the 7 business analysts all tried to do the business architecture in addition to the 4 people who have been given it as a day-job and on top of their own day jobs? I would argue worse in both cases.

So, sometimes it’s a necessary evil for the analysis and architecture roles to be separated. The business needs (I need!) multiple business analysts to get through the volume of work; but the business needs (the analysts need!) a single steer on the architecture.


The table below sets out how we generally segregate accountability between the architect and analyst. Note that you can simply substitute “roadmap of change” wherever you see “program” if that is better suited to your situation.

Architect Analyst
Responsible for the value delivered across the whole program
Responsible for the value delivered by individual project scope
Works with project management to scope and schedule capability increments across the program
Works with project management to schedule capability deliveries within the project
Agreeing with the sponsor the budget to be spent on each capability increment
Delivering within that budget or flagging risks of over/under spend
Advising the sponsor and project management on capability trade-offs at program level
Advising the sponsor and project management on alternative delivery options for a capability
Ensuring requirements are balanced according to business value across all capabilities being delivered
Ensuring requirements are proportional to the business value of the capability being delivered
Ensuring that all the “moving parts” work together – cross project dependency management
Ensuring that a particular moving part serves its purpose – inter project dependency management
Working with IT architects to resolve business and IT architecture concerns
Working with IT analysts to resolve application/component concerns


Clearly, this requires close collaboration between the architect and the analysts both formally and informally.  Our starting point for the formal communication is the Business Architecture Briefing backed up by our “knitting pattern” and functional dependency map.

Informally, it’s really just about working as a team – I and the senior business analyst on each project get together at least once a day – and trusting each other. I know I can count on them to flag with me when things are going pear-shaped and they know they can count on me to fire a rocket at the business if they need me to.

It’s not about seniority either. I would, and have, happily worked for business analysts in the reporting chain when they’ve asked for architecture support. It’s just about understanding that the analysis has to flow from the architecture – not the other way around. It’s all about communicating between the two formally and informally to get the job done.

That, after all, is what we are paid to do.


About EBAnous

EBAnous works as a business architect for a FTSE-100 company in the south-east of the UK
This entry was posted in Controversial, Delivery Mode. Bookmark the permalink.

2 Responses to Analysis and architecture

  1. nickmalik says:

    Your post demonstrates your experience with these roles, as well as a balanced and fair approach. Solid insights that are clearly born from delivering value, in these roles, in the real world. Thank you for sharing.

  2. Pingback: Analysts and architects | EBAnous

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s