Chapter 3
Business Architecture and Requirements

A factor present in every successful project and absent in every unsuccessful project is sufficient attention to requirements.

Suzanne & James Robertson (Robertson 2004)

When you have completed this chapter you will be able to:

•   Understand and use business architecture and business requirements terms.

•   Describe business capabilities and create a business capability heat map.

•   Elicit and organize data warehousing and business intelligence business requirements.

•   Conduct a successful business requirements workshop.

In this chapter of The Analytical Puzzle, the following topics are explained:

•   Business architecture

•   Business goals, capabilities, and strategies

•   Business requirements

•   Functional and non-functional requirements

•   Conducting the business requirements workshop.

Business architecture and business requirements are critical to the success of data warehousing and business intelligence projects because they provide linkage and alignment with enterprise goals.

Business architecture is a strategic blueprint of an enterprise, or unit of an enterprise, including analytic capabilities. The business architect builds a picture of how multiple views of the future combine to support the organization's stated vision and mission. The multiple views include functional decomposition of the business value chain into business functions and capabilities. The first order of discussion is the enterprise mission, vision, and strategies.

Peter Drucker (Drucker 1974) has recommended these critical questions and their corresponding decisions:

•   What is our business? (Mission)

•   What will our business be? (Vision)

•   What should our business be? (Strategies)

The layers of enterprise mission, vision, and strategies are described in Table 03-01.

Table 03-01: Enterprise Mission, Vision, and Strategies

Mission

The mission statement is a short description of the fundamental purpose and approach of an enterprise. It answers fundamental questions including:

•   Who are we?

•   Why do we exist?

•   How do we do business?

The answers to these questions serve to keep all parts of an enterprise “on the same page”, as well as to inform external stakeholders such as customers and investors. The focus is on the present. A mission statement might say “First Place Toys is an agile company that develops toys in order to help children develop small motor skills. We accomplish this goal by extensive quality and safety testing.”

Vision

The vision statement is an inspirational picture of the future of an enterprise which provides guidance for strategic planning. The vision describes where an enterprise will be in a successful future. For example, a vision statement may indicate the enterprise will be the “Leading Provider in the field of Manufacturing Automation”.

Strategy

A strategy is a long-range plan for managing resources to implement a vision. A strategy could be a long-range plan for improving the effectiveness of a capability, such as innovative product development or excellent service.

In general, the enterprise architect contributes to enterprise strategies by proposing them, and by developing business architectures that support the strategies.

The enterprise mission, vision, and strategies provide guidance and direction to the business architect who models the business needs in the form of the business value proposition. It is the primary benefit that an organization offers its customers. This model may be broken down into lines of business architecture. Figure 03-01 shows a typical business value chain that is widely applicable to many enterprises. The value chain framework is an aid to understanding the business functions and capabilities that an enterprise needs to fulfill its mission.

Figure 03-01: Business Value Chain

The value chain is part of the enterprise picture. Figure 03-02 shows that the value chain translates to core business capabilities that impact stakeholders, including employees, customers, suppliers, investors, regulators, distribution channels, and business partners.

Figure 03-02: Model of the Enterprise

Business functions can be decomposed into lower level capabilities. Then each of the capabilities can be assessed for current and desired maturity. For example, the “Develop Offerings” business function could be decomposed into the following capabilities (among others):

•   Evaluate existing offerings to market opportunities

•   Research needs of customers and markets

•   Evaluate customer feedback.

The maturity level of these capabilities is evaluated using a scale divided into multiple levels, such as aware, trailing, par, leading, and excelling. Table 03-02 describes these maturity levels.

Table 03-02: Capability Maturity Levels

#

Maturity Level

Description

5

Excels

The enterprise has established a capability that is a competitive advantage over peer enterprises, as determined through benchmarking and competitive intelligence.

4

Leads

The enterprise has a level of capability that is ahead of peer enterprises.

3

Par

