An insight into Business Analysis

1. 7
An Insight into Business Analysis
By Kailashnath Reddy Kavalakuntla
A study of the way the role of a BA has evolved helps
to better understand the way it defines itself now
Business analysis techniques are powerful
methods for redesigning and revitalizing
business processes as well as specifying systems
solutions for technical staffs. However, these
interlocking techniques must be well understood
and applied if business benefits are to be
achieved. Working with clients and system users
is often a complex assignment that requires the
analyst to understand the physical and logical
business processes which comprise an enterprise
system. Then the analyst must conceptualize a
new solution that is accurate, pragmatic and
implementable.
Business analysis is about drafting what
the solution is expected to do while a design is
about how we make use of the technology in
achieving it. Business analysis gives a logical
view of process and data needs and is not bound
by the physical implementation. When business
needs change they require a restructuring of
the requirement plan but the change is not
much directly proportional to the change in
technology.
Technical personnel evince interest in
changing their design views with the upcoming
technologies whereas the business user is more
concerned about the product deadlines and
the final operational system. Business analysis
neatly bridges this gap between the IT analysts
and the business analysts (BA).
Very often the pressures of deadlines
and budget leads one to bypass the important
process of analyzing the business needs and
we jump straight into the technological needs
without realizing whether the system meets the
business requirements.
WHY ANALYZE BUSINESS?
In the early days of software development the
products were designed by technical analysts and
computing specialists who were focused more on
the product than the business they were working
on. This led to excessive focus on technology
than on business which resulted in business
backdrops like lack of focus on business needs
and deliverables. For confronting such problems
the Software Development Life cycle (SDLC)
came into implementation so that all the business
requirements and deliverables are focused at
almost every phase of the product life cycle.
The development life cycle’s basic
building blocks are:
SETLabs Briefings
VOL 6 NO 4
2008

2. 8
■ Gather
■ Analyze
■ Model
■ Define business system requirements
■ Improve business processes
■ Manage changing business requirement.
Every block of the life cycle is a crucial
aspect when considering the development of
final operational system. Many surveys have
shown consistently that the increase in cost of
repairing errors increases exponentially the
later a repair takes place in the SDLC. An error
which costs a dollar to repair during the Initiate
phase will cost $10 to fix if it is left until Analysis,
$100 at Design and $1000 if nothing is done until
Implementation.
CHARTING HISTORICITY OF THE BA’S
ROLE
In the 1980s when the SDLC was well accepted
as a necessary step, people doing this work
typically came from a technical background
and were working in the IT organization. They
understood the software development process
and often had programming experience. They
used textual requirements along with ANSI
flowcharts, dataflow diagrams, database
diagrams and prototypes. The biggest complaint
about software development was the length
of time required to develop a system that did
not always meet the business needs. Business
people had become accustomed to sophisticated
software and wanted it better and faster.
In response to the demand for speed,
a class of development tools referred to as
Computer Aided Software Engineering (CASE)
was invented. These tools were designed to
capture requirements and used to manage
a software development project from the
beginning to end. They required a strict
adherence to a methodology, involved a long
learning curve and often alienated the business
community from the development process due
to the unfamiliar symbols used in the diagrams.
As IT teams struggled to learn to use
CASE tools, personal computers began to
appear in large numbers on desktops around
the organization. Suddenly anyone could be a
computer programmer, designer and user. IT
teams were still perfecting their management of a
central mainframe computer and then suddenly
had hundreds of independent computers to
manage. Client-server technologies emerged as
an advanced alternative to the traditional green
screen keyboard-based software.
The impact on the software development
process was devastating. Methodologies and
classic approaches to development had to be
revised to support the new distributed systems
technology and the increased sophistication
of the computer user prompted the number of
software requests to skyrocket.
In the 1980s the sudden surge of personal computers and the
need for numerous business applications made the software
development process go haywire

3. 9
Many business areas got tired of waiting
for a large, slow moving IT department to roll
out yet another cumbersome application. They
began to learn to do things on their own, or
hired consultants, often called BAs, who would
report directly to them, to help with automation
needs. This caused even more problems for IT
which was suddenly asked to support software
that they had not written or approved. Small
independent databases were created everywhere
with inconsistent and often, unprotected data.
During this time, the internal BA role was
minimized and as a result many systems did
not solve the right business problem causing an
increase in maintenance expenses and rework.
New methodologies and approaches
were developed to respond to the changes.
Rapid Application Development (RAD),
Joint Application Development (JAD) and
Object Oriented (OO) tools and methods were
developed for the purpose.
As the new millennium began, internet
emerged as the new technology and IT again
faced a tremendous change. Once again, more
sophisticated users, anxious to take advantage of
new technology, often looked outside their own
organizations for the automation they craved.
The business side of the organization started
driving technology as never before and a large
percentage of organizations began staffing the
BAs from the operational units instead of IT.
Consequently, we now have marketing directors,
accountants, attorneys and payroll clerks
performing the role of the business analyst.
In addition, the quality movement that
had started in the 70s with TQM came into
focus again as companies looked for ways to
lower their cost of missed requirements as they
expanded globally. The International Standards
Organization (ISO) set quality standards that
neededtobeadheredtowhendoinginternational
business. Carnegie Mellon created a software
development quality standard — Capability
Maturity Model (CMM). Additionally, Six
Sigma provided a disciplined, data-driven
quality approach to process improvement aimed
at the near elimination of defects from every
product, process and transaction. Each of these
quality efforts required more facts and rigor
during requirements gathering and analysis
that highlighted the need for more skilled BAs
familiar with the business, IT and quality best
practices.
At a purely functional level, the BA’s
skills were process modeling, requirements
gathering and requirements specification. But
with change in time the role of a BA has changed
and is no longer limited to only modeling and
specifications handling. While IT analysts are
playing a pivotal role in the life of any business,
the BA profession is in relative infancy. What
is expected of today’s analyst varies from
As business increasingly started driving technology,
people from different backgrounds donned the cap of
business analysts

4. 10
organization to organization and from project
to project. That makes it neither possible nor
practical to come up with a definitive list of
competencies.
The quest for competencies should begin
with identifying the various roles that analysts
fulfill and the tasks the analysts are expected to
perform. However, because the BA has a highly
visible role in the project, the expectations from
clients, colleagues and the organization are often
much higher and extend through the life of the
project. A BA’s presence is seen from the project
initiation phase to the implementation phase.
A BA’s role becomes more critical as
project teams become more geographically
dispersed. In recent times outsourcing and
globalization of large corporations have been
the driving factors for much of this change.
When the IT development role no longer
resides inside our organizations, it becomes
necessary to accurately and completely define
the requirements in more detail than ever
before. A consistent structured approach, while
nice to have in the past, is a requirement today
to be successful in the new environment. Most
organizations will maintain the BA role as an
‘in-house’ function. As a result, more IT staff is
being trained as BAs.
The BAs role will continue to evolve
as business dictates. Future productivity
increases will be achieved through re-usability
of requirements. Requirements management
will become another key skill in the expanding
role of BA as organizations mature in their
understanding of this critical expertise. The
BA is often described as an ‘Agent of Change.’
Having a detailed understanding of the
organization’s key initiatives, a BA can lead
the way to influence people to adapt to major
changes that benefit the organization and its
business goals.
FINDING SOLUTION FOR BUSINESS
PROBLEM
It’s not all about temporary solution to the
problem but about analyzing the problem and
providing an appropriate solution as it is meant
to address the issues of resource and deadline
management. One should not freeze the solution
but move to further changes with time and
situation. The solution should be short and
simple and should be applicable in majority of
conditions. Sticking to an approach that proved
successful for a project need not prove the same
with the other, it is always like a gold refinement
process and the more quality the customer
demands the more refinement one’s processes
need to follow.
CONCLUSION
Today we operate in an environment more
complex than time has ever witnessed. We need
the long-term view, a permanent fix and an
adaptive design that is fully integrated. It is up
to us to provide a business effective solution so
as to keep in control of the business or let loose
the enterprise so that the unpredictable events
of the business play around with us. Business
analysis is a disciplined and perfectly engineered
approach for the present trends in the enterprise
business. The more effective are the business
decisions taken the tastier are its fruits.
REFERENCES
1. Ralph Whittle and Conrad B Myrick,
Enterprise Business Architecture: The
Formal Link between Strategy and
Results, CRC Press, Florida, 2005
2. The Executive Guide to Business Analyst
and Project Management Terminology,
2007. Available at http://images.
globalknowledge.com/wwwimages/
whitepaperpdf/WP_ExecutiveGuide_

5. 11
BAPMTerms.pdf
3. WhatisaBusinessAnalyst?IRMTraining,
2005. Available on www.whitepapers.
techrepublic.com
4. Brian Cooney, Separating Analysis
from Design. Also available at http://
www.modernanalyst.com/Resources/
Articles/tabid/115/articleType/
ArticleView/articleId/65/Separating-
Analysis-from-Design.aspx
5. ArcViewBusinessAnalyst,Environmental
Systems Research Institute, Inc., 1998.
Available at http://www.edgetech-us.
com/Pdf/avbadata.pdf
6. Barbara A Carkenord, The Emerging
Role of the Business Analyst. Available
at http://www.businessperform.com/
articles/business_analyst_role.html.