Skip to main content

Business analyst with extended role (#2): reasons why

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:
  1. Defining what BUSINESS ACTIVITIES would be performed using technology
  2. 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
  3. Making it all work so that those activities actually can be performed.
Answers to "who does what?" are fairly consistent for most of the items above: the Business Analyst (BA) for item 1 and the technical team for items 3 and 2(b). When it comes to item 2(a) though, we don't see the same level of consistency. User interface (UI) specialists, technical team members, and even BAs have been responsible.
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 . . .
  1. 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.
  2. 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.
  3. 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.
Is this a proposed idea or a proven approach? I will answer this question in article #3 in this series!


  1. Hi,

    I have had an opportunity to work in a product company as well as process companies (now am with Cognizant and got to read your blog via the IIBA group).

    Till the point I entered a process company, I have been doing the UI architecting while gathering requirements - and so was under the assumption that getting the UI right was a BAs job just as getting the requirements. Every time i did a UI, i would think in terms of the usability, et al.. (i have sat counted the number of clicks and have spent time figuring out if there is still a better way to achieve the end result with less clicks...)

    But my experience with process companies is different. the entire project execution process is different. the way BAs are treated is different... Its here that I got to meet specialized UI Groups doing what I thought was my job... While I have nothing against specialised UI teams, I definitely agree to the fact that a BA who understands the biz needs of the project and elicits requirements will be able to elicit the required UI as well.

    I have experienced the second point of your reasoning. I had to refit requirements in a case so that it aligns with the UI that were produced by the UI team after the req. phase. This led to a great deal of confusion and added challenge of getting the stakeholders to understand that req. describe the WHAT not the HOW so not every change in the UI needs to be fitted back to the req spec just for the sake of establishing traceability...

    To end, I vote the ability to architect the UI as one of the skills a BA must possess - to me its not a "nice to have" but a "must have" skill.

  2. Mayuri, thanks so much for sharing your experience and insights.

    As pointed out by a few BAs at the IIBA's Linkedin discussion, it is not uncommon to see software teams asking BAs to architect the UI. Usually it is done becasue the project manager thought it was smarter to use fewer resources or had other reasons such as non-availability of trained UI experts.

    However, when I recommend that BAs do UI arch, I do so for the 3 different reasons I outlined in the article. And -- more importantly -- I'm talking about having the BAs specially trained for the "new" extended role ... not in conventional UI/usability engineering, but in business process centric UI architecture.

    In fact, if you view the UI differently -- as business process -- then you might find the extended activity interesting and intellectually challenging as well!

  3. Pradeep ... This is interesting. I think you are right in that there is a dislocation between requirements development and implementation. We use knowledgebase building software in conjunction with workflow building software so that as you map our entities (customers, locations, products, programs, staffing, policy/procedure, 3rd party rules/regulations) we also ask the client to walk us thru some of the workflows (very high level) and we then give this to the implementation people.

    The implementers have to as you say, come up with a day-to-day processor that can handle some tasks that are done by people and other tasks tha can be done by software. (e.g. example, in a hospital that only handles children when the patient comes in the door, we pick up age and so at any point in a process that has branching on age, the software can handle this on its own.


Post a Comment

Popular posts from this blog

Explorer mentality Vs conqueror mentality

A fixation on competitors and on beating them is evidence of what Amazon's Jeff Bezos calls a conqueror mentality. In contrast, people waking up in the morning thinking how to innovate for the customer -- and having intense fun innovating -- is evidence of an explorer mentality.

The explorer mentality resulted in Amazon allowing negative reviews of its products. Reacting to this, a book publisher objected, saying "You make money when you sell things." But Bezos thought, "We don't make money when we sell things; we make money when we help customers make purchase decisions." So explorer mentality also demands a willingness to be misunderstood for long periods of time.

During his 16 years as CEO, Bezos' Amazon has delivered shareholder returns of 12,266% (industry-adjusted), and the company's value has grown by $111 billion. More in HBR Jan-Feb 2013.

M&A perspective: IT staffing Vs IT consulting

This report is a simple analysis by HT Capital -- a boutique investment banking firm in New York. It basically makes the point that being a staffing company (Vs consulting company) does not provide adequate returns to most investors, especially from an M&A perspective.

Peter Rozsa, co-author of the report, is a Senior Managing Director at HT Capital. He was also my "classmate" at a Columbia Business School executive education program. I have Peter's permission to make the report available here.

Click to download PDF report.

Leading Change Vs. "Leading" Status Quo

Change and Status quo can be as far apart from each other as a butterfly is from a caterpillar ...

Or ... as an is from a K-Mart ... Or ... as a BMW is from a Hyundai ... Or ... as laying a runway is from paving a cow path ... Or ... as a solution is from a product ... Or ... as experience is from service ... Or ... as customer success is from customer satisfaction ... Or ... as a distinct brand-you is from a me-too employee ...

Change can be triggered by innovation. Change can happen in corporate culture. And so on. There is a leader "behind" every Change. If you consider the corporate world, people like Lou Gerstner, Michael Dell, and Jack Welch may come to mind. Actually, there are scores of other lesser-known and unknown leaders that make change happen in their organizations.

Here's my question: What are some differences between those who lead change and those who "lead" the Status quo? Oh yes, we know about the staggering percentage of Change i…