Top 10 Key Business Analysis Trends For 2012


Top 10 Key Business Analysis Trends for 2012What would the start of 2012 be without a tradition I’m pleased to continue to uphold: the unveiling of this year’s top 10 business analysis trends. This year business analysts (BAs) will need not only the balanced portfolio of technical and business skills they have been perfecting, but also a more comprehensive perspective in order to meet the challenging business environment of 2012. BAs will need to broaden their linear thinking and adopt a three-dimensional approach to provide effective requirements management and development (RMD) that drives real business impact. With a 3-D mindset BAs will be able to better manage the dynamics of their profession and the organizations in which they work as well as maneuver challenges and leverage opportunities that will build their career paths.

Many of the trends identified this year have been ongoing for several years and they continue to evolve along with the practice of business analysis.

Demand for greater organizational efficiency will increase demand for business architecture, business rules and business process experts
Unrelenting economic and financial pressures perpetuate this trend from 2011 as organizations are finally starting to focus on becoming leaner and more efficient. The ubiquitous mantra of “do more with less”, and questions such as “how do we become more agile-like?” have taken hold. Economic woes have essentially changed the organizational mindset so that people are myopically focused on the business side rather than the IT side and realizing that creating business efficiencies doesn’t necessarily mean more technology.

In five years we are likely to see technology mature to meet new business demands, but not until organizations have money to spend on technological infrastructure. So, this year organizations will again rely on business analysis to examine business architecture, rules and processes that will enable internal improvements in efficiencies.

Federal, state and local government agencies will invest seriously in the role of business analysis
After having spent billions of dollars on contract management and project management to fix their troubles, government agencies have finally seen the light that poor articulation of requirements is at the root of many of their functional ills. Taxpayers demanding “more bang for their buck” will have all levels of government seeking better RMD to fulfill their missions. Calls for agencies to be more efficient in serving the public, more collaborative working across agencies and more accountable for ensuring that procurements are delivering what they are supposed to will make business analysis indispensible to their success.

It’s important to note that this will be a slow moving trend, much like the way the pace of government moves. Still in its infancy, the trend is first starting to pick up at the state and local government levels where they are rallying the troops around business analysis to articulate requirements so they can adopt them correctly.

Agile methods will continue to gain traction
Having appeared on the top 10 BA trends of 2011, agile adoption shows no signs of letting up and is again among this year’s top 10 trends. With higher project success rates than traditional IT development methods (67 percent for Agile vs. 50 percent for traditional development according to results from Scott Ambler’s 2011 IT Project Success Survey posted at
), Agile will continue to be the leading framework on which to base quality deliverables in 2012.

But it won’t be without growing pains. BAs and project managers will struggle to fit their title into the Agile space, but will need to realize quickly that it is not about them—it’s about the end state.

Emergence of a hybrid role of project manager and business analyst
The drive to create greater organizational efficiencies will spur the global emergence of a project role that mixes the project manager and the business analyst. Lack of resources is a key driver of this trend since many organizations cannot afford the luxury of having a utopian team in which project management and business analysis are conducted by separate individuals—why not get two roles filled for the price of one salary?

Another factor in this trend is the inability of organizations to foster collaboration among its project teams. If you can’t all just get along, get one person. The widespread adoption of Agile practices will further drive this trend. Agile’s all-hands-on-deck approach has little use for titled positions.

This trend will not come without risks, however. An imbalance on either the business analysis or project management side could result, depending on the background of the practitioner.

Business analysts will enhance skills to make their business case to stakeholders
Far too many talented BAs have been missing the mark in their interactions with stakeholders and it’s time they polished their delivery in order to effectively manage expectations. In 2012, BAs will need to step up their game, not only in presentation and communication skills, but they will also have to be proactive in articulating the value of the projects they propose in order to make effective business cases to stakeholders.

BAs are traditionally known for being good at collecting data, but also for being less than scintillating at presenting it. Optimally, BAs should take on almost a leadership role that will force them to increase their level of interaction as well as the level of people with whom they interact to really sell the benefits of the product—and the contribution of business analysis—to the organization.

BAs will need to measure results to prove results
This trend continues in 2012 as BAs will be under enormous pressure to quantify their work, and it will continue to be an issue for BAs each year. Undoubtedly, this is a trend that has to grow. Unless BAs apply their skills in elicitation and requirements management—graphical modeling, cost estimates, risk analysis and other measurements—they and, ultimately, the organization will not be able to quantify the BA’s impact on the business.

