The Rise of the Technical Analyst

Ian Mainwaring, Senior Consultant, Citisoft

Wouldn’t it be nice if… development timescales could be reduced by 50%, the number of people needed to complete the project could be reduced, and so many requirement details were not ‘lost in translation’ as they pass between business users, business analyst (BAs) and developers? Well, it’s possible that the emergence of the Technical Analyst (TA) will be part of the new development process that allows this wish to be fulfilled.

Many organisations are still structured so that there is a distinct division between business teams (the business analysts) and technology teams (the developers). This is at least partly because of a clear distinction in roles performed by individuals in each group. This division is most noticeable when an organisation takes a traditional waterfall approach to projects, but even in a more enlightened organisation which has embraced an agile methodology, with business and development teams more closely aligned, there is still a clear distinction between roles. In either approach the business teams document the requirements (business requirement documents or user-stories) and technology builds the solution. (Correction of the misunderstandings happens throughout the testing process; and sometimes well beyond that!)

Now, imagine that as part of producing the appropriate business requirements, something more like a self-documenting and executable set of business logic, rather than just the requirements documentation were delivered to technology teams. This is a very powerful approach, with obvious cost saving benefits, but it requires a number of changes to current standard practices in order for it to work. To start with, the TAs delivering the solution package will require different tools and different skill sets from those employed by traditional BAs.

Foremost among the new tools and practices needed will be support for Model Driven Development (MDD). This is the use of data structures (of many different types) and the associated relationships and metadata about these structures needed to build business flows, business rules, and transformations between the structures. The relationships and TA-defined transformations are then interpreted to automatically generate the necessary application code to implement the transformation. Generally speaking, the tools used to support MDD ‘hide’ the detailed technical intricacies – e.g. the automatic generation of Java code to support an interface adapter. The more sophisticated the MDD tool, the more hidden from the user this technical detail is likely to be.

The increasing use of these tools will require organisations and individuals to revisit their structures and skill sets, as tasks are rolled together which, historically, have been parts of different competency sets. This may mean BAs becoming comfortable with tools that require more technical awareness, and developers having a greater business understanding. Thus, the blurring of the traditional roles of BA and Developer – to create the new hybrid “Technical Analyst”. Likely candidates for the new roles will be traditional BAs who are ready to become more comfortable with technical tools – and developers who are always asking “Why?”.

In this new context the role of the ‘pure’ developer and technology teams also changes. Firstly, they will be called upon more and more to provide libraries of functions that can be used, and re-used within the MDD toolset. These objects will have to be genuinely re-usable as their context will only be defined when the Technical Analyst uses them. And secondly they will need to integrate the code delivered by technical analysts into the appropriate application framework and messaging infrastructure.

So, which technical skills are required for BAs to evolve into Technical Analysts? Becoming Java or C# experts? Understanding messaging frameworks? The short answer is – none of the above.

The MDD tools must take these real technical aspects away from the user. The technical skills required should be similar to those needed for intermediate level spreadsheet macros and functions. It is more of a mind-set change required from the BA; to embrace the new tools and invest time to learn how to use them. The TA will have to think more like a developer, but not actually be a developer and the developer turned TA needs to move away from the “..real developers hand-code everything…” mentality.

Using MDD tooling and its associated metadata repository, the TA should be able to construct a solution by linking together sets of (newly created, or re-used) ‘business components’. The key point here is that both pre-existing business components and newly developed ones are stored in the metadata repository – together with the metadata to describe them – and become part of the evolving MDD environment.

The evolution of the tooling to empower the Technical Analyst (TA) in an organisation is only one part of the equation. The organisation must also recognise the fact that the traditional roles of BA and developer are changing. Approaches to creating project teams should reflect this. There is no ‘one size fits all’ solution to the BA / TA / Developer mix, and the answers will vary between organisations and also between projects within the same organisation.

The key point to recognise is that to reap the full benefit from using new tools to build technology solutions requires both individuals and organisations to evolve and adapt.