Computers are useless: they can only give you answers. Questions are what matter. –Pablo Picasso
While computers obviously aren’t “useless,” Picasso’s point is a good one: knowing the right questions to ask can often turn out to be of more importance than knowing the answers. This post is interested in the effect that better technical questions can have on driving better technology integration results.
The Building Business Continuity (BBC) Conference
This past week, I was lucky enough to attend the business-analyst focused Building Business Continuity Conference in Las Vegas, Nevada. The BBC conference focuses on building business analytic skills and discussing the technology of business analysis. I attended on behalf of InRule with a focus on deepening my understanding of why gaps exist between business analysis and the technical implementation of that analysis. I came away with some interesting insights.
Most Business Analysts are Not Coders
Business analysts are responsible for identifying and documenting business processes. Often times the business processes they’re documenting have little or no direct connection to specific technology. And for a variety of reasons, it is often helpful for BAs in those scenarios to document processes in terms that are technology agnostic (using flow charts, decision management notation, Visio diagrams, user stories, spreadsheet-based decision tables, and more).
But there are an ever-increasing number of scenarios in which business requirements DO ultimately end up being translated into functional software (a.k.a. “code”). In those scenarios, BAs can make a critical impact (i.e. shorten expensive solution design efforts) if they have a deeper understanding of the implications of technology on their efforts.
Easing the Transition from Business Analysis to Solution Design
I don’t have a lot of “software developer” in my background. But my job at InRule involves a lot of translating business requirements into technical system requirements, what we refer to as “rule harvesting.” Technical rule harvesting can be frustrating, time consuming, and fraught with enough risk and unknowns to make project managers pull their hair out. So I’d like to offer some help for BAs.
I’ve identified several critical technical skills that I’ve learned about system design that should be of help to non-technical BAs. I cannot fully do justice to the techniques I’ll describe below, but perhaps future blog posts can help to elaborate on them.
Helpful Questions to Ask
It’s important for any BA on a technical project to understand not only where the organization is in the Systems / Software Development Life Cycle (SDLC), but also the implications of each stage. If you are a BA and are intimidated by the SDLC, then asking the right questions of your project manager and your technical team can help to sharpen your focus on to the things that matter.
Data Overview Questions
- For all business processes that you’re documenting that will result in computers taking action:
- What are the inputs to this process?
- What are the outputs of that process?
- Can you map the inputs and outputs to a specific data model?
- For decisions which will be made, where will those decisions be stored? What is the current system of record?
- Will a database hold important data?
- If so, does that database limit or expand what can be done?
- If not a database, where will the decision output go?
Working with the System
- What user interface will be used to interact with these processes?
- Is this interface being developed in tandem with your project, or is it an existing (i.e. legacy) system that is being modified to accommodate your new processes?
- Can you be provided with wireframe documents or actual screen shots of this software to help you understand how the processes will be implemented?
- Can you start to identify where key business processes will likely interact with that data model?
- Can you identify where specific software logic will need to be called in order to make decisions?
- If there was a previous system, how did that system work?
- How did the previous system map to the previous business requirements?
- Why is the system changing?
Implementing Rules
- What role are you expected to have when it comes time to implement rules?
- Will you be writing them in InRule, or will a developer be coding them (in InRule or another technology)?
- Will the system of record change as a part of this project?
- In a typical development environment, there will be at least a development and a test environment. Will you be working in the development environment?
- Some higher-level business requirements don’t translate directly to code or to rules. For those requirements:
- How will your business process documents be used to guide the technical development process?
- Can you identify the lower-level (i.e. more detailed) technical implications for each of your higher-level processes?
- Does the technology chosen to implement these requirements force changes to your requirements?
There’s certainly quite a bit more to discuss on this topic, but hopefully these questions give business analysts a head start on being able to better interface with the developers they’re working with when it comes time to implementing their business requirements in technology.
Feel free to drop me a line with feedback.
