This article assumes you've already read Business analyst with extended role #1: recent arguments.
As we all know, every enterprise is basically engaged in performing "business activities" encompassed in business processes. From enterprise perspective, development of a business application therefore is fundamentally about:
- Defining what BUSINESS ACTIVITIES would be performed using technology
- Architecting those BUSINESS ACTIVITIES "on" the technology ...(a) some of these activities will be done by people on the user interface while (b) other activities will be done "automatically" by system
- Making it all work so that those activities actually can be performed.
As I said in article #1 in this series, teams that develop business applications must extend the Business Analyst's role to include high-level process-centric UI architecture (usability specialists take off from that point).
Here are my reasons . . .
- As explained above, item 2(a) "Architecting the UI" is primarily about designing a business process -- an effective and efficient business process. As it requires business knowledge, industry expertise, and process innovation/improvement expertise, the BA obviously is the professional who is either qualified or trainable.
- When a designer or techie takes over from where the BA traditionally left off (that is, after defining requirements), they introduce a different perspective and the business/process focus is often redirected to factors of secondary importance like usability and aesthetics. Architecture is a crucial "deciding" phase when such a loss of perspective/focus should not be allowed to happen.
- Business-IT alignment continues to elude AND stays on top of enterprise concerns. It is No. 2 in Gartner's 2009 list. A BA with the extended role and skill-set can take the business strategy and processes to effective and efficient implementation/actualization. That is the way to ensure operational-level business-IT alignment.