In this world of “It’s not my job!” thinking, I look at the practice of business architecture and noticed that nowhere does anyone discuss business requirements as part of business architecture. “We are not IT, we are aligned to the business.” Yet, one of the values of business architecture is to create the bridge between business and IT which means at some point we need to be involved in translating business requirements or business needs.
From the IT side, one of the first steps everyone quotes is “We need to gather the requirements.” It’s almost mechanical. But what does that mean? To most of the IT folks I know, their definition of a requirement starts with the statement “The system shall…” The next thing I hear quite often is “We’ll ask the users.” That’s usually said with a lot of confidence. Let’s face it, “users” hate change the most. I wouldn’t expect them to be a visionary source of requirements for change. Many of the stakeholders I know can tell you what their vision and strategy are, but wouldn’t know how to define an actionable business requirement. So why wouldn’t you want the person who understands the structure of the business to be the one who defines the requirements for closing the capability gaps in accordance with the business objectives?
So, where do the business requirements that support a project really come from? It starts at the top of the organization with the overall strategy, goals and objectives long before the project is started. For the most part, you will not hear that a company objective is to create XYZ IT system, unless of course that’s your company’s product. What you will hear is that the organization needs an efficient and effective way to execute the acquisition portfolio to ensure products and services are delivered consistent with end user expectations. Try putting that into a statement that starts as “The system shall…” and get something reasonably close.
This is where I see business architecture creating the “bridge”. By the time a project has been initiated and a business analyst is assigned to gather project-level business requirements, that’s not the time to start thinking about what the organization needs – the prescribed process in the Business Analysis Book of Knowledge. As the business architect, I believe you should have already formed the strategic business requirements from the company objectives, strategies and tactics. Plus, as you define the value streams, communications and information, you defined the operational business requirements. That way when a project is initiated, the business analyst can easily start with the defined strategic and operational requirements to form the project-level business requirements. That’s the illusive “bridge” that business architects talk about.
Business Requirements are not High-level System Requirements
The problem with most project requirements gathering efforts is that the IT team is looking for ‘stakeholders’ to provide a predefined concept of what the system should be and they expect their business counterparts to have already translated those “requirements” into techy terms – the system requirements. System requirements describe how the system will work, not what the business needs, so starting there rarely works. The key is to develop business requirements first – and before you say it – business requirements are NOT high level system requirements.
Requirements “gathering” is not like gathering apples from a tree – pick the low hanging fruit then work your way up in the tree. Business requirements need a process of discovery and understanding first. Business requirements are ‘what’ the business needs, not ‘how’ to implement the solution aka system requirements. Business requirements should have started long before any initiatives or projects were ever started.
Business Architecture Provides the Tools
My recommendation to my clients is to have the Business Architect begin the requirements discovery process at the strategy level when defining capability gaps. As the architect maps the organization’s capabilities and determines the gaps, they can identify what the business needs to fulfill the gap. Yes, these are business requirements. I call them “Strategic” Business Requirements. Honestly, I haven’t seen an IT project that has shown me a set of Strategic Business Requirements to work from.
Ok, so now the IT team can develop system requirements; Right? Wrong. Just knowing we have a capability gap to close and knowing what it should take to close the gap is not a solution – it’s the definition of what a solution must solve. The next step is to define what has to change operationally to support an initiative that solves one or more of the capability gaps.
Strategic and Operational Business Requirements
This step requires mapping the business capability gaps to organizational units such as business units or departments, value streams and information. The requirements that are discovered here I refer to as “Operational” Business Requirements. Operational business requirements define what needs to change in the structure of the organization. This includes changes to business units, changes to the communications between business units, information that is needed or changed, changes in process and how the change in process affects the customers. Business Architecture defines organization maps, information maps and value streams that easily serve as the basis for these concepts.
Strategic Business Requirements define what the organization needs to meet its strategic objectives. Operational Business Requirements define what changes need to be made to the organizational structure to close the capability gaps. All of this occurs before an IT solution is even considered. Depending on the chosen solution, IT may not even be involved. Management now begins the process of creating initiatives to define solutions that close the gaps. Typically, the Business Architect will have worked with management to update the capability maps indicating which gaps are the most serious to help prioritize the projects.
Project-Level Business Requirements
As projects are assigned, the project’s Business Analysts can work with the organization’s Business Architects to decompose the strategic and operational business requirements down to enough detail to meet the project’s goals and objectives. These requirements are still not in the flavor of “The system shall…” The project’s business analysts then work with the project’s solution architect to translate the business requirements into a solution for which the system requirements will then make sense.
System requirements are always in terms of the prescribed solution. System requirements are “how” the solution will meet the needs of the business. If the solution is to use pencil and paper to maintain a list of people to call, the system requirements would be much different from using a spreadsheet or Customer Relationship Management (CRM) system. The strategic business requirement may have been to put a name and a face with every customer. The operational business requirement could be the salespeople need a way to capture customer information.
User Requirements
But what about “User” requirements? Are they business requirements or system requirements? The answer is it depends. Huh? When the user requirement refers to something related to the business such as having to meet 508 Compliance – a business policy, it should be part of the operational business requirements with a matching system requirement. If it is related to the solution, such as double-clicking the mouse should save and close the record, that’s only a system requirement.
Conclusion
The practice of Business Architecture has opened a lot of doors for providing better solutions to business problems. Requirements are one of the most misunderstood and mishandled concepts in the IT realm and the source of many failed projects. Focusing on strategic and operational business requirements before any IT solution is defined will lead to more focused and successful projects that meet not only the operational needs of the business but also the strategic goals that move the organization forward. This is how the Business Architect “bridges” the gap between business and IT.
