harmonizing requirements and business architecture

0© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.

Harmonizing

Requirements and

Business Architecture

Capabilities, Context, and

Connections

Keith EllisPresident & CEO

Enfocus Solutions

In partnership with:


What are we going to talk about?

• Business Architecture and Business Value

• Requirements are valuable when Connected and in Context

• Action plan:o Specific changes in how you do

requirementso Specific techniques in supporto Other architecture stakeholders


Enfocus Solutions:Achieving Business Analysis Outcomes


Requirements Excellence Framework™Business Analysis Perspective


Business ArchitectureWhat is it really?


When You Think Business Architecture…


IS

Has

Business Architecture – Enfocus Solution Definition

Context

Ontology(What exists)

Taxonomy(is a common way to describe

and classify things)

Relationships(Dynamic)

View & Viewpoint(Abstraction)

Content• Capability• Value Stream• Artifacts/models

Process• Scope of use• Governance

Purpose• Alignment• Prioritization• Communication


Business Architecture Framework

Location

Product

Regulators

Roles

Business Information

Rules

Vendors

Customers

Organization

Policy

Application

Inventory

Initiative/Investment

Inventory

The business architecture “framework” is a series of models which represent viewpoints of the business and combine to create a “blueprint”.

Business Drivers,

Goals & Strategic

Objectives

Business Use Cases


Contrasting Concepts

Business Architecture Business Analysis

Tend to talk about CapabilitiesRequirements

(Requirement types)

What they are talking about is Stable Pretty volatile

Tend to be focused on Planning (alignment of business and IT)

Project Execution

TechniquesValue streams, capability

map, gap analysis, etc.

Use Cases, Traceability,BPMN, Context

diagramming, etc.

Tend to work Across project teams In a project team


What’s the relationship between the two?The relationship depends on the viewpoint…

Business Architecture Business AnalysisRelationship

When are you doing “Business Architecture”?

Before: Using to drive project strategy and as input to Business Analysis

During: Describing how a project scope fits into the context of an organization

After: Using as part of transition requirements and value realization

“Creates Structure for”

“Identifies Interdependencies in”

“Assesses Value of”


Defining the RelationshipHarmonizing Requirements and Business Architecture

Business Architecture Business AnalysisRelationship

“Creates Structure for”

“Identifies Interdependencies in”

“Assesses Value of”

Relationship

?How does Business Analysis change if we harmonize the

two perspectives


Why is Business Architecture so Critical?It’s a question of scale!

• Exponential interdependency growth• Complexity is very high• The description of Scope is always

frustratingly vague• Can’t roll up critical information• I’m coordinating large numbers of

increasingly time constrained stakeholders• Can’t easily deal with cross-divisional

On a single project:• I want my analysts to be “proactive”• I need to identify my project’s stakeholders• I want improved project outcomes• I must improve how I identify interdepartmental

requirements

Dozens, Hundreds, or Thousands of Projects or User Stories?


HARMONIZING BUSINESS ARCHITECTURE

AND

BUSINESS ANALYSIS: WHAT’S DIFFERENT


What are the Major Changes

• Your process of doing requirements

• How you identify stakeholders

• Where you put certain requirements information

• How you communicate SCOPE

• How you approach detailing requirements


Snapshot of the Typical Requirements ProcessChanging the way you do requirements…

Elicit NeedsDevelop

Requirements

RequirementsDocument

RequirementsValidation

ValidatedRequirements

Document


In the Harmonized World:You START with what is Impacted PC-TADPOL

• Product• Customer• Technology• Application• Data• Process• Organization• Location

Impact

Capture the Nature (Issue/Outcome) and Severity of the Impact

OR

Capability Map

In a Business Analysis Repository

OR


Establish Your Stakeholders Based on the Impact

Each has:

• Owners• Subject Experts• Constraints• Interdependent initiatives


Process Analysis is only ONE way

to identify the features needed to deliver value

You can even change your elicitation approach depending on where the major areas of impact are…


Process Models Should not be in “Requirements” DocumentationSeparate “Requirements” from “Business Architecture” Artifacts

Enterprise Architectural Models

Business Architecture Repository

Business Process

Enterprise Data

ITServices

StakeholderPersonas

BusinessRules

Process Models Data Models System Models Organization Models Decision Models

ProcessImpacts

DataImpacts

IT ServiceImpacts