The enterprise has a level of capability that is similar to peer enterprises.

2

Trails

The enterprise has some level of capability that is behind the level of peer enterprises.

1

Aware

The enterprise realizes that a capability exists and wants to pursue it.

Objective metrics and targets will aid in the evaluation of maturity. A metric is a direct, quantified measure of performance including revenue, cost, unit sales, and complaint count. Targets are quantified goal levels for specified time periods. Targets can take into consideration benchmarks of peer enterprises and strategic choices. Key Performance Indicators (KPIs) are metrics that support strategic goals and are defined in terms of targets.

The Heat Map is a comparison of the current (as-is) maturity level to the desired (to-be) maturity level. Figure 03-03 shows an example of a Heat Map. In this case, three business capabilities are evaluated.

In each case, the as-is maturity level is less than the desired to-be maturity level. For the business capability “evaluate existing products to market opportunities”, the as-is is a level 2 (trailing) and the to-be is at a level 4 (leads). The difference between the as-is and to-be is the gap. When there is a gap of one level or less, moderate improvements could close the gap. However, when the gap is two or more levels, more extreme, transformational change is required.


Figure 03-03: Business Capability Heat Map Example

Business Capability

Level 1
Aware

Level 2
Trails

Level 3
Par

Level 4
Leads

Level 5
Excels

Evaluate existing offerings to market opportunities

 

As-Is

 

To-Be

 

Research needs of customers and markets

As-Is

 

To-Be

 

 

Evaluate customer feedback

 

As-Is

To-Be

 

 

You might ask, “Why not excel at all business capabilities and have a goal of level 5 for each capability?” Each organization can only do so much and must focus on strategic competencies. The industry low cost leader may pursue customer service at a par level, while excelling at offering low prices. Another firm might provide premium products and services for a premium price.

The business architect will work with the enterprise to determine the gaps that are highest priority to close. This typically requires a prioritization of capabilities and linking those capabilities to enterprise goals and strategies.

Often, many root causes for the low maturity of capabilities are due to a lack of data and analytical tools for decision-making. In fact, the same information can have many uses.

Putting together a complete business architecture is a multiyear effort.

Business requirements describe the needed data warehousing solution in business terms. Eliciting and managing business requirements include these activities, which will be described in more detail shortly:

•   Homework (Research of Documents)

•   Enterprise Goals and Objectives

•   Identify User Groups

•   Requirement Interviews

•   Requirement Workshops

•   Sizing

•   Data Exploration.

Business requirements are sometimes known as functional requirements and are the focus of this tutorial section. Technical requirements, sometimes known as non-functional requirements, will be explained in Chapter 4, Data Warehousing Technical Architecture.

Be sure to do your homework before eliciting requirements from others for the data warehouse and business intelligence effort. By doing your homework, you acknowledge the prior data warehousing efforts that have been made, avoid looking uninformed, and save others time by not asking questions that have been previously addressed.

First, you must understand previous data warehousing efforts:

•   Who was involved?

•   What were the results?

Researching documentation can help you get a handle on your organization's current and prior state of data warehousing. You can examine documents such as:

•   Enterprise mission, vision, and strategy statements

•   Business plans

•   Annual reports

•   Business unit plans

•   Data strategy and roadmaps

•   Data warehousing project plans

•   Requirements specifications.

In addition, computer-based information can provide insight into the requirements of existing systems:

•   Database layouts

•   Data models

•   Metadata repositories

•   ETL jobs

•   Programs.

Identifying and engaging the right people to participate in data warehousing and business intelligence efforts is key. Focus on decision makers such as:

•   Executives

•   Managers.

The people who analyze data are subject matter experts (SMEs) who will provide valuable input. Examples are:

•   Financial Analysts

•   Marketing Analysts

•   Information Consumers.

The people who create reports usually have great insights because they are asked by the business to create business intelligence reports. They often have a backlog of requests and “wish lists” that can be translated into data warehousing requirements.

