Business Analysis Articles

Jan 23, 2023
It’s no longer rare to see machine learning (ML) models used to support a variety of business decisions, from whether a financial transaction should be sent to the fraud investigation team, to what discount a distributor should get. Still, even in organizations that have embraced ML-based s...
It’s no longer rare to see machine learning (ML) models used to support a variety of business decisions, from whether a financial transaction should be sent to the fraud inve...
Data is crucial in making sound business decisions, and business owners can acquire this much-needed data through business analysis. For example, Microsoft’s data analytic...
As a Business Analyst we might need to work on Projects related to multiple industries and domains during our career. It is critical that we try to leverage our past knowledge and ...

Latest Articles


As budgets tighten and organizations continue trying to achieve return on investment faster, cheaper and with better results, they are trying to create and evolve their overall enterprise architecture.


There appears to be a gross misunderstanding about Architecture, particularly in the information technology community. Many people seem to think that an implementation, an end result, is Architecture. To use an Architecture and Construction example, many people think that the Roman Coliseum is Architecture.

The Roman Coliseum is NOT Architecture. The Roman Coliseum is the RESULT of Architecture. The RESULT of Architecture is an instance of Architecture, an implementation. In the end result, the implementation, you can see an instantiation of the Architect’s Architecture. If an Architect had not created the descriptive representations (the Architecture) of the Roman Coliseum, they could not have built the Roman Coliseum. They couldn’t have even ordered the stones they required in order to build the Coliseum without the Coliseum Architecture which had to be created long before the Coliseum was constructed.

Architecture is the set of descriptive representations that are required in order to create an object. If you can’t describe it, you can’t create it. Also, if you ever want to change the object you created, Architecture constitutes the baseline for changing the object once it is created, that is, it is the baseline for changing the object IF you retain the descriptive representations used in its creation and IF you ensure that the descriptive representations are always maintained consistent with the instantiation.

If the object you are trying to create is so simple that you can see it in its entirety at a glance and remember how all of its components fit together at excruciating level of detail all at one time, you don’t need Architecture. You can "wing it" and see if it works. It is only when the object you are trying to create is complex to the extent that you can’t see and remember all the details of the implementation at once, and only when you want to accommodate on-going change to the instantiated object, that Architecture is IMPERATIVE. Once again, without Architecture, you are not going to be able to create an object of any complexity and you won’t be able to change it (that is, change it in minimum time, with minimum disruption and minimum cost).


So, the question is, what constitutes the set of descriptive representations relevant for describing an object such that you can create it and change it with minimum time, disruption and cost?

Author: John A. Zachman


Two years ago, some of my friends pressed me intensely to be more definitive about the Framework concepts. Even though, I had written “The Book”, they were specifically asking me for definitions of the entities that comprise the metamodel of Row 2 of the Enterprise Framework. It has taken me and a team of dedicated folks two years, however we have progressed far beyond the original requirement.

We have produced descriptions, not only of the entities of Row 2 of the Enterprise Framework, but also we have definitions of the entities of Row 1, Row 2, Row 3, Row 4, Row 5 and Row 6 of the Enterprise Framework plus descriptions for the Product Framework (where I learned about the Framework classification in the first place), for the Profession Framework (that I used to call the I/S Framework, the “meta Framework” relative to the Enterprise Framework) and for the Zachman Classification Framework (the Framework classification for all Frameworks).

This work is particularly significant at this point in time for several reasons.

Author: John A. Zachman


In recent years it has become more and more apparent that the job description of Business Analyst has become diluted and distorted. Can this be considered the natural evolution of a profession or is it a profession that no longer has a clear job description? Is this a profession that has moved past the point of clear boundaries or are the boundaries still there but blurred based on the need to adapt to a changing world to meet the needs of people rather than the needs of the business? What can we do to win back the respect that the Business Analyst profession deserves? Exactly whose responsibility is it to maintain a professional and respected image of this profession? Should the recruitment process of Business Analysts be an exercise in requirements gathering?


If it is allocating your internal resources, making a new hire, or bringing in a consultant; what is the best process to match the right business analyst to the right project? For organizations that truly value the role of the business analyst this is one of the most frequently pondered questions.

Companies that want to have the right people in the right roles need to address four main stages; defining the BA’s roles in the project, attracting the best talent, matching the BA to the project and finally, making the selection and continuing to support.


In previous articles, I discussed ways in which business analysts can become organizational consultants, driving innovation, problem solving and strategic solutions within their companies.

In addition to the traditional tools of project business analysis and the emerging tools of enterprise business analysis, another toolkit can be exceptionally helpful.

This is the rich group of practices from the Quality and Process Improvement methodologies, including Six Sigma, Lean, Theory of Constraints (TOC) and Systems Thinking.

Although these methodologies are used in many organizations, their tools have not yet been widely incorporated into either project or enterprise business analysis.

In this article, I will focus on combining a Voice of the Customer (VOC) with the “Ends Planning” exercise from Idealized Design.

Author: Sam Cherubin


Lean processes—whether you’re building bicycles, assembling TV dinners, or developing software—are all about value. Activities like rework, reprocessing, reformatting, storage, handling, and sign-offs are not valuable. In lean terminology, they’re waste.


Business isn’t going to walk hand in hand with IT until we’re ready to truly partner with them. Here’s how.

I’ve had some interesting conversations about the role of business analysts and the best practices most of them use for requirements-gathering. And I’ve noticed a major contradiction between our desire to be effective partners with the business and the way we go about gathering system requirements.

The contradiction is this: current best practices lead us to gather requirements for a new system by using procedures that, right from the start, cause tension and adversarial interactions between IT and business people.

Author: Mike Hugos


When I’m not consulting or managing projects, some of my time is spent teaching MBA classes at Drake University.  The fact that I teach both project management AND creativity for business creates consternation among some of my friends and colleagues.  After all, can a project manager really be creative?  Aren’t those mutually exclusive skills?

My response is a great project manager also must excel at creativity to remain a viable, valuable asset in today’s marketplace.  Gone are the days of simply managing scope within a budget and schedule; project managers must be multi-faceted utility players.  Project and program managers are being expected to create solutions, to facilitate conflicts, and to motivate resources toward a goal in ways never before anticipated.


Business analysts are at the sharp end of one of the great challenges of information technology – how to build the systems organizations need. At the same time, organizations are demanding more sophisticated systems – the “dumb” systems of yesteryear are no longer enough.


Business-process-modeling technology provides a powerful set of tools for describing and automating processes. The technology is so powerful that it often seems there are no limits to what BPM can do. But not every process that is automated needs BPM. Following on last week's discussion of process discovery, the JargonSpy asks the question: What sort of processes should be automated using BPM?

Businesspeople and technologists alike quickly get drunk on business-process modeling when they first become competent in the technique. Like wikis, business-process modeling allows you to capture the detail that you have in your head and then leave placeholders for what is not yet baked. In wikis, this takes the form of pages of text that link to other pages covering concepts that you will fill in later. Wikipedia is full of links to pages waiting to be completed.

The analogous act in business-process modeling is to put a box in to cover a step ("solve the halting problem" or "find qualified leads") that is part of the process but that you don't want to worry about just then.

Author: Dan Woods


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

Page 64 of 67First   Previous   58  59  60  61  62  63  [64]  65  66  67  Next   Last   



Copyright 2006-2023 by Modern Analyst Media LLC