Connect with us

Global Banking and Finance Review is an online platform offering news, analysis, and opinion on the latest trends, developments, and innovations in the banking and finance industry worldwide. The platform covers a diverse range of topics, including banking, insurance, investment, wealth management, fintech, and regulatory issues. The website publishes news, press releases, opinion and advertorials on various financial organizations, products and services which are commissioned from various Companies, Organizations, PR agencies, Bloggers etc. These commissioned articles are commercial in nature. This is not to be considered as financial advice and should be considered only for information purposes. It does not reflect the views or opinion of our website and is not to be considered an endorsement or a recommendation. We cannot guarantee the accuracy or applicability of any information provided with respect to your individual or personal circumstances. Please seek Professional advice from a qualified professional before making any financial decisions. We link to various third-party websites, affiliate sales networks, and to our advertising partners websites. When you view or click on certain links available on our articles, our partners may compensate us for displaying the content to you or make a purchase or fill a form. This will not incur any additional charges to you. To make things simpler for you to identity or distinguish advertised or sponsored articles or links, you may consider all articles or links hosted on our site as a commercial article placement. We will not be responsible for any loss you may suffer as a result of any omission or inaccuracy on the website. .


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.Ian-Mainwaring

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.


Global Banking & Finance Review


Why waste money on news and opinions when you can access them for free?

Take advantage of our newsletter subscription and stay informed on the go!

By submitting this form, you are consenting to receive marketing emails from: Global Banking & Finance Review │ Banking │ Finance │ Technology. You can revoke your consent to receive emails at any time by using the SafeUnsubscribe® link, found at the bottom of every email. Emails are serviced by Constant Contact

Recent Post