Analytics users may have difficulty knowing or expressing their data requirements. Consider challenging potential users to discuss their problems, pain points, and wish lists to find out what they need.

Business users of data are often saying “I'll know it when I see it.” Create situations where analytics users can experience possible data. This can be done by creating demonstration outputs such as mocked up reports, dashboards, and scorecards. Demonstration outputs can be created by using a quick Proof Of Concept (POC) data mart. Be sure to display in bold letters that the samples are mock ups only and are not ready for use, or some users will have the false expectation that the information will be immediately available.

There are a number of good reasons to interview individual business intelligence users for data warehousing requirements. The reasons include:

•   Obtaining facts beyond research

•   Verifying research facts

•   Answering open issues and questions

•   Encouraging buy in by participation.


Here are some suggestions to make the interview process productive:

•   Start on a positive note – a friendly smile, good eye contact, and firm hand shake help to establish rapport

•   Prepare an agenda and questionnaire

•   Be friendly and flexible, within limits

•   Talk business, not computer buzzwords

•   Use the Kipling Questions as a means of generating ideas for questions that elicit requirements:

I keep six honest serving men, They taught me all I knew; Their names are what and why and when and how and where and who.

Rudyard Kipling

Here some sample questions for the interview:

•   What are the expected goals of your area?

•   How do you measure results? (Metrics)

•   What are the critical success factors of your job?

•   How do you identify opportunities and problems?

•   What business dimensions are important to your analysis and decision-making? (Products, Customers, Vendors, Time)

•   What are your current sources of information?

•   What is your vision for the future of your area?

•   What questions would you like the new system to answer?

A facilitated group session is often a great way to elicit requirements. Requirements are produced in group sessions faster than using individual interview methods. In a facilitated group session, the meeting participants have the opportunity to bounce ideas off of each other and reach a consensus on the requirements.

See the BI Requirements Workshop section of this chapter for a practical approach to conducting group data warehouse requirement sessions.

There are a number of documents that can be used to specify requirements at various levels. Table 03-03 describes many of these documents.


Table 03-03: Requirements Document Types

Document

Description

Needs and Features

A document that describes high-level requirements (needs) and then provides details about the characteristics (features) that are required to fulfill the need. For example –

•     Need 7: System will provide a scorecard display that includes multiple perspectives.

•     Feature 7-1: System will display scores relating to the Financial Perspective.

•     Features 702: System will display scores relating to the Product Perspective.

Requirements Specification

A document that provides a detailed description of the essential and desired functions of the system. It provides more details than the Needs and Features document. See Table 03-04.

User Story

A document, often the size of a 3 by 5 card, which describes a feature of the system from the user point of view. The User Story is an artifact that supports Agile projects. For example –

The Production Manager will be able to view the production for an entire region, and be able to drill all the way down to individual production lines to find and correct the root causes of production problems.

Use Case

A document that describes system requirements in terms of interactions between the system and its users. It supports object-oriented analysis and design and is a recognized Unified Modeling Language (UML) artifact. It includes scenarios for both the most common (the “happy path”) and exception cases.

Each use case includes:

•     Name and identifier, such as UC-1099

•     Description of the use case goal

•     Identification of the actors – people who participate in the use case

•     Assumptions about conditions that must be satisfied for the use case to complete

•     Steps that must be taken to perform use case tasks, including sequence, conditions and exceptions

•     Variations in the overall use case flow

•     Non-functional requirements - describe the manner in which a system must carry out the functional requirements.

SIPOC

SIPOC is a high-level description of a process that is organized into the following subjects:

•     Process – the name of the process stated as a verb followed by a noun, such as “Receive Inventory”

•     Suppliers – the sources of inputs to the process, such as persons or software systems

•     Inputs – the things that trigger and are used in the process, including data

•     Process steps – the series of activities that compose the process

•     Outputs – the results produced by the process

•     Customers – the people who receive the outputs.

