The Business Analyst of Tomorrow (and Now Today) It is a Software Development Revolution


My company, WorkXpress, has been delivering platform as a service based solutions successfully for over five years now and have had the opportunity to witness first hand on many occasions a new phenomenon that is likely to change greatly the role of the business analyst in organizations. Recently, I was asked to expand on an article published here about that phenomenon entitled "The People that Cloud Computing Forgot - The Business Process Analyst".

To summarize, we are witnessing a marked increase in both the importance of and focus on the work of the business analyst that is directly proportional to the depth with which cloud computing services are utilized. What's more, we are experiencing a shift in the tools and skills that our analysts and those of our customers are required to utilize. We believe this to be more than just theory or prediction, but rather something that we have observed first hand and that will change forever the role and prominence of the business analyst. The forces behind cloud computing can't really be stopped due to their disruptive value proposition, and as a result we are all simply going to have to change with them.

The Inevitability of the Cloud
The first thing that as analysts we need to understand is that cloud-based concepts are here to stay. Many times I see people asking whether the cloud is just marketing hype, or complaining that all of the hype is simply a rehash of existing technologies. Whether or not those claims have any merit whatsoever are completely irrelevant. The cloud is a train that cannot be stopped.

How can I express this with such confidence? Most of the new and emerging technologies we encounter on a day-to-day basis are incremental technologies. They are incremental because the value they bring to the table is an incremental value. They are either complementary to or slightly better then something else that's already out there.

Cloud computing technologies on the other hand are
disruptive. They are displacing many technologies currently out there. Their value proposition is not incremental, it is transformative. Let me give you a real life example;

Company A entered into a large contract with a global automobile manufacturer. They had exactly three months to have an entirely new business process brought online. This process ideally involved automatic receipt and generation of orders electronically, generation of work tickets and routing automatically, generation of new work tickets every time a branch in the assembly process occurred, and ultimately automated integration with shipping and billing. The entire automation was to be based on barcoding wherein operators didn't have to enter data, they simply had to scan work tickets, scan in parts, and so on. Historically, this would be a major task involving months of requirements gathering, iteration of specification documents, and ultimately agreement before development even began. Further, once development was in full swing, the inevitable change request process for a brand new process can bring the whole project to its knees.

However, utilizing cloud based tools, the process went much faster, and was much different. It all started with a full-day requirements gathering session among a large group of key stakeholders. Many spreadsheets, documents and plans were gathered. There was a lot of writing on the board, a lot of back and forth, and a lot of new ideas and changes. By day three, a weekly build estimate was developed that went for the duration of 12 weeks as required by the contract. With the next generation of platform as a service (PaaS), estimation becomes less of an art form and more of a simple counting of screens, fields, automations resulting in faster, more accurate estimates. Because each application element is a more concrete building block with a more understood build time, the estimator simply needs to tally the elements. By day four, work began on a cloud-based PaaS. Over the course of the next 12 build-weeks, there were weekly reviews, hundreds of changes (some of them major), and some usual amount of frustration. But, in the end, a great product emerged, was deployed, and works.

This is a very typical type of project that we've witnessed over and over again. There are two key differences relevant to understanding the new role of the business analyst. First, the application itself becomes the spec document, and it evolves iteratively. The application is literally completed in the same time frame that typically would be required just for the completion of a formal specification document. Second, development is trivialized, and the burden of a successful project shifts almost entirely to the business analyst.

Stating that a specification document becomes less relevant is a highly controversial endeavor. I understand very well that in traditional projects, a specification document is what holds the project together, and that without it, all manner of miscommunication and problems can occur. I understand this very well. What I'm saying is that the very concept of how a project is implemented will completely change "in the cloud"; throwing out many of the norms we've all grown accustomed to.

As if that wasn't enough, there is an even more radical shift on the horizon for the analyst. When we deliver professional services, particularly on smaller or faster projects, the business analyst IS the developer. The time they would spend normally writing specs and managing communications between business users and developers is instead spent simply building the application. This completely eliminates some of the communication pathways, and therefore some of the miscommunication potential, and pairs the analyst directly with the business stakeholders, leveraging a living breathing spec document to drive at a rapid solution.

So what skills are necessary for this new type of business analyst who holds the power to single-handedly automate entire businesses? Most important, this individual needs to grasp large quantities of business process quickly, and assimilate them effectively. Remember, the time frames are all compressed, so the analyst needs to cut right to the important aspects of process definition. A general understanding of them is only the beginning because real value to a client comes in extrapolating that general knowledge into more unique process concepts specific to a given implementation. Our team members have had to cultivate a deep understanding of sales, inventory, manufacturing, billing, purchasing and many more types of processes so that they can quickly communicate with the client both in general terms but also picking up on the unique details of the clients non-standard processes. This knowledge, coupled with vision, is a key asset of the analyst of the future.

