Business Analyst, IT Must Be Buddies for Effective Business Intelligence
One of the songs in the musical “Oklahoma!” involves a politician attempting to persuade farmers and ranchers to be friends, so they can present a united appeal for statehood. Of course, says the rancher, I’m happy to be friends, even if the farmer’s fences are constantly injuring my cattle. Absolutely, says the farmer, I’d love to be friends, although the rancher is constantly trampling my crops. They end up pretending to be friends while glaring at each other.
Is there a similar dynamic at play in the new world of business analytics? Today business analysts are rapidly implementing and incrementally refining new analytics capabilities that yield useful new insights, based on incessant interactions with other business folks who are the end users of their solutions. In fact, the process of business analytics implementation resembles nothing so much as that of agile software development.
So who is a big hindrance? Why, IT, that “hideously inflexible” (in the words of one respondent to a recent Sloan Management Review survey) bureaucracy that guards the data warehouse – according to the business analysts interviewed by SMR.
Meanwhile, 25 years after programmers started talking about the concepts (e.g., fourth generation languages) and 10 years after the arrival of the Agile Manifesto, most IT development shops are awash with Scrum-type agile programming, spiral processes, user stories, technical debt (the idea that code should be refactored periodically to ensure ease of further change), and the use of agile development techniques to achieve agile business intelligence.
And who is a big hindrance? Why, that rigid, unresponsive business bureaucracy that demands and then objects to cost estimates for a process whose time span is by definition indeterminate, and imposes counterproductive formal project management and “governance.” Business analysts, by definition, must be part of the corporate bureaucracy.
And yet, the business analyst and the IT programmer should be friends, or at least effective collaborators. They are carrying out separate agile processes, and the value of these to business intelligence and to overall business agility is halved if they fight with each other instead of abetting each other. Collaboration doesn’t necessarily require that the two cultures be friends; but it does require that organizations think carefully about how to mesh the two without diminishing the enormous, productive reservoirs of enthusiasm that each side brings to its tasks.
The Dual End User Approach
The key to business analyst/developer cooperation is the fact that they should be tackling different levels of the same problem. That is, the business analyst is more tactical. He or she moves briskly from immediate problem to immediate problem.
Meanwhile, the business intelligence developer is (or should be) more strategic. He or she moves briskly from new type of analytics functionality to new type of analytics functionality. So, for maximum effect, each of their agile processes should feed into the output of the other.
To achieve this, I propose what I call the “dual end user” approach. That is, in a certain number of cases at least, one side should take on the role of the end user, with the other taking on the more familiar role of the implementer. Then, as appropriate, they should switch roles.
Let’s see how that would work out in a particular case. Suppose the business analyst is implementing a factor analysis of social-media data, but the necessary statistical tools are not there. In this case, the developer first acts as an end user, while the business analyst tries out various factor analysis capabilities that will also satisfy future factor analysis needs.
At that point, the two switch roles. Having created a general factor analysis “core capability,” the developer now tunes that solution for the immediate needs of the business analyst “end user” – who can then apply them to the needs of real end users.
The obvious objection to this is that it produces two additional sequential processes before the business analyst delivers a solution. Not at all; the business analyst and agile developer can actually to a large extent perform their own processes in parallel with the two processes cited above. They can, in fact, (if they want) perform the two processes simultaneously. The only additional complication is that both business analyst and developer are dealing with two end users — the “real” end user and each other — instead of one.
The positive result of the “dual end user” approach is that both IT and business analysts are no longer slowed in their processes, the business analyst by waiting for IT to supply general capabilities, the business intelligence developer by no longer dealing with lack of information about use cases from the “cowboy” business analysts. The subtle cultural effect of the approach is that neither the developer nor the analyst should wind up regarding each other with quite as much frustration or disdain.
Wayne Kernochan has been an IT industry analyst and auther for over 15 years. He has been focusing on the most important information-related technologies as well as ways to measure their effectiveness over that period. He also has extensive research on the SMB, Big Data, BI, databases, development tools and data virtualization solutions. Wayne is a regular speaker at webinars and is a writer for many publications.