Centers of excellence will continue to spread
The resurgence of business analysis centers of excellence predicted for 2011 is continuing to proliferate in 2012 as organizations look to a centralized and focused group of specialized individuals to manage very complex enterprise-wide engagements. The driving force behind this is the focus on business architecture and resulting needs that are much bigger than many organizations anticipated initially.

In our practice at ESI, we’ve seen a tremendous amount of interest, client requests, articles, white papers and other activity around growing centers of excellence in the last year, and it shows no signs of letting up.

BPOs to invest in the development of their business analysis practices
Business process organizations (BPOs) in India are investing heavily in building business analysis capabilities in response to their clients’ deficiencies in the field. It’s a win-win for BPOs and their customers since the process of selling bundled software development, project management and business analysis services as an entire package improves project outcomes and mitigates project risks. Having experienced failures from developing software based on requirements their customers provided, BPOs are taking a proactive, foundational approach. This will also lead to a growth in onshoring as formerly offshore BAs will be working at their customers’ locations throughout the world.

India will emerge as the shining star of this trend through their global customer reach. Bonus trend: More business analysis certifications will come out of this country than any other in the world.

Rise of tablet tools for business analysts
BAs will put the awesome visual power, functionality and portability of tablet tools to work in their practice, particularly in client interactions. Writing, drawing or creating models on a tablet will enhance visualization and decision-making. Due to their flexibility, tablet tools will enable BAs to get the right details, right on the spot.

This will prove to be a sweet spot for software vendors as demand increases for analysis tools, educational tools, modeling, mapping and other applications BAs didn’t even know they needed.

IIBA Building Business Capability conference will gain prominence for professional development
If anyone needs evidence of the strength, size and influence of the BA community, they need to look no farther than the International Institute of Business Analysis (IIBA®) BBC conference. A growing phenomenon, the BBC should double in attendance and attract more delegates from all over the world as the business analysis discipline continues to mature, define specialized niches of practice and gain recognition among practitioners’ organizations. The advancement of the BA profession will elevate the BBC conference to a position of prominence among all project management events.

What does it all mean?
Business analysts are dealing with a Rubik’s Cube of variables as they consider tasks, responsibilities, stakeholders and other factors in the requirements mix. The increasing demands and expectations for RMD in 2012 require business analysts to shift to a new way of thinking. In order to recognize and accommodate the endless permutations for managing requirements effectively, BAs will need to discard narrow viewpoints and approach their work from a 3-D perspective.

For those of you keeping track, here’s a brief recap of how the top 10 BA trends of 2011 that were not referenced above finished out last year:

Business analysis will guide the surge in cloud computing: This trend may have been somewhat optimistic. Organizations are still interested in cloud computing, but it may have taken a back seat to the preparation that preempts migration to the cloud. This is a trend that’s still simmering.

RMD will lead in delivering smart business perspective: This trend was probably one of the most prescient of the 2011 trends. Business architecture has never been more prevalent, while BAs are being forced to measure and quantify and balance their skills portfolio. This all has been the result of focusing on people working smarter in order to make smarter decisions for the business.

BPMN will solidify its reputation as the industry standard: Business Process Modeling Notation has absolutely taken the lead in the field. According to the report, “Business Process Modeling Survey” published by BPTrends in December 2011, of the respondents who use process modeling tools, 72 percent use BPMN.

BAs will be recognized as critical to change management to avoid troubled projects: This trend showed early promise but was quickly forgotten as BPMN and business architecture took prominence.

RMD will be essential to regaining market share: This still holds true, and is growing and becoming more critically important. However the movement isn’t quite as strong.

RMD will continue to struggle to define itself: The struggle continues, but we’ve taken steps that have gotten us closer to defining ourselves through BPMN, Agile, the combination of hybrid roles and other developments in the discipline.


Glen Brule - CBAPAuthor: Glenn R. Brûlé, CBAP, CSM, Executive Director of Global Client Solutions, ESI International, brings more than two decades of focused business analysis experience to every ESI client engagement. As one of ESI’s subject matter experts, Glenn works directly with clients to build and mature their business analysis capabilities by drawing from the broad range of learning resources ESI offers. A recognized expert in the creation and maturity of BA Centers of Excellence, Glenn has helped clients in the energy, financial services, manufacturing, pharmaceutical, insurance and automotive industries, as well as government agencies across the world. For more information visit

Like this article:
  43 members liked this article


Rildo Santos posted on Tuesday, January 3, 2012 8:24 PM
I like this post. I consider what The trends are positives for 2012.
Tony Markos posted on Thursday, January 5, 2012 8:23 AM