Also, the analyst needs to be able to communicate effectively. They need to be able present what can be perceived as radical change in a way that inspires and motivates the business team to want to change how they think and to want achieve results greater than what they were previously imagining. Then, when it comes down to the technical details, the analyst needs to be able to motivate the business user to wrap their head around the details long enough to provide clarity that was properly considered and properly given. The bottom line is that the analyst needs to teach the business users about the tools and options available to them, and empower them to imagine, and to think big. If the client is properly empowered they will meet the analyst half way with regular reviews of the functionality, articulate feedback, and rationale suggestions of alternatives.

Finally, in the most extreme extension of cloud computing; use of a 5th generation development language (5GL) that imparts developmental capability to the analyst, the analyst needs to be able to implement the project. If you are wondering what this is like, imagine building a very large and complex spreadsheet or access database. Automating and entire business process follows those lines. The work is very quick, but there can be a lot of details depending on the specific implementation. Let me provide another example:

Company B uses a manual process to match short-term jobs all across the country with talent located near each specific job. On any given day there could be 100 jobs in various parts of the country that each need a handful of talent to satisfy the requirement. The amount of communication required to solicit talent, qualify them, assign them, schedule them and follow up is overwhelming on such a large scale. Historically, Company B used a time consuming and manual process to make the business work, but at some point they decided they wanted to automate. They investigated traditional development mechanisms, and even began work on a traditional development project, but the results were not good enough to improve the business noticeably, and were expensive; they were likely staring at a 1+ year development process to get the software they truly needed, and this assuming the project would even be successful. Then, they looked to the cloud to find a solution. Leveraging cloud based models and a 5GL platform as a service, work proceeded much as it did with Company A. It began with an all day meeting, which led into a week-by-week estimate of work. In total, five weeks were projected to reach conclusion. In this case, the analyst empowered the client by teaching them the principles of the tools and creating a common ground by which both parties could fluidly communicate. Then, the analyst met weekly with the client to review in detail each week's progress, and to discuss specifications for the upcoming week. Following this process, the clients expectations were adjusted each week, and at the end of the process the client was extremely happy; not only did they have a better solution than they had previously imagined, but also the total cost was far less than what they were expecting from traditional sources. In this example the analyst used all of their skill sets; they developed a detailed knowledge of the business process, they communicated with and empowered the business users and then they actually built the software. As a result of this analysts single-handed efforts, over 30 processors will be transitioning to a new way of working, increasing their productivity by as much as 80% and opening new avenues of growth and profitability for their company. This is a tremendous amount of power to give to the business analysts of the future!

The key thing to understand about deep use of cloud technologies is that everything will move faster, and many formerly cryptic highly-technical things will be made easier. The analysts by themselves now will be able to simply and quickly spin up servers. They will be able to provision and customize software all by themselves. They will even be able to maintain it themselves on an ongoing basis.

However, what doesn't change...what nothing in the cloud will make any easier, will be the requirements of assessing business process, of communicating vision and ideas to business leaders, and of bringing their best ideas into the final result.

The business analyst of the future will need to be a business analyst first and foremost, but they will also need to be a visionary, a communicator and to some extent a leader. They will hold the power in their hands to do everything necessary for any given project. This isn't just fanciful's here and now. As I look out across the office, I see analysts doing all of this even as we speak!

Author: Treff LaPlante has been involved with technology for nearly 20 years. At WorkXpress, he passionately drives the vision of making customized enterprise software easy, fast, and affordable. Treff received his MBA from Pepperdine University and a BS in chemical engineering from The Pennsylvania State University.

Like this article:
  14 members liked this article


savy davis posted on Friday, September 4, 2009 4:44 AM
A wonderful insight on the importance of business analyst role in cloud computing.
zarfman posted on Wednesday, September 9, 2009 7:28 PM

Most of my working life has been spent in the areas of finance and accounting (CFO, VP, etc). Accordingly, my view of the corporate business environment may differ from yours.

If I understand the concept of the cloud aka the internet correctly, I have something called a browser. I type in www dot some name dot three letters and I’m connected to one of more computers. I’m familiar with big rooms full of big boxes and racks of stuff with blinking lights. I’m also familiar with the same kind of room but we didn’t have a browser. My comments and statements of confusion follow.

You wrote “Second, development is trivialized, and the burden of a successful project shifts almost entirely to the business analyst”: Sounds good to me, now we have someone set up to take the blame if the project fails.

You wrote “When we deliver professional services, particularly on smaller or faster projects, the business analyst IS the developer”: To me smaller and faster are relative terms, as compared to what. If I understand correctly, every thing that appears on my or other user’s screens will be provided by the business analyst. Depending on the size of the corporation, there can be terabytes of accounting data. In these cases is there any middle ware and is there a DBA involved or does the Business Analyst take care of that also?

Finance has some really mind bending mathematics. This leads to the question, are there different kinds of business analysts. I find it hard to believe a single business analyst is capable of competently analyzing any and all facets of a complex business. As CFO, I have come in contact with many analysts who claimed analytical prowess in accounting. I would say eight out of ten have failed.