StakeholderImpacts

Rule BookImpacts

Architectural Impact Assessment


Change How you Communicate Scope

• Need to communicate scope AND how that scope impacts (integrates) into the business context (People, Process, Technology)

• Need to use this to find the functionality BETWEEN impacted entities (this is the stuff that gets missed)

• How you choose to ORGANIZE and analyze projects determines what dependencies you see


Project Control is About Closing the Communication Gap

What is the ANALYST communicating: What are the viewpoints created?

Ideation to Feature

Feature to Requirements

Requirements to Value

Business Viewpoint• What are the major components of the solution?• What is the problem/need? What is the gap? What is

impacted? What are the tradeoffs? What delivers the value?“Solution Scope”

Developer Viewpoint• What does the solution need to do?• What is right level of detail? What are the priorities? What

visualizations or models to use? Do developers understand? Can it be tested?

“Solution Requirements”

Transition Viewpoint• Are we building the right solution?• Does the solution conform to the requirements? What is

needed to transition to new solution? Did the solution deliver value?

“Transition and Solution Validation”


Are Analysts Forced to Use Techniques that Don’t Support Reducing Risk?

Generally: How frequently do projects fail to meet this

objective?

How susceptible is

this Project to

REQUIREMENTS

RISK(How frequently does the

project fail to meet

objectives if an AVERAGE

skill analyst is used)

0%

10%

20%

30%

40%

50%

60%

70%

15% 20% 25% 30% 35%

Reduce transaction

and indirect costs

Launch New

Products

Regulatory Compliance

(limited process change)

Significantly re-engineering

the business processes

surrounding application

Source: Business Analysis Benchmark, 2008

Communications with employees,

suppliers or customers

Reduce direct costs

Better manage internal

information and access

to information Data should be

clustered along

this line

35%

35%

http://www.google.com/url?sa=i&rct=j&q=&esrc=s&frm=1&source=images&cd=&cad=rja&docid=xBslGO_0eaZ2UM&tbnid=G-hc7ZV_Khj5YM:&ved=0CAUQjRw&url=http://www.dougfields.com/posts/teenage-risky-behaviors/&ei=kV2MUcavHI7lqQHkmoDYAw&bvm=bv.46340616,d.aWM&psig=AFQjCNF45-NvY9iosyUaK5dDiLToDZvVOg&ust=1368239846636018


HARMONIZING

ARCHITECTURE AND BUSINESS ANALYSIS: WHAT’S DIFFERENT


Connected RequirementsE

nte

rpri

se A

rch

itec

ture

La

yer

Pro

ject

La

yer

Requirements Repository (Project-focus, Transactional, Stakeholder oriented)

Architecture Repository (Planning-focus, Point-in-time snapshot, IT-oriented)

TOGAF

“CONNECTED REQUIREMENTS”

1) Maintain the synchronization between PLAN and ACTION layers

2) Facilitate interaction between the Owners and Analysts

3) Make it a closed, self-updating, loop


Architects Want the Opposite View… Tell me all the things that impact the enterprise objects


Enterprise Data TraceabilityManage reusable product/services, business processes, business

rules, and stakeholder personas used by all projects

Diagram shows all related projects, features, requirements, etc. for one product/service in enterprise portfolio


What are we going to talk about?

• Business Architecture and Business Value

• Requirements are valuable when Connected and in Context

• Action plan:o Specific changes in how you do

requirementso Specific techniques in supporto Other architecture stakeholders


REMINDER: Enfocus Solutions - Achieving Business Analysis Outcomes

(psst… It’s the secret to successful projects)


QUESTIONS AND DISCUSSION

Getting the Slides:Email to: [email protected] us a little feedback, and Andrea will be happy to send you the slide deck

PDU/CDU InformationYou can submit this course/webinar for PDU/CDU credit to your association by providing them with the following information: • Webinar Title: Harmonizing Requirements and Business Architecture• Webinar Date/Time: October 23, 2013 (1:00 eastern)• Provider: Modern Analyst Media LLC• Email: [email protected]• Phone: (818) 284-6800

For PMI, you should select Category B for the live webinar.For IIBA, use the "Professional Development Other Events" for live webinars. To track your CDUs, please keep track of your "Thank you for attending this webinar email" as proof you attended the webinar.

mailto:[email protected]

harmonizing requirements and business architecture

Documents