Gone are the days when technology was associated with computers and hardware only.  Although there can be a physical component associated to an IT project, this is not always the case.  The Business Analyst’s job is to make sure that the solutions match the business needs.  Usually, the hardware component needs of a project are passed on to a Technical Architect, but the “flow” and understanding of the system usually lies in the hands of the Business Analyst.

So what separates a Business Analyst from a Technical Business Analyst?  More frequently now  employers are posting “Technical Business Analyst” when looking for Business Analysts for their ICT projects.  They prefer somebody who understands both “business” and “IT” jargons so that they can coordinate with both the client and the developers.  We have to face it, the business know their own thing and the developers know theirs but sometimes they may not be able to understand each other so that’s why a Technical Business Analyst must come in.  The Technical Business Analyst usually knows more IT concepts than your average Business Analyst but really, most of the time what separates them are the following:

business analysts at work

Technical Business Analyst Skill #1: An Understanding Of Programming

There was a time when we look at an application like a conveyor belt.  We put a raw material on the conveyor belt then the material goes through a set of procedures until it becomes a product (i.e. the output).  That is pretty much how procedural programming works.   Procedural Programming goes from step 1 until step n  to get your results.  However, with the dawn of Object-Oriented programming, the inside of our applications changed too.  Instead of having long procedures, we now have objects, what their attributes are, what they can do and how they interact with other objects.  Imagine a simple Hospital System: 

  • The objects involved can be  the following: Patient, Doctor, Operating Room
  • The attributes of the object “Patient” can be the following:  Name, Age
  • The interaction involved between the Patient and Doctor could be the creation of a Booking and a Diagnosis

So a Technical Business Analyst  needs to ask the following questions:

  • What are the objects in my application?
  • What are the attributes of these objects?
  • How do these objects interact?

 A Technical Business Analyst may also be expected to know the following Object-Oriented programming concepts:  Class, Objects, Attributes, Methods, Packages, Inheritance, Polymorphism.  Note that he does not necessary have to know how to program. He just needs to understand how developers see a system.

Technical Business Analyst Skill #2: An Understanding Of Databases

A database is a collection of data. A database can have many tables and it is part of the Technical BA’s role to tentatively determine some of the tables (and fields) of the databases.  I say “tentatively” and “some” because depending on how the Technical Team designs the DB, there may be additional tables or combined tables at the end of development.    

To determine the Tables and Fields of the database, the Technical BA asks the same three questions mentioned above:

  • What are the objects in my application?
  • What are the attributes of these objects?
  • How do these objects interact?

The objects and interactions usually represent the tables.  So in our example, the tables can possibly be the following: Patient, Doctor, Operating Room, Booking, and Diagnosis.  

The attributes of the objects are usually the attributes of the Table.  So for the Patient table, the attributes can be Name and Age. 

Tables representing the interaction can have their own attributes too.  The Booking table, for example, can have Time and Date as its attributes.

 A Business Analyst can be classified as a Technical BA if he has an understanding on how to create Entity Relationship Diagrams (which is a representation of the database structure) and apply Normalization rules.

Technical Business Analyst Skill #3: An Understanding Of SDLC Methodologies

Technical Business Analysts are usually hired for IT Projects. Given that, he must be at least familiar with the Software Development Life Cycle (SDLC) Methodologies.

There are different SDLC Methodologies. The more traditional companies follow the waterfall methodology where the project is divided into distinct phases (i.e. Analysis, Design, Development, Testing, Deployment).  Big, old companies were more comfortable with this approach but this has been changing and today, more and more companies are employing an Agile Approach, particularly the Scrum Methodology.

There are different types of Agile Approach but all of them are characterized by iterative development where the product is not just deployed in a “big bang”.  Instead, there are iterative developments and deployments, allowing the client to review the product earlier.  

One of the most popular Agile Approaches is the Scurm Methodology.  In Scrum Methodology there are teams and, ideally, each team member can analyse, develop, and/or test. Of course, in reality, this does not happen.  Each team member has his own forte. 

Development, in Scrum Methodology, is divided into sprints (usually 2 weeks) where the application is analysed, developed, and tested.  Note that it is common practice that the version of the app being developed is different from what is being tested for the sprint.  Analysis meanwhile is for the future version of the application.

As a Technical Business Analyst, you should be able to work with the Development team within an SDLC Methodology.  Since more and more companies are moving towards Agile, then knowing about it, especially the Scrum Methodology will be good for your career.

Consider reading more about the Scrum Methodology and take special note of what the differences are between the traditional business analyst and the Product Owner. 

So Why Do Employers Look For Technical Business Analysts for their IT Projects & Projects?

IT Projects are becoming more and more important to an organisation. Management would want the Business Analyst to be highly involved not just in the planning stage of an IT Project but also during the development and deployment of the application. An ordinary business analyst could create a good Business Case for planning purposes, but it is a Technical Analyst who could create good Functional Specifications for an IT System.  With a Technical BA, (1) gathering of requirements becomes more IT disciplined, (2) requirements specifications become more technical for the benefit of the  IT Team, and (3) the proposed solutions become more feasible.