The Agile family of development methodologies is pushing business analysts into a new role, and the coming IT transformation is pulling them into it as well. The role? Analyzing the business, not the software requirements.
Agile isn't a particularly new topic. It is, however, a particularly misunderstood one, thanks to far too many attempts to turn it into a collection of recipes -- a process, when everything about Agile screams practice.
[ Also on InfoWorld.com: Get Bob Lewis's continuing IT management wisdom in his Advice Line blog and newsletter. | Find out why running IT as a business is a train wreck waiting to happen. ]
Here's Agile in a nutshell: high levels of informal contact between developers and business users, paired with incremental delivery. If a project works this way, it's using an Agile methodology. If it isn't, it doesn't matter if you're following every step described in the Scrum, eXtreme, kanban, or LSD ("Lean Software Development" -- and who coined that sorry acronym?) manual. You aren't being Agile. You're just painting by numbers.
Agile has become important for a seldom-admitted reason: Most business logic is simple (with one exception that we'll get to it in a moment), but the challenge lies with user interfaces, which aren't just complicated, but as matters of aesthetics, aren't even verifiable.
Most of the effort that companies put into business applications goes into the user interface -- into data management screens that retrieve or accept data, subject as many data elements as possible to validation logic, then update a database.
As a result, maximizing the usability of the user interface is a lot of what developers have to do. In fact, you hope that's where most of the effort goes, because if that isn't the case, it goes into system interfaces that have gotten out of hand. The system interfaces are where business logic most often gets seriously complicated -- the exception mentioned above. The more they're a collection of one-off programs, the worse it is.
While not everyone in IT considers investments in the UI to have a big enough payoff to warrant the required effort, it does dominate most application development projects. And given that a bad UI seriously impairs end-user effectiveness, there's no substitute for picking up the phone, calling Fred in the Order Entry department, and asking him to come on down and look at what you have in mind.
But don't stop there. Do this frequently. And don't call in Fred alone; Fred and Susan might not agree on what will work the best.
Additionally, don't just ask them to come on down. Asking them if you can come up so that you can see what they do is a pretty good idea, too.
It's the ratio of UI programming to business-logic programming that's made Agile important. Agile is reducing the importance of heads-down programmers who work from a specification and increasing the importance of programmer/analysts who can do the complete job.