Hey Dude Where's the Data Analyst Gone!

Sitting over a couple of Margaritas the other week with a friend, she moaned to me about 2 of my chief grouches: No one appears to do data analysis anymore and the hijacking of the word Architect into every job title.

The data analysis issue is a serious threat. Digital depends upon data and if you want to be continuously evolving and moving, getting the data structure right so that it accommodates likely future changes and enhancements will only make you more agile and responsive. Not doing it means rewriting almost everything when you change your data requirements slightly.

There is more to it than that, another friend who was a leading methodologist in his day, used to drum into every business analyst that he met that functional analysis, when conducted independently of data analysis, is at best incomplete and at worst totally skewed from reality. He was right. anyone who has done 2 activities in parallel, knows how much data analysis makes you think things through. It also produces a very useful diagram which if you draw and read it correctly will concisely articulate a lengthy essay on the requirements of the business system being analysed.

So why is it that so few analysts actually learn the technique and use it? It's a fairly easy and straight forward technique to master and essential for getting your application right. It works well when used alongside structured interviewing to help the analyst gradually build a picture of the overall requirements and helps identify essential questions.

The other rant of the day was the over use of the word Architect, especially in the job title Solution Architect. This is often coupled with a misunderstanding of the role. It seems that everyone thinks "Architect" is a sexy word and inclusion of it in their job titles will boost their importance (& pay) by at least 20%. The trouble is that a lot of people trying to do this are really designers, working at a different level of detail.

An architect is interested in the overall framework, which ensures that all the major components integrate into a coherent solution. The designer mainly focuses on how the individual component will work. There is an overlap, of course, but there is a danger in confusing the roles, because people tend to be biased in nature to one role or the other. If only one of the roles gets performed, then the solution will probably be sub optimal. This is very important in agile delivery teams, as architects need to know when to back off and let the developers do their thing. This allows the Architect time to anticipate any major future technical decisions and address them before the lack of direction impacts on the developers ability to deliver usable code within a coherent and complete framework.