User Interface Specification

A document that defines and describes how a person will interact with the system. This often includes display and report layouts, such as scorecard and dashboard layouts. A rough layout of a graphical user interface is often referred to as a “wireframe” or “mockup”; it helps people to visualize solutions. See Chapter 16 to learn more about this.

Data Model

A graphic representation of the data and information needed to support the functionality of the system. It is used to understand the data and design the database(s). Data modeling is described in Chapters 6 through 8 of this book.

Data Dictionary

An artifact that contains definitions of the data, along with descriptions of its characteristics, such as data type. A Data Dictionary is a kind of Metadata Repository. See Chapter 5 for a description of the data characteristics captured in a typical Data Dictionary.

Metric and KPI Specification

A component of the data dictionary that defines and describes metrics and KPIs. A metric is a direct, quantified measure of performance, and KPIs (Key Performance Indicators) are metrics that support strategic goals and are defined in terms of targets. This specification is also described in Chapter 5.

 

Functional requirements are the features and functions of a system; that is, what the system does for those who use it. Each requirement is assigned a requirements number, which is used to track the requirement and to ensure that the requirement is satisfied, as illustrated in Table 03-04.


Table 03-04: Functional Requirements Example

#

Description

Priority

307

The system will provide users with KPIs that support sales campaign management including:

•     Campaign returns per 1000 items mailed

High

308

The system will enable categorization of sales by Region, Territory, District, Manager, and individual.

High

301

The system will enable summary and drill down of general ledger transactions by year, quarter, day, and individual transaction.

Medium

 

Non-functional requirements describe the manner in which a system must carry out the functional requirements. Table 03-05 shows a non-functional requirement example. These requirements are often detailed in architecture documents. The need to provide a specified level of performance while utilizing specified technology is a non-functional requirement.

Table 03-05: Non-Functional Requirements Example

#

Description

Priority

951

Non-Public Private Information (NPPI) will be encrypted, both while being moved and when stored (at rest).

High

952

A Disaster Recovery (DR) hot site must be provided to ensure that service will be restored within two seconds without loss of data, should the main site experience a service interruption.

High

953

Naming of tables and columns will conform to the XYZ Corporation data modeling standard.

Medium

Alignment with corporate business goals, as well as executive vision, strategy, and investment, were important factors in the 3M Global Enterprise Data Warehouse (GEDW) success story. The GEDW team demonstrated to the CEO and other senior executives, through both one-on-one communications and executive committee review, that GEDW contributes to the achievement of 3M business goals. The executive committee provided support to the project both through funding and through management commitment.

In addition to working with the executive committee, the GEDW team elicited requirements by interviewing 250 mid-level managers. (Watson 2004) In addition, the GEDW team streamlined its requirements gathering approach by deciding on and implementing high-level principles. A critical principle explained by Allen Messerli is “Touch It, Take It Data Sourcing.” Using this principle, the team extracted all data from touched source systems when the source systems were first accessed. “This best-practice approach is faster and less costly” than continually going back to the source system to extract more data, according to Messerli.

A second critical principle is that the GEDW must support action by the business, which requires detail about business events and transactions. Allen Messerli explained that establishing a “role-based, event-driven culture” was essential to success. Events and transactions captured in GEDW include customer touch points such as customer calls, as well as system activities such as order processing steps. It is a high-level requirement that business users be able to drill down to actionable date to make a difference.

A third critical principle is the “one face, one voice” philosophy, which declares that information made available to stakeholders must be consistent. This means that customers, suppliers, distributors, and employees have tailored yet consistent views of company information.

Large projects' requirements change many times before they're completed. Important requirements usually remain important as the business changes, while others change or even evaporate. Prioritization lets you deliver the most important requirements first.

Dave Quick

When you have completed this topic you will be able to:

•   Conduct a successful Data Warehousing Requirements Workshop

•   Prepare the Inputs for the Session

