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.

posted @ Tuesday, August 25, 2009 12:01 AM by adrian