There are so many questions swirling around the mind of a freshly minted Business Analyst:
- What’s the purpose of a use case?
- When should I do a process map vs. a workflow map?
- How do I model the business data?
These were just a few of the question I grappled with when I first started my BA career.
I tried very hard to sort through all of the BA related advice that was available on the web. But it was 2005, the IIBA had just been founded, Google wasn’t as good as it is today, and there was a glut of conflicting BA advice on the web.
The IIBA has come a long way since, Google has gotten much better, but there is still a glut of conflicting BA advice on the web.
The Solution Stack Framework
It took me about 7 years to build a modeling framework that worked for me in the real world. Once constructred, this framework helped get passed all the confusion that I had faced. Now I use this framework to produce consisten results for my clients through my BA consulting business . This framework greatly reduced the number of decisions I have to make during analysis, and it helped me build requirements documents that were incredibly useful to both the business and the dev team.
I’m going to share this framework with you here, but first, let’s understand the purpose of a “framework”.
What Is a Framework?
Simply put, a framework is a set of related theoretical concepts that help to guide your actions when you’re solving some real world challenge.
Brain surgeons use frameworks to help them understand the structure of the brain, so they can quickly decide where and how to cut during surgery. Building architects use frameworks to help them understand the basic forces affecting building structure, so they can decide how to design a building that won’t collapse under the weight of the forces that are involved.
Business Analysts also have frameworks to help guide their actions. The Solution Stack Framework will help you decide what questions you should address, and what modeling tools you should use when you’re helping your company design a new solution.
5 Levels of the Solution Stack
This Framework divides solution modeling into 5 levels. This helps you separate the concerns you should focus on at different times for different types of projects.
The 5 Levels are:
- Business Level | Describes how the business will function.
- User Interaction Level | Describes how the user will interact with the product/system.
- Business Logic Level | Describes the business rules that the product/system must enforce.
- Entity Lifecycle Level | Describes how the business data is born, how it lives, and when it dies.
- Entity Structure Level | Defines the business data that the product/system must store and work with.
The reason this framework is so useful is that it helps you trace the business needs all the way down to the internal structure of the system. Here is an example of how this can happen:
Don’t Let The Technical Terminology Intimidate You
If you’re completely new to Business Analysis then some of the more technical terms can be intimidating. Don’t let that scare you away from understanding this useful framework.
I’ll be describing each of the levels in plain English throughout next 5 posts. Those posts will help you really understand:
- what each level is meant to do
- how each level gets used during analysis
- the modeling tools available at each level
- which levels you have to focus on for different types of products/solutions/projects.
- Most surgeons and building architects have internalized their frameworks so deeply that it’s now like second nature to them. They don’t think twice when making big decisions under pressure. They intuitively know what the right decision is and they take action.
- You should do the same if you want to excel at Business Analysis. Use the practical frameworks you come across to guide your decisions, and over time they will become like second nature. This is what employers look for when deciding who to hire.
Would anyone else find this useful?
Please share this article with one person who you know is interested.