•   Define Objectives of Requirements Sessions

•   Develop the Agenda

•   Produce Results

•   Follow up the Session.

Would you like to learn a productive way to elicit requirements while building support for your data warehousing project? The Business Intelligence Requirements Workshop is a great way to get that done. Read further to learn:

•   Benefits of Data Warehousing Requirements Sessions

•   Who does what?

•   Room Layout and Equipment

•   Building and Maintaining Momentum.

Obtaining requirements rapidly using the requirements workshop has numerous benefits:

•   Increased Productivity

•   Improved Solution Quality

•   Rapid Results

•   Longer Lasting Results

•   Enhanced Teamwork and Cooperation

•   Lower Development Costs.

The successful BI Requirements Workshop requires a team effort with assigned roles and responsibilities:

•   Session Leader Facilitator

•   Data Warehouse Modeler

•   Scribe

•   Executive Sponsor

•   User Manager

•   Business User.

The Facilitator leads the BI Requirements Workshop and has responsibilities including:

•   Setting goals and preparing the agenda

•   Keeping the session on task and within scope

•   Encouraging participation

•   Gaining and articulating consensus

•   Leading exercises such as brainstorming or consensus building

•   Identifying follow up tasks and gaining commitment for next steps.

The Data Warehouse Modeler asks questions to identify the data required to support business intelligence. This may include diagramming facts and dimensions or asking related questions, such as: “What is being measured here?” or “How would you slice and dice that information?”

The Scribe records the minutes of the session including:

•   Participants

•   Decisions

•   Requirements.

Again, Rudyard Kipling and his questions will come to our aid. Prepare for the session by answering these and similar questions:

Why

Why are we holding this meeting? (Identify problem, opportunity, or challenge.)

Who

Who will attend the meeting, and who will play each role?

What

What are the inputs and outputs of the meeting?

How

How should the meeting be conducted?

When

When should the meeting be scheduled, and how long should it last?

Where

Where should the meeting be held, and with which facilities?

The Executive Sponsor provides a high-level picture of the goals of the Business Intelligence program. The sponsor also shows that executive management is committed to the program. The User Manager provides expert input and encourages team member participation. Business Users provide subject matter expertise.

Focus on the goals of the workshop. Arrange the room using Figure 03-04 as example, to be effective for workshop activities. Encourage interaction between participants, while focusing on the business intelligence requirements.

Figure 03-04: Room Layout

The Session Facilitator will use group methods, techniques, and ground rules (Figure 03-05) to ensure a successful BI Requirements session:

•   Asking Questions and Probing for Answers – The facilitator will provoke thinking using the Kipling Questions. Open ended questions such as “How would you measure success?” are good for clarifying problems. The lean admonition to “ask why seven times” to drill down to root causes is a great way to probe for answers.

•   Generating Ideas – Brainstorming, brain writing, and the Nominal Group Technique are ways to encourage idea generation.

o         Brainstorming involves a rapid listing of ideas without the inhibition of evaluation.

o         Brainwriting is a structured technique to generate many ideas in a limited period of time. Participants bring 3 ideas. The team is broken into small teams who generate ideas and record them on sticky notes in 5 minute rounds. Ideas are clustered and shared with the larger group.

o         Nominal Group Technique is a decision making technique that encourages participation. After an introduction, participants individually record their ideas on paper. Next, participants share their ideas. This is followed by a group discussion. Finally, the ideas are voted on and ranked.

•   Evaluating Ideas – Determining which ideas are best is a multi-step process. First, criteria must be identified and weighted. The criteria form one side of a matrix. Second, the degree that each idea satisfies the criteria is evaluated using a consistent scale, such as a 1 to 5 scale. Finally, the weighted score of each idea is determined by multiplying the score by the criteria weight. The sum of the weighted scores will provide an overall rank for each idea. This scoring process can be done by individuals or a group. These scores are used to select which ideas are implemented.

