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!

Comments

  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.

    ReplyDelete
  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!

    ReplyDelete
  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.

    ReplyDelete

Post a Comment

Popular posts from this blog

Business model intimacy

Courtesy: NobelPrize.org
The Grameen Bank success story continues to be researched and written about. Other companies have tried to repeat the Bank's model. Is there a fundamental difference between the original innovation and the followers? In MIT Sloan Management Review (Summer 2009), Erik Simanis and Stuart Hart compare the original model with that of India-based Hindustan Unilever's model and point out a crucial difference.

Grameen Bank was a result of personal bond and shared vision between Nobel laureate Muhammad Yunus and Bangladeshi farmers/villagers. Yunus and the villagers spent quality time together as a community before the innovator launched the bank. While Grameen Bank became a profitable and scalable village bank, the authors say that Hindustan Unilever's project is "unlikely to grow into anything more than a new distribution channel." While Grameen Bank generated a "groundswell" of demand," Hindustan Unilver's entrepreneur turnov…

clinton/obama/media cabal to be exposed starting june14

A lot of people have surrendered themselves to be constantly duped by leftist media outlets.

The duped people now believe things that are entirely different from facts – as regards the obama/clinton/media cabal.

For the duped leftists, the coming Inspector General (IG) reports and follow-up actions (assuming they're both carried out unobstructed) will be a shock.

The shock will be so powerful, the duped leftists may react in insane and dangerous ways. (Well, they've already been behaving in such ways, but they've been doing so for a different set of reasons and largely unaware of facts.)

Broadly, the IG reports are going to be about treasonous/ unconstitutional/ illegal activities, power abuses, and obstructions for the purpose of:

1. Exonerating a criminal Hillary

2. Covering up the crimes of the Clinton folks

3. Attempts to block a presidential candidate

4. Attempts at a coup against a constitutionally elected president

5. Obstruction of presidential duties

6. Public deception…

Elon's April 1 tweets: part of an emerging leadership style?

First his tweets and then my comments ...

Tesla Goes Bankrupt
Palo Alto, California, April 1, 2018 -- Despite intense efforts to raise money, including a last-ditch mass sale of Easter Eggs, we are sad to report that Tesla has gone completely and totally bankrupt. So bankrupt, you can't believe it. — Elon Musk (@elonmusk) April 1, 2018
There are many chapters of bankruptcy and, as critics so rightly pointed out, Tesla has them *all*, including Chapter 14 and a half (the worst one). — Elon Musk (@elonmusk) April 1, 2018
Elon was found passed out against a Tesla Model 3, surrounded by "Teslaquilla" bottles, the tracks of dried tears still visible on his cheeks.

This is not a forward-looking statement, because, obviously, what's the point?

Happy New Month! pic.twitter.com/YcouvFz6Y1 — Elon Musk (@elonmusk) April 1, 2018
Almost all commenters appear to love Elon's April 1 tweets. But one person commented "CEOs of public companies shouldn't be putting out tw…