Interview with Brad Botz on Business Analysts
I recently met Brad Botz in a professional Facebook group we both belong to and found we have much in common. I really like databases and development, and Brad likes to read users’ minds. Well not really, but see Brad is a Business Analyst and his job is to eek user requirements out of users.
I’ve been there, it can be really challenging work. In a way its like being a politician. Everyone knows whats wrong, but no one knows how to fix it!
No matter whether you’re a developer or DBA looking for a better way to work with customers or users, or an aspiring business analyst looking to expand your skills, I think you’ll enjoy this interview.
Brad has extensive experience and his answers are very insightful.
What database advice would you give to those that want to start a career as a business analyst? For instance, is there any particular software to learn first?
For those just starting, or looking into, a career as a business analyst, it is important to understand the basics. Specifically, it’s important to be able to create an Entity Relationship Diagram (ERD). The ERD is one of the ways a business analyst can ‘speak the language’ of the developer by translating the business data needs into a format the developer can easily work with.
I’ve found that the ERD is a good way to get the dialog between BA and developer flowing, and development/database staff seem to appreciate the effort. There are three main types of ERDs: Conceptual, Logical and Physical.
Those starting out as a BA should master the Conceptual ERD (also known as a Conceptual Data Model). The Conceptual ERD describes the business ‘entities’ and the relationships between them at a high level and without the granular detail of a Logical or Physical ERD. A basic tutorial and free online tool can be found at http://creately.com/blog/diagrams/er-diagrams-tutorial/.
Since Conceptual ERDs use very basic shapes, beginning BAs can use Visio or other basic diagramming software that they may be using at their place of work. There are also many online diagramming toolssuch as lucidchart.com.
My personal favorite diagramming tool, although not free and with a longer learning curve, is Enterprise Architect. Enterprise Architect, in my opinion, is the most full featured, affordable, diagramming tool on the market.
What were some of the most frustrating aspects of SQL you had to learn? How do you overcome them?
I have never been, and would never call myself, a SQL expert by any stretch of the imagination. Like learning any language, you need to be able to practice SQL to get a really good grasp of the basics. I’ve been through any number of 2 or 3 day courses at companies I’ve worked for, only to get back to my desk and have nothing to practice on.
It’s frustrating to feel like you are getting a good handle on SQL only to let the knowledge slip away through lack of use. The only way to combat this frustration is to find simple projects to continue utilizing your SQL knowledge.
My recommendation for beginning BAs is to ask for some simple projects to keep your SQL skills fresh. You can explain it to your supervisor or management as cost savings. It is much cheaper to have you work on some small projects rather than completely retrain you at a later date.
Much like algebra or calculus, if you are not continuously using it for a length of time, you will forget it. This seems to be a consistent experience for business analysts like myself, as well as those I have worked with and trained.
Business Intelligence is a hot topic nowadays. Do you feel it is merely a buzzword put on top of traditional analyst work, or are there big changes being made in how analysts do their work?
There is definitely buzz around Business Intelligence, but I don’t feel it’s just a buzzword. Business Intelligence occupies that spot between the business side and technology side that is currently difficult to fill with a traditional business analyst. There are a couple reasons why I think it’s hard to find a business analyst to fill a BI role.
The first reason is that traditional business analysts are often former Subject Matter Experts (SMEs) with a lack of the deeper technical knowledge needed for BI. In addition, many companies still use the BA as a note-taker or scribe. It’s certainly not that these folks are not capable, but companies often won’t take the risk to train them up to the level needed to tackle a BI role.
The second reason is that those BAs that do a lot of data work, like report creation or financial analysis, often don’t have the experience on the business side. It takes a good understanding of the overall business to be able to know what data might be beneficial from a BI standpoint.
BI requires a skill set that is not very common, and it shows in the, relatively, high wages and difficulty in finding employees. This is why BI hasn’t really changed the way BAs are working overall.
What database skills really help you get an edge on putting together the best use cases or business requirements for your customers?
In my experience, understanding how data in a relational database is structured can be invaluable in putting together use cases or requirements. Going back to the ERD mentioned earlier, the ability to visualize the way data flows through the organization can make it much easier to create use cases and validate requirements.
In addition, being able to perform basic SQL queries, can help a BA identify additional functionality or identify unnecessary functionality. Duplicate data or lots of null values point out areas that need to be analyzed.
Duplicate data may indicate a UI (user interface) area that is redundant and, perhaps frustrating to the user, as well as potential data structure problems. Null values can point to additional problems in the UI that users are skipping or the application is not collecting affectively. Simple SQL queries can point these problems out, and allow the BA to change/update use cases and requirements.
I’m sure it can be frustrating at time to get requirements and details out of your customers. When digging into an issue, what techniques do you use to get people to think hard about the issue at hand and help you come up with detailed and meaningful information to help you piece together a new business solution?
This is a great question, and from my point of view, the crux of the business analyst’s job. The technique I use most frequently is to rephrase the same question several times to see if the answers change. If they do, the business analyst should be able to identify the new information and direct the conversation accordingly.
If the answers don’t change, it is likely that the customer has no more knowledge on this topic. It doesn’t mean that there isn’t more info, just that this particular person has no more to offer.
Another technique I use is borrowed from creating use cases. I often start by asking about their CRUD – or the data they Create, Read, Update or Delete. This type of questioning really gets the customer thinking about data, and for the most part, they like talking about the things they do in their job.
This technique can bring out some really interesting constraints on the new solution. For instance, in government solutions, there are times when data is not deleted for extended periods of time, or never.
Finally, I’ve found that diagramming is the single most effective technique that is useful to business side and developers. Some diagrams, like ERDs, use case diagrams and activity diagrams are easily understood by both. The ability to create a single type of diagram for both customer and developer is extremely useful and keeps everyone on the same page.
Brad has been doing business analysis for nearly 15 years. He has worked as both an employee and contractor in 11 different industries.
As a “big picture” guy, Brad enjoys Enterprise Analysis and finding the best solution for the problem at hand. He is the creator of the Business Analyst Academy http://businessanalystacademy.com and contributor to ModernAnalyst.com