Taking a more Agile approach, hybrid BA/PM, better interaction (i.e., presentation skills) with stakeholders, etc., are all great forward steps. The question I have is: Are BA's mature enough to grow along the lines you mention.

I really doubt it. I will go so far to say that vast majority of BA's can not even articulate how to accomplish the basic essentials of analysis.

Without knowing how to logically partition a system and unawareness of the non-sequential nature of systems, to give two examples, BA's can not move on move to the higher level goals that you mention.


LLMABA posted on Thursday, January 5, 2012 1:55 PM
Tony: I am not quite sure what size work environments you gained your experience, but in large financial and government agencies, the lines of communications can get complex. The CEO or VP of Marketing doesn't care how a server disk will be partitioned. Executives only care about results. The role of the Business Analyst is to make sure the stakeholder requirements are communicated (written or verbal) to the server engineers. I remember having a two hour conferfence call with 150 people discussing the pros and cons of a double nic network card. BA's are essential to the success of any large enterprise application especially when there are heavy deadlines and stressfull situations.
Tony Markos posted on Friday, January 6, 2012 5:40 PM

By " logically partitioning a system" I mean dividing up the business requirements in a way that leads to effective decomposition. And effective decomposition of requirements is necessary in complex projects.

Common dictionary definition of analysis: Partitioning a system into its component parts and then examining how the parts interrelate. Analysis, especially of systems, is largely about partitioning.

With out partitioning skills, I do not think that BA's are near being able to move on to higher level goals.

Charu posted on Sunday, January 8, 2012 4:36 PM

I like the post as well. I totally agree with the trends and it is a very positive indication that BAs will play a critical part in the success of projects as always!


I am not sure what you mean by the statement "vast majority of BA's can not even articulate how to accomplish the basic essentials of analysis."

This is really not true.

I have been a BA for at least 15 years now and I see that many BAs do have the maturity level and are already playing the critical role with stakeholders, involving themselves with business case and roadmaps for the organisation.
I have been through at least 9 different organisations during the last 10 to 15 years (as a contracting Senior BA) and have seen at least a few BAs in every organisaton with that level of maturity, width of knowledge, playing a great part in large projects.

I am not sure whether your experience with BAs is where someone who is not a professional BA is playing the role of a BA.....

Tony Markos posted on Monday, January 9, 2012 9:00 AM

Let me give you an example of what I am talking about. Especially iIn larger scale analysis efforts, effective decomposition (i.e., partitioning) is needed to handle complexity. And this decomposition often needs to go downward many levels If this decomposition is not accomplished in a logical way, the result is a mess.

What guides you through a logical decomposition of the system at hand?

Note: This is an example of a basic, key, fundamental BA skill requirement that very few BA's are even aware of. Not even the BABOK really talks about the need for such skill. And with a knowledge of the basics, BA's can not move up the maturity scale.

Glenn Brule posted on Tuesday, January 10, 2012 9:03 AM
Hi there Tony,

You make some valid points in your comments and others that are somewhat of a cause for concern. I think it's a hasty generalization to comment;

"Are BA's mature enough to grow along the lines you mention.I really doubt it. I will go so far to say that vast majority of BA's can not even articulate how to accomplish the basic essentials of analysis."

My approach to this is that BA's really have had a bum rap in getting executives and management to buy into the value of business analysis, I believe both parties are to play and as a consequence we are really only starting to see investments in competency development for both functional skills and soft skills. Being a senior business analyst I'm certain that you would agree with me that you simply didn't not jump into this role with an inherent ability to " how to logically partition a system and unawareness of the non-sequential nature of systems". With experts such as yourself I would hope that some of your time is coaching and mentoring some of the intermediate and junior BA's to inherit that which is so vital and critical to the success of requirements management and development activities.
Tony Markos posted on Wednesday, January 11, 2012 8:45 AM

You and I must live in different worlds. Based on alot of experience I will go further than my initial statement: to me it is really shocking how many at the executive director level can not articulate how to accomplish some of the basic essentials of analysis.

The basic skills that I refer to - like how to partition a system for effective decomposition - are not skills that require alot of experience to understand. I learned these skills in an introductory Requirements Specification course back in the 80's.

What has happened since the 80's? My observation: the increase drive for firm due dates has caused analyst to, move away from performing analysis to seeking the safety of implentation. Hence, alot (most?) of BA's are really implementation coordinators of some sort.

Now adays if BA's perform analysis, it is typically analysis of smaller scale systems. Hence the populatity of small scale analysis techniques such as BPMN and Use Cases (both of which, for example fails to provide any significant provision for decomposition).

