In a previous post I talked about how we segregate the roles and accountabilities of business analysts and architects in our organisation. I also stated my belief that the “business analyst and architect role are not quite as far apart in terms of skill-set as is sometimes claimed”. Since then I’ve had a few questions which can be summarised as “So, what is the difference then?”
I must admit I struggled to find a good answer to this, until recently. I was working with a good business analyst and I had a bit of an epiphany. The context is the analysis and design of a new e-commerce application that will be implemented alongside an existing suite of e-commerce applications facing off to the same end user. In particular, the login and authentication aspects of that new application.
We are implementing “captcha” codes for this application in response to a change in the security policy while a separate project will be retro-fitting captcha to all existing applications. The use case path under discussion was “what happens if the user fails to correctly captcha after three attempts?”
The implementation had two main architectural flaws: technically, the captcha failure was being handled by the application itself, rather than in the authentication framework; and, functionally, it was being handed off to a specific business team which was different to the central team who handled the same scenario for password failure. But I was having problems explaining this to the analyst who couldn’t see anything wrong – “It worked didn’t it?”
The business analyst’s take on this:
- This component should have all the functionality the user will expect;
- It must comply with our security policies;
- It must comply with our usability and brand guidelines;
- It must cater for all “happy day” and “rainy day” use case paths.
My (the architect’s) take on this:
- Logically this capability is about finding out who the end user claims to be and then satisfying ourselves that this is indeed the case;
- This is a generic component that needs to be consistent and reusable;
- It has hygiene value for the customer – it needs to be there but mustn’t get in the way of the value they are trying to get to;
- In the context of an interaction with us, the customer should only ever be asked to do this once.
It wasn’t until I sat back and mentally drafted the above bullet points that I realised why I was having problems. We were both using the same analytical skills on the same problem but we were looking in two different directions.
| Analyst | Architect |
|---|---|
Tends to focus on physical implementation |
Tends to focus on logical abstraction |
Tends to focus in on the functionality of this capability |
Tends to focus out to the relationships with other capabilities |
Tends to focus down on the detail of the capability |
Tends to focus up to the use context of the capability |
Tends to focus on completeness of the capability |
Tends to focus on the value of a capability |
Tends to focus on whether the capability works |
Tends to focus on whether the capability is reusable |
I’ve deliberately used the words “tends to focus” because this is a spectrum. You will get positions along that spectrum and you must have coverage of the whole spectrum. But, if you need to answer the question “does this person operate more as an analyst or an architect?” you might find the table helpful.
EBAnous 