You wrote “A 5th generation development language (5GL) that imparts developmental capability to the analyst”: Ah the holey grail of something or other, aka let’s have the user do his/her applications. In my field of endeavor the only thing that I can recall that has even come close is the spreadsheet.

Barring a time tested 5GL language I have a hard time understanding the benefits. In fact I’m not sure I want my companies’ data zipping around the internet. It seems hacking abounds and hosts come and go. By go I mean fail financially.


Confused and irritable old CFO
Treff LaPlante posted on Monday, September 21, 2009 5:18 PM
Hi Zarfman, I hope this comment reaches you.

Most of your understanding is astute and accurate, clearly bred of years of dealing with software and its problems. I think most of your examples represent the very high end requirements of larger organizations, and I believe you correctly surmise that cloud computing may not yet be mature enough to take these challenges on. Most enterprise IT architecture can be divided into two camps; "core" and "non-core". Most core architecture in the larger companies has already been rationalized by standardizing on something like Oracle, SAP or other applications. However, the next big wave of efficiency gain is to similarly standardize the very diverse non-core architecture...all of those disparate applications, access databases, web pages, spreadsheets, etc. etc. that fill in the thousands of holes that are left by the big core systems. Large organizations I've been told by many sources have as many as one to two thousand of these disparate "systems", each of which need to be managed, audited, etc. This non-core infrastructure is the right next step for cloud computing in my opinion.

I think when you look at the cloud as being a solution to these more discrete (but still very numerous) requirements of non-core systems, many of your questions hopefully will resolve themselves. With the rise of data regulation, and the increasing competitive pressures of cost and reaction time, and if you have an understanding of the challenges of the non-core architecture, I believe you will clearly see the business value.

One very important misconception has to do with your comment about data zipping around the internet. I don't believe "cloud computing" requires this...there is a lot of debate about the meaning of a "private cloud", and my own definition includes the notion of a cloud that's hosted within your own data center. But because of the portability of cloud computing, your staff can make decisions on a case by case basis (actually, the analyst can make the choice guided by policies set in the IT department, or however) whether to check a box and put files out on Amazon S3, or uncheck the box and have the files live on your own servers. For that matter, they can make a similar type of choice to put the application on a server at GoGrid, or within your own private cloud. I hope this makes sense, its a key differentiator of cloud computing versus a traditional mainframe infrastructure.

The key here again is empowerment. The real business value is simply taking away a lot of complexity, and making it faster and cheaper for you to get things done. When a business unit needs an application to receive a certain type of web-based order, process it, and pass it into the SAP system, an analyst can make this happen in a day, whereas a traditional IT process might be year. Further the entire process can be done without provisioning hardware, touching a server, requisitioning a hard get the analyst simply clicks a few buttons.

Your analogy to the spreadsheet is the analogy I use all the time. We saw an incredible wave of productivity occur with the advent of email, the spreadsheet and word processing. I believe cloud computing represents a similar wave of organizational productivity.

I tried to provide examples that demonstrate it. I believe we're seeing it happen right here and now. So, if you're still confused, I'm happy to talk...if you're still irritable...well...we'll see : ).

Treff LaPlante
zarfman posted on Monday, September 28, 2009 5:06 PM

Hi Traff:

Regarding core versus non-core applications. Speaking as an accounting and financial guy, my rule is that if the application or policy doesn’t support the core business in some positive way or it is some renegade application or policy I try and kill it.

Perhaps I don’t understand what you mean by non-core. The function that I tend to consider non-core is Human Resources. I think they should be located in the Legal department because of the many laws involved.

We make a lot of decisions on a case by case basis. However, they tend to be cases based on accounting, financial or SEC rules (transgression can be expensive). Accordingly, specialized knowledge is required. I’m not sure an analyst without knowledge of these rules would be helpful in these cases.

You wrote - actually, the analyst can make the choice guided by policies set in the IT department. Are you suggesting that IT sets accounting policy? I hope not.

I’m not sure I know what the term analyst really means anymore. My guess is many of them don’t have a very good theoretical or philosophical foundation.

I haven’t heard the term “private cloud” before. I may have someone check that out.

I’m definitely for tying offices in different physical locations into a common system. I’ve been doing that for years, no renegade and accounting and financial systems. Might they be called non-core systems?

If I recall correctly, SAP has some software called SAP by design. This may be edging closer to the 5GL you talk about.

When I hear the term simply clicks a few buttons I tend to get suspicious. Historically, I suspect this phrase was coined back in the 1960’s. One can click buttons and get reports, etc. However, producing a complex accounting or financial system with a few clicks, I'm not so sure. If this technology is available in finance and accounting, I’m not aware of it, which entirely possible.

Interesting paper, we most likely disagree on several issues, such is life.


Only registered users may post comments.


Upcoming Live Webinars


Copyright 2006-2024 by Modern Analyst Media LLC