Regarding the trends that you mention in you article. To me it is clear that Business Analysis can not move forward until the focus is once again on the essentials of analysis.


Glenn Brule posted on Wednesday, January 11, 2012 9:10 AM

While we might live in different worlds I think fundamentally we are in agreement that there is much learning and development to done by business analysts today, further to that, this can only be accomplished with an inherent understanding, strong support, and a continued investment in time for enterprise wide requirements activities.

I am in total agreement that the drive for firm dates has forced the hand to sacrifice quality, this for me is a reflection of the lack of consideration for quality competency as a result of the lack of understanding of the role, much as you have stated in your opening line of the last comment....

I do appreciate your comments and feedback, thank you.
Tony Markos posted on Wednesday, January 11, 2012 10:51 AM

Thanks for your informative feedback!


Charu posted on Wednesday, January 11, 2012 3:34 PM

Thanks for providing the clarification - I understand what you are saying.

There can be no book or theory teachning how a BA accomplishes this skill of effective decomposition in large scale projects - this purely comes from a basic "common sense" that BA has to have to be a professional BA (well, this is my definition of a BA - without this, a person cannot claim to be a BA, in my opinion!)

Any person to be caled a BA must have had some ability to analyse current scenario / processes and map the future scenario / processes. Without this skill, we do not call a person a BA.

Havign said that the above skill is with a person, and we have called this person a BA, then comes the functional understanding of the "TO BE" scenario / processes.

Again, without this functional understanding and clarity, the whole project does not commence or cannot mvoe towards a solution.

Assuming that we have now started moving towards a solution, decomposition or logical break-down is a basic need without which we cannot proceed with even prioiritisation or plot parallel tasks or even think of the critical path for the project.

While I agree with the needs for such skills, what I am trying to say is, any one who calls himself or herself a BA must have these natural abilities that comes from soem experience + common sense + a natural flair (just like how a novelist has a natural flair with language / vocabularies).

It is actually such skills / abilities that makes a person move towards a BA profession.
Charu posted on Wednesday, January 11, 2012 3:36 PM
And, apologies for missing the spelling (typo) mistakes - again a natural skill a BA should not have missed!
vlad posted on Thursday, January 12, 2012 10:22 AM
I think it is worthwhile to distinguish Business Analysts from Business Systems Analysts. IT Analysts vary in their breadth. Some are more technical, some are less so. Some are very much about the software life cycle, some prefer the big picture. A lot depends on the environment rather than the analyst. A great deal of work done by some business analysts in my organization is project management, research, strategy, methodology, modeling (in addition to requirements, testing, and so on). What's being challenged is not only the BA role but the role of the IT unit as a whole. Let's also not forget that Business Analysts in some organizations have nothing to do with IT at all. So, we should not assume that BA=BA when we ascribe characteristics to them.

The focus on "decomposition of system" feels dated to me personally. As I am not a Business "Systems" Analyst, perhaps it's outside my sphere. I would say the skill in question is, more broadly speaking, organizing information, and it's not limited to systems (broadly or narrowly defined), and includes synthesis to a great degree. Moreover, factors like systems thinking, design thinking, prototyping, service (as opposed to functional) orientation, and BPM are challenging traditional approaches to how systems are described and what the "system" is.

These observations certainly do not reflect a majority of organizations (or even my organization), not yet, but there are promising trends on many fronts. That's where my thinking is heading in any case. Cheers.
LLMABA posted on Thursday, January 12, 2012 2:49 PM
@Tony: I now understand your perspective. if you would like to make suggestions for the next IIBA BABOK review here is their link: Chapter 6 and Chapter 9 address Requirements Analysis and Technicques.

I agree with VMalik a BA is different than a BSA, but I notice lately most companies would like to hire a BA with some system analysis skills. ( I guess to save money).

The "decomposition of a system" can be very complex and quality should not be sacrificed.

Gathering requirements and partiioning a system for NASA or the military obviously requires an engineer or Lead Architect to breakdown or architect the system based upon IEEE method vs. a finance workgroup application which may use IIBA knowledge or the Zachman Framework.

When I am reviewing a large enterprise, the first thing I do is to review what "hardware" or "software" companies they have partnered with and then understand what "process or business initiative" needs to be improved (for example, billing or accounts payable).

For new BA's, all the tools and methodologies can be overwhelming.
LLMABA posted on Thursday, January 12, 2012 2:57 PM
I also apologize for my spelling typo's and grammar. LLMABA.
LLMABA posted on Thursday, January 12, 2012 3:18 PM
@Glenn, it would be great to understand what enterprise architect tools (i.e., Enterprise Architect, or IBM Rational) are being used by various industries.

