Analysts and architects

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.

Advertisements

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 Delivery Mode, Philosophy of EBA. Bookmark the permalink.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s