Redefining the Business Analyst Role

With citizen development on the rise, non-traditional applications and data growing, and business changing faster, how is the business analyst role changing?

Historically, the business analyst, also once known as a systems analyst, was an IT staff member who worked with end-business users on requirements definition and design for new systems. Business/systems analysts spent as much time “walking the floor” in the end-business area and observing how business processes did (and didn't) work from the user’s standpoint as they did working with IT technical designers and programmers.

I started my own career as a business analyst in aerospace. I was a liberal arts graduate and the company that hired me had intentionally targeted and hired individuals with liberal arts backgrounds, as it had experienced phenomenal success with a group of liberal arts grads it had brought in from UCLA the year before.

On my first day of work, I didn't know anything about programming, technical system design or really any IT-related work, aside from using a word processor for my master’s thesis. No matter. This large aerospace company felt that I would be “bright enough to pick it up.” Besides, I had all the skills of my UCLA counterparts: I could read, write, communicate and learn.

Later in my career, after I had become a CIO, I understood the wisdom of this strategy. The most successful business analysts on my staff tended to come from liberal arts backgrounds. They were strong communicators and were highly empathetic with understanding their “user-customer” pain points. They advocated tirelessly for their users with their more technical IT colleagues, and they gained users’ trust.

All of this notwithstanding, there were a few “caveats” to the job:

Today's business analyst

Today’s business analyst is still expected to be a consummate communicator and collaborator. However, now with the growth of no-code and low-code application generators and the takeoff of DevOps and Agile methodologies, business analysts are also expected to have a firm command of these methods and of the less technical IT tools that generate apps.

Business analysts are now expected to not only collaborate with business users as they have in the past but also to be active “doers” on IT projects that they undertake. This is in sharp contrast to the traditional business analyst, who seldom got his/her hands into the process of actually developing applications.

Part of this transformation is due to the replacement of waterfall style application development, which had a step by step life cycle of define, design, develop, test, implement, maintain. DevOps and Agile both streamline the application development process and eliminates many of the handoffs among participants would occur in waterfall development. As a result, the business analyst no longer just sits with the end user to define the requirements of an application and to design the process flow of how the application works in the user area -- and then hand off this work to IT. Now, the business analyst must do more.

There are fewer opportunities for liberal arts “no knowledge IT” people to step into a business analyst role in today’s companies. Instead, companies are looking for individuals who have the communications and soft skills of many liberal arts persons, but also the hands-on command of easy to use “para-IT” development tools like application and database generators, or experience working with the cloud

So, given this evolution, what hasn’t changed?

In IT itself, where most business analysts continue to report, the highest value (and salaries) are still given to the technical gurus. Consequently, business analysts must still fight to get the attention of these gurus for their projects.