Entries for January 2009


If a single word can represent an entire year, then 2008 was the year of change. Of course, the next American president ran an entire campaign on change, but, more specifically, the business world as we know it will simply never be the same. We’ve all learned that no company—no matter how thoroughly it is woven into the fabric of the economy—is isolated from the need for improved efficiency, due diligence and corporate responsibility.

With change having such a profound influence on 2008, 2009 will likely be shaped by the business world’s ability to adapt to that change. And, of all the groups of professionals working today, few will serve a more important role in that adaptation than business analysts. Requirements management and development, which has for so long been the unsung hero of the successful project lifecycle, is poised to begin receiving the prominence it deserves.

Here are 10 key trends to look forward to in business analysis for 2009. They represent the on-going evolution of requirements management and development and the ever-increasing value of the modern business analyst.


If Agile is to become the next zeitgeist for development, what will become of the traditional Business Analyst?

We all know the traditional waterfall mantra: analyze, design, build then test... underpinned by the common belief that the more you analyze up front the more you save in maintenance later on. This has had a huge impact on the way we organize our teams: separating functions and putting a heavy emphasis on theoretical modeling.

When a project kicks off, the classic Gantt chart dictates that analysts are on-boarded early for a lengthy requirements analysis stage. Once the requirements specification is 'signed off' the analysts are often relieved of their posts for the design crew to take over. The 'sign off' fest continues until eventually the user community is (invariably) force fed a UAT phase and the fledgling product is launched; all the while resources are inhaled and exhaled as the project plan demands. The project then becomes more of a way to co-ordinate a set of individual skill sets and activities.


Business Analysts rely on input from a subject matter expert (SME) to help complete scoping and requirements documents. This simple truth is the reason ModernAnalyst has asked me to share an overview of the Data Management Association Body of Knowledge (DAMA-DMBOK). The purpose of the article is not to teach you data management, but to provide you with a general understanding of building blocks of the practice. It will describe the breadth of subjects that data management professionals may be able to address.

The BABOK includes data modeling in order for a BA to document data requirements; this overlaps with the skills a data management professional needs to do data development. It is an obvious point of collaboration. When we examine all of the facets in data management, you may find other opportunities for leverage.

If you can recognize requirements that indicate impacts to the data environment early in your project, you can draw on other resources more effectively. I have provided some sample ‘red flags’ to illustrate requirements that might benefit from collaboration with a data management professional.

I suggest you develop your own list with the data management professionals at your organization; it will become helpful tool for you to know when to include them.


Does it ever feel like no one really appreciates what you do as an architect? It doesn’t matter what you’re designing, the consensus seems to be that what you do is just a lot of planning and thinking. No one seems to understand how much time and effort you have put into understanding every nook and cranny of the business so that your projects succeed not only from a physical deployment perspective, but from an organizational perspective as well. Essentially, your main role is to lay the foundation for your entire organization to succeed in business. Whether that’s from an enterprise, application, Service-Oriented Architecture (SOA), or other architectural design doesn’t matter. Your role is clearly one of the most pivotal in any organization, yet it's also one of the most misunderstood.

I say “one” of the most misunderstood because there is another worker bee in the hive who performs just as many pivotal yet misinterpreted tasks as you: the business analyst. As you work at defining the organization and deployment structures of your design, business analysts work at defining business problems and opportunities and turning them into solutions for customers. In other words, the business analyst is another key role that’s often misunderstood.

The misunderstandings occur because on the surface, it appears that both of you are attempting to do the same job. You—the architect—are undoubtedly the best person to design a practical solution for business requirements that you’re not particularly close to. At the same time that you are designing a solution, the business analyst—arguably the person much closer to those business requirements—is attempting to design a practical solution for them. Ultimately, you both want the same thing: a solution that works for the business and is cost-effective. The problem is that the two of you are coming at that solution from different angles.

Just imagine the possibilities if you and the business analyst learned how to put those angles together to form the perfect square.

Author: S. E Slack


The U.S. economy is bleeding jobs, but -- at least, so far -- the high-tech industry is something of a safe haven. That's not to say there haven't been tech losses or that it's easy to find an IT job. However, people with the right skill sets and the savvy to sniff out the particular areas of demand are much better positioned than professionals in some of the more-beleaguered industries.


Demand for IT business analysis is also on the rise right now, according to Rubillo, driven by a couple of different factors. Of particular importance in these recessionary times is the need for analysis that can wring out the most efficiency from a software application.

"Companies are increasingly aware of understanding the real world implications of an IT investment," said Rubillo. "A new software application, for instance, can result in bottlenecks in the supply chain, or a need for new resources -- or the ability to cut back on others. Companies want to get ahead of these developments as they implement their new IT investments."

Companies are also looking for untapped savings from pre-existing systems, he added.

Author: Erika Morphy


Billions of dollars earmarked for new technologies, at the same time billion-dollar projects are failing. Virtual teams who can’t implement Virtualization. Service Oriented Architecture when customers are no longer oriented towards your services.

Where can you turn to? Who can you trust?

Enterprise Business Analysis is the solution

EBA is Strategic, Process and Organizational Consulting:
o Strategic – Planning and execution.
o Process – the steps.
o Organizational – the whole enchilada.
o Consulting - Internal or external, the combination of expertise and intuition, Techne and Poesis, improvisation and practice in planning and supporting the enchilada’s goals.

You are already familiar with EBA, under its many masks for the diagnosis of the patient, and prescription for the cure:

  • Best Practices
  • Change Management
  • Coaching/Mentoring
  • Process and Operational Improvement
  • Strategy Development
  • Technology analysis, recommendations and implementation

Author: Sam Cherubin



Copyright 2006-2021 by Modern Analyst Media LLC