•   Consensus Building – Consensus is reached when a group decision has been made wherein a majority of the participants agree with the decision, participants feel heard, and participants support the decision. The facilitator builds consensus by stating ideas and asking for agreement or disagreement as well as the reasoning behind agreement or disagreement.

•   Using Presentation Materials and Equipment – The successful facilitator is skilled with both presentation materials and electronic equipment.

o         Facilitator Tool Kit – Be ready with supplies: markers, flip charts, sticky notes, and easels.

o         Equipment – The facilitator requires computer with presentation software, diagramming software, and a projector.

•   Dealing with Difficult Group Members – Difficult members may derail facilitated group sessions. Be ready to address these challenges:

o         Non-participator – This person says little and does not participate in discussions. Periodically ask this person questions about topics where the person can contribute. Also, structure methods so that each person contributes, for example using brainwriting.

o         Monopolizer – This person dominates discussions to the point where others do not have a chance to participate. First, set ground rules such as the five minute rule, which limits discussion of each topic. Second, ask the person to focus on the identified topic. Third, summarize the person's points and then move on by inviting others to provide their perspective.

•   Encouraging Participation – The facilitator can encourage participation by asking questions of non-participative members; dividing the group into smaller teams, which gives each participant more “air time”; and by asking participants to individually write and then share ideas.


Figure 03-05: Ground Rules

The BI Requirements Workshop can have a number of positive outcomes:

•   Requirements are documented

•   Benefits are identified

•   Costs of not having BI are identified

•   Business processes, including analytical business processes, are identified

•   Business roles are identified and related to the business processes

•   Participants better understand BI and the BI program

•   Preliminary measures and KPIs are identified and related to business processes

•   Potential analytic data is explored

•   A list of business questions that the business wants to see answered are specified

•   Preliminary facts and dimensions are identified

•   Preliminary models are created

•   Risks and mitigations are identified

•   Follow up tasks are identified and assigned

•   Forward momentum is increased.

The benefits and costs elicited are great supporting material for the business intelligence business case, which in turn is critical to the success of the program.

Realizing the outcomes of the BI Requirements Session requires follow up. In this case, you will:

•   Document and distribute the results of the session

•   Update requirements documents

•   Follow up on “Action Items” identified during the session

•   Schedule a second session to validate the requirements.

 

Key Points

•   Elicit DW business requirements using a sound methodology.

•   Get the right people involved in the requirements gathering process.

•   Group sessions are an effective way to elicit requirements. This approach is faster than a series of individual interviews and has the advantage of building consensus and resolving differences.

•   Group sessions have drawbacks that should be compensated for. For example, not everyone may participate and the group may engage in groupthink. Be sure to include individual sessions to obtain a balanced view.

•   Lack of documented and agreed upon requirements is a leading cause of project failure.

•   Exploring data can help users to visualize their requirements.

•   Interactive group sessions are an excellent way to elicit and document data warehousing and business intelligence requirements.

•   A successful requirements session requires thorough preparation.

•   A productive requirements session is a team effort that includes the roles of facilitator, executive sponsor, scribe, data modeler, and business experts.

•   Group methods, such as setting ground rules and idea generating techniques, boost output of requirements sessions.

•   Follow up is required to implement the requirements identified through requirements sessions.

Build your know-how in the areas of business architecture and business requirements using these resources.

Visit a Website!

APQC is an industry organization that has built an excellent library of business capabilities and business processes.

http://www.aqpc.org

The International Institute of Business Analysis (IIBA) has developed outstanding guidance for eliciting and documenting business requirements. Check out their Business Analysis Body of Knowledge®(BABOK®Guide).

http://w ww.iiba.org

 

Read about it!

This book shows how to define business architectures and elicit requirements:

Laursen, Gert H. N., and Jesper Thorlund. Business Analytics for Managers: Taking Business Intelligence Beyond Reporting. Hoboken, NJ: Wiley, 2010.

 

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.191.194.123