Thank you for your article. It helps to keep me focused.
Tony Markos posted on Thursday, January 12, 2012 3:34 PM
Comment for Charu:

I must disagree with your statement that there is no therory to conducting decomposition of a system. Data flow diagrams for one are largely all about a formal, logical approach to decomposition.

Decompositon of a not-really-large system can go down 4 to 5 levels. Such requires more than common sense.

Charu posted on Sunday, January 15, 2012 3:50 PM

I think there is a difference between Technical Decomposition and Functional Decomposition.

Functional decomposition depends entirely on the system / industry, business priority and what is deemed as the most important part of the system functionally and a logical breakdown of the solution / system.

Assuming that Agile methodology is used, the high priority business requirements will need to be implemented first.

But to implement the high priority business requirements, of course, the BA will need to work together with the Architects and senior developers in understanding the architecture of the proposed solution, the technical complexities and dependencies.

The approach that is usually taken is to look at how do we implement the high priority business requirement by starting with the necessary dependent technical elements.

What I meant by "BA common sense" is functionally splitting the system into logical parts ..........and this will entirely depend on the functionaliy and the functional components of the system. It does come from a full understanding of the functionality that the BA will need to have after havign gathered the business requirements and taken part in the finalisation of the functional solution.

I have not come across much guidance of how someone functionally breaks the system ...........and this is what I was trying to express.

I totally agree with you on the Technical Decomposition side.
Tony Markos posted on Monday, January 16, 2012 4:15 PM

I focus most heavily on the unchanging (i.e, essential) business requirements. This means I deprioritize the mechanism used to accomplish a function/process. Let's say, to keep things real simple, that it is an essential business requirement to be able to add together two single digit numbers. There are various mechanisms (i.e, means) that could be use to accomplish this task: a J2ee platform base servo modulator, a person, electronic circuits, or Fido the wonder dog (yes a dog can be trained to add together two single digit numbers - I saw it on TV).

My primary job as a BA is to indentity the essential business requirement: Add together two single digit numbers. Now whether the j2ee platform is the mechanism used to accoplish the funcgtion, or Fido the wonder dog, well that is an architect or designer decision.

zarfman posted on Wednesday, February 1, 2012 10:06 PM
Greetings one and all:

How does one decompose a system where the various components of the system are not independent? By this I mean a system where any change in one component effects other components of the system.


Tony Markos posted on Thursday, February 2, 2012 12:46 PM

Are you talking about decomposing a systems analysis or a systems design?

I am a Business Analyst; I decompose the required behavior of businesses, both implemented manually or by automation.

Whenever I hear the word "component", it generally means the discussion is about design. Here all I recommend is the basic principle of structured systems design: Components should be highly cohesive (singular in purpose as much as possible) and loosely coupled (mimization of logical interfaces).

Obviously, if any change affects [all] the other compoents these principles where violated significantly and major redesign is required.


zarfman posted on Friday, February 3, 2012 10:03 PM

Tony et al:

Various contributors have written about business architects and enterprise business analysts. My understanding is these individuals attempt to analyze corporate entities.

Based on my experience corporations in general tend to be made up of management, sales, marketing, finance, accounting, treasury, engineering, production/manufacturing, R & D etc or some variation there of. I would assert that these corporate components as I tend to call them influence one another to varying degrees.

If the financial statements show that the bottom line is falling, how does the analyst figure out what caused the decline? Given these conditions perhaps decomposition has some sort of practical limit. I’ve been in these situations and solving them is not a trivial task.

However, I may wandered into some parallel universe and this is not the type of problem you’re discussing. If so let me know.


Tony Markos posted on Saturday, February 4, 2012 2:41 PM

As I am sure you know, analysis is a big part of problem definition. Key is to know what analysis is. It is very surprising how very few BA's know this. If one looks up the word "analysis" in a dictionary, chances are that the first listed definition will read something like: "Analysis: Partitioninig an entity into its components and examing how the components interrelate".

Business systems are especially hard to partition as they can not be seen nor felt (only the mechanisms used to impelement them can). So business analysis is largely all about partitioning, leading to effective decomposition. To ponder the practical limits of decompostion is to ponder the limits of business analysis.

How far should decomposition (partitioning) go? That can vary. The Yourdon data flow diagramming method recommends decomposition down to a level where one can describe the internal processing logic of processes/functions using a 8 1/2" x 11" piece of paper.

But for Agile projects, that much decompostion is not needed.

Parallel universe? I'm in Cleveland.

Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC