Business Analyst vs Business Systems Analyst, part 2

In my previous post, I referred to an article by Vongsavanh and Campbell discussing the differences between Business Analysts and Systems Analysts, and I stated that Business Systems Analysts (BSA's) possessed both sets of skills.  In this post, I want to look at the specific skills required by each type of analyst.

Vongsavanh and Campbell's research produced the following list of skills for business and systems analysts:

• Elicitation
• Presentation
• Leadership
• Communication
• Business Knowledge
• Creative Thinking
• Problem Solving
• Technical

The top of the list represents those skills most common to business analysts, and the bottom those skills most common to systems analysts.  There is no explanation for how they arrived at this particular list or how they determined the ordering.  In the diagram in their article, Communication is shown as the skill closest to the middle.

The first thing that appears strange in the ordering of these skills is that Business Knowledge is on the Systems end of the scale.  While some of these skills could be debated exactly where they should fit on the list, Business Knowledge should clearly be shown in the realm of Business Analysts.  Systems Analysts need to understand the systems, and Business Analysts need at least a general familiarity with the business functions.

Since Presentation is separate from Communication, it appears the authors intended Communication to mean documentation or one-on-one verbal communication.  That is a strength required by both Business and Systems Analysts, but Presentation would be more important for the Business Analysts.  The order looks appropriate, but any analysts who are only mediocre in their documentation skills will never excel in their jobs.

Data analysis is missing from the skills list, but it probably fits under Technical or Problem Solving.  From my experience, when the business and technical experts disagree on some detail, it is the analyst's job to find some relevant facts to clarify and focus the discussion, and data analysis is a means to discover those facts.  "One accurate measurement is worth a thousand expert opinions."  -- Admiral Grace Hopper (1906-1992)

Research ability is another skill missing from the list.  If the organization is mature and system documentation exists, it is the analyst's responsibility to understand whatever relevant information is contained in that documentation.  If little documentation exists, then data analysis will have to compensate for that gap.  Sometimes the documentation is out-of-date, so it must be validated with data analysis.  Research and data analysis go hand in hand.

Leadership is helpful in any role, but leadership implies some people skills that often come in handy when working with the business staff, so I agree with placing that on the Business half of the scale.

I cannot guess the difference between Creative Thinking and Problem Solving.  Both have to do with Solution Design, but if you have no creativity, you will solve very few problems.  I would consider those skills as one.

My revised list of skills is diagrammed below.  

Of course, one of the essential skills not mentioned is flexibility.  Every client and project is different, and analysts need to be able to adapt and respond to the unique needs of the situation at hand.  That just means that it should be easy to find a situation that doesn't fit the skills list above.

Such is life for a BSA!

Business Analyst vs Business Systems Analyst, part 1

I market myself as a Business Systems Analyst (BSA).  I think it's the best description of my skill set and the work I typically do with my clients.  The only problem is that Business Systems Analyst doesn't mean the same thing to everyone.

I have always understood a BSA to be a combination of a Business Analyst (BA) and a Systems Analyst (SA).  I bring both skill sets to a project in one convenient package.  The advantage to the client is they get a flexible resource that can wear either hat over the course of a project, and can avoid extra hand-offs between the BA and SA tasks.  The advantage to me is that I should be able to charge a slight premium rate over a pure BA or SA -- at least in theory!

However, there are some who use the term BSA to identify a specialized type of SA who specializes in Business Systems, as opposed to manufacturing systems for example.  There are others who just use BSA as a synonym for BA, arguing all good BA's must have some systems knowledge as a basic requirement.

My experience shows that BA and SA roles are distinct but related, and fortunately a couple people who are smarter than me agree.  Australians Alan Vongsavanh and Bruce Campbell published an insightful article in 2008 entitled "The Roles and Skill Sets of Systems vs Business Analysts."  Their research shows the two roles have overlapping skills, and they present them along a spectrum.

My simplified version of their skill spectrum is that the BA has strong skills on the business side of the spectrum, and decreases in strength as you move towards the systems side of the spectrum.  The SA is strong on the systems skills and decreases in strength as you progress towards the business skills.  Both have some skills on each end of the spectrum, but their strength lies on one end only.

By extrapolation then, Business Systems Analysts should be strong across the entire spectrum.

In the next part, I want to look at the specific skills that lie along that spectrum.

No Such Things As Data Rules?

I found an interesting blog entry by John Owens titled There Are No Such Things As Data Rules.  I find John's articles compelling and much of his material I agree with, but not quite all of it.  This article of his is in the second category for me.

I think I know where John is coming from in his approach to this subject.   Data quality analysts who spend all of their time with their heads buried in the data making decisions on what records are "right" or "wrong" are not what data quality improvement is about.  This approach can create as many new data problems as it resolves.  However, I don't believe we solve this problem by going to the other extreme and assert that simply looking at the data for problems accomplishes nothing.

I want to focus on a few of John's specific points, some of which are found in his follow-up comments after his initial article:

a.   "There are no data rules …. [There are] business function rules."

      "The only reason any attribute would have rules ... would be to support a known, documented business function."

In order for these statements to be true, every last data rule would have to be documented as part of each business function that uses it.  For instance, every business function that required an email address would have to restate that all email addresses must have one and only one "@" symbol somewhere in the middle.  Why would any business want to duplicate that definition all over its business functional documents?  What value does it create?

Further, there is no business need that requires email addresses to have one and only one "@" symbol.  The business requirement might be to communicate with a client quickly and electronically, and nothing more.  The fact that the chosen solution to meet that need is email does not introduce a new business rule.   It introduces a technical rule specific to that solution, namely that email standards must be followed in order to complete a successful email communication.  If a different technical solution is chosen (such as SMS text messaging via wireless phones), the technical standards would change accordingly, but the business requirements and rules would not change.

Shared technical standards are best documented and evaluated centrally, and calling them "data rules" may not be the best name, but it's certainly more accurate than calling them business functional rules.

b.   "If you want to understand the data, you must understand the business functions."  
"Data only has meaning ... when viewed in the context of supporting the business functions of the enterprise."

      "Data can only be said to be erroneous if it fails to meet the needs of the business function(s) that utilise it."

These statements are partially true.  There are certain data questions that require business context in order to arrive at the right answers.  For example, one can never answer the question, "Is this data precise enough?" without putting it into a business context.  However, not all data questions require business context.  Meaning can sometimes actually exist in the data alone.  More importantly, meaninglessness can sometimes be determined from the data alone.

For example, postal codes are a mandatory part of any Canadian mailing address, such as K1A 0A6 (the Prime Minister's office in Ottawa).  The business purpose for capturing a customer's postal code may be to send the customer's bill to them by mail, or it may be to assign the customer to a geographical location for a mapping analysis to set regional boundaries for salespeople.  For the first purpose, all 6 digits of the postal code are required or the bill doesn't arrive at the address.  For the second purpose, the sales department only uses the first 3 digits of the postal code (called the Forward Sortation Area) which provides sufficient location accuracy for assigning sales region boundaries.  Therefore, a partial entry of K1A in the Customer Postal Code field would be insufficient precision for mailing purposes, but sufficient precision for assigning regional sales boundaries.  Answering the precision question requires business context.

However, because Canada Post has defined that no postal codes shall begin with the letters I, O, or D (to avoid confusion with the numbers 1 and 0), we can be sure any entry in the Customer Postal Code field beginning with I or O or D is meaningless, regardless of the business purpose.  Answering the validity question sometimes requires no knowledge of the business purpose whatsoever.

c.   "If a business function requires [data] to be collected ..., then it must enforce all applicable data rules at the point of creation."

I wish this could be true in the real world, but it in many situations it simply cannot be implemented successfully. 

Implementing it technically is easy -- design your system to force the sales person to enter a valid customer postal code before moving to the next screen.  However, if the customer who is standing with the sales person recently moved and hasn't memorized his new postal code, does that mean you should prevent that sale from occurring?  Is a valid postal code more important to the company than a sale?  Probably not, so the employee will enter a fake (but valid!) postal code just to get to the next screen and complete the sale.  It doesn't take long for frustrated employees to realize that Santa Claus has a completely valid postal code -- H0H 0H0.  Suddenly a lot of the company's customers seem to be living at the North Pole!  Therefore, an enforced business rule at the point of capture may improve the validity of postal code data, but it does not guarantee improved quality of the postal code information.  It may instead just frustrate both employees and customers.

The situation is a bit riskier if your organization is a hospital, and the postal code being captured is the patient's at the point of admission in an Emergency Room.  Do you really want to prevent a patient from being taken off the ambulance because he is unconscious and can't tell you his postal code?  If the registration clerk cannot leave the patient postal code blank in the registration system, then you can be sure a fake one will be entered so the intake process is not delayed.  The hospital's postal code is both valid and familiar to the registration clerks, so a lot of patients will appear to live at the hospital.  Oh, and Santa has lots of ER admissions too!

Given the complexity of technical data standards that have no direct relation to the business processes that use the data, and given the challenge of preventing erroneous data at the point of capture, data rules can play a helpful role in managing an organization's information assets.