A case study of the evolution of the Business Analyst and ... · Oracle Siebel CRM New System...

Who sees the trees? Who sees the woods?

A case study of the evolution of the Business Analyst and Business Architect roles at WestJet Airlines Ltd

Who is WestJet Airlines Ltd?

Ø  WestJet was founded in 1996 by a team of Calgary

entrepreneurs as a western Canadian regional carrier with

3 aircraft flying to five cities.

Ø  Started as small entrepreneurship, approx. 100 employees, 3 aircraft

Ø  Currently an enterprise with 8,500 employees and still growing rapidly

Ø  Today, WestJet is Canada’s leading high-value low-fare

airline offering scheduled service to 76 destinations in

Canada, the United States, Mexico and the Caribbean, with

its fleet of 99 Boeing NextGeneration 737 aircraft (will be

100 aircraft soon)

Who is WestJet Airlines Ltd?

Ø  2010 changed core systems in 1 yr – Reservation system,

Revenue Accounting system, Loyalty, Vacations Reservation

system

Ø  Highly complex integration environment

Ø  Tumultuous change that drove the need for an enterprise

view

The mutual identity crisis and how the Business Architect and Business Analyst roles have evolved together

Ø  Initially Business Analysts perceived Business Architects as

having overlapping roles

Ø  The unique contribution of Business Architects in projects

was unclear

Ø  Practical architecture was the mandate we were given – no

ivory tower


Ø  Built credibility, enabled understanding of our role

Ø  Over time the Business Architecture role has evolved,

solidified as a consistent approach and practice has been

developed

Ø  Business Analysts and Project Managers now have clear

expectations when engaging with Business Architects:

diagrams, questions, structure, service


Ø  The Business Architect provides the enterprise view of the

business functions and systems used


Ø  The business architect relies upon the business analyst to

provide the detailed view into an enterprise function

IT Organizational Structure

Business Unit Chief Information Officers

EVP EVP EVP EVP CIO

CIO CIO CIO CIO

CEO

CIO

Director of Operations

Chief

Technologist

Data Services Release Management

QA & Test Security

Networks Infrastructure Apps

Operations

A R C H I

T E C T U R E


Ø  It’s all about perspective, with both being just as important

as the other in any enterprise

Business Architects’ contribution: simplify complexity and enable common understanding

Ø  Manage Complexity

Ø  Enable Enterprise Planning Ø  Promote Best Practices and Consistency

Manage Complexity - Architecture Framework



Ø  Enable Enterprise Planning – Portfolio Management Ø  Promote Best Practices and Consistency

Enable Enterprise Planning - Project Interdependency Diagram

Legend

Common require

ments, scope delineatio

n, roadmap,

implementatio

n timing

Common requirements, scope delineation,roadmap, implementation timing

Integration, test strategy and plan

Integration, test strategy and plan

Common requirements, scope delineation, roadmap,implementation timing

Common requirements, scope delineation,

roadmap, implementation tim

ing

Com

mon

req

uire

men

ts, s

cope

del

inea

tion,

road

map

, im

plem

enta

tion

timin

g

Common re

quirements, s

cope delineatio

n, roadmap,

implementatio

n timing

P J 000001E nterprise P roject

S ystemNew S ystem

P J 000002E nterprise

P roject

Generic Sy s tem

New GenericSys tem


P roject


P roject

B U B us ines sUnit P roject


P roject


P roject

2012 P roject2011 Carry

Over P rojectB usiness

U nit Initiative No Impact2013 P roject

This project interdependency diagram is intended to be a collaborative toolto stimulate discuss ion and awareness of the influence and impacts ofenterprise level projects , as well as business unit projects.

Business Owner: John SmithIT Owner: Willy WilliamsProject Manager: Johnny RattrayBusiness Analyst: Hulio Igles ius

C ompleted

Enable Enterprise Planning - Project Interdependency Diagram

L egend

Capability R

eplication & high availability requirem

ent

Guest Profile Information

R equired for load testing

Guest Profile Information

Em

ploy

ee P

rofil

e In

form

atio

n?Guest Profile Information

Alignm

ent of vendor and WestJet identities

E mployee P rofile Information?

Em

ployee Profile Inform

ation?

E mployee P rofile Information?

Integrate

check-in w

ith

other functio

nality

P resentatio

n Layer

Integrate check-in with other functionality

P resentation Layer

Integrate check-in with other functionality

P resentation Layer

Integration requirements

User credential system of re

cord

Integration require

ments




Und

erly

ing

tech

nolo

gy


P rofile Information


Integratio

n require

ments

"Phase 2"/P

rofile In

formatio

n

R oadmap component

R oadmap component

Roa

dmap

com

pone

nt

Integration with reservation system

"C h a n ges to th e C I da ta ba s e s c he ma ( N S K- P P P) "/Align men t of da ta de finition s , ma ppin g,re qu ire me nts , o ppo rtu n itie s

Guest Profile

Inform

ationAlig

nment o

f Require

ments

Capture and m

aintain information about G

uest preferences for premium

products

Em

plo

yee

/ Gu

est profile

inform

atio

n, sin

gle

sign-on

supp

ort, a

ccess via

the

po

rtal

« #6»P J 000205 Identity &

P rofile S ervices 2012

« #2»P J 000201

G uest F acingE ast C oast

P oint ofP resence

« #11»P J 000210 Mas s

R E W A R DSP has e 2

« #17»P J 000216 Q ALoad & T es t

« #1»P J 000200 New

DigitalS torefront - IB E

« #20»P J 000219

T alentManagement

P J 000104 S elfS ervice

Check-In P has eI

« implemented»1

K ios k C heck-In

« #8»P J 000207E nterprise

Notifications

« #4»P J 000203B roadband

W ireles sO nboard

« #9»P J 000208

Mobile P hase 1

« #12»P J 000211

W estJ et B ank

« #14»P J 000213

V acation B idding

« #10»P J 000209

W estNet T ravel

« implemented»2

Mobile Check-In

« implemented»3

W eb C heck-In

S ystem

Ora cle SiebelC R M

New S ystem

Active Direc tory(AD)

Ora cle J DEdwa rds

ESB / FTI

KronosW ork forc e

C entral

IBM Tivoli Suite

Enterpris eDirec toryServ ic e

Sabre TravelBank

B U ADP rovisioning

B U K ronosS ingle-S ign-O n

B U P as swordS elf-S ervice

SabreSonicR es ervation

Sys tem

B U S abreCustomer

Insight P P P

P J 000059S MaR T

Automation

P J 000111 DataMart S ervices

B U 3rd P artyDirect Connect

« #3»P J 000202 F are

B undling

P J 000X XXO perationsP ublication

S ervice

2012 P roject

IBM TivoliFedera ted

Identity Ma na ger

IBM TivoliAcc es s

Ma na ger

2011 CarryOver P roject

B usinessU nit Initiative

Business Owner: Mike HafichukIT Owner: James CallaghanProject Manager: Business Analyst:

No Impact

IBM Tivoli IdentityMa na ger

2013 P roject

This project interdependency diagram is intended to be a collaborative tool tostimulate discussion and awareness of the influence and impacts of enterpriselevel projects, as well as business unit projects.

C ompleted

* This slide intentionally blurred to hide proprietary content. Point is to illustrate possible scale of complexity



Ø  Enable Enterprise Planning – Scoping and Requirements Ø  Promote Best Practices and Consistency

Enable Enterprise Planning - System Interaction Diagram

E xternal Hosted S ys tems

Internal Hosted S ys tems

L EGEND

Informa tio n F low sInforma tio n F low s

Informa tio n F low sInforma tio n F low s

Info

rma

tion

Flo

ws

Info

rma

tion

Flo

ws

Informa tio n F low s

Info

rma

tion

Flo

ws

Informa tio n F low s

E xternalS ystems

E xternalS ystem

Exis ting WSHos ted Sys tem

Non-Hos tedSys tem

New Sys temChanges to

Exis ting Sy s tem

Net New Information Flow

Exis ting Information Flow

Change to exis ting information flow

S ystem

T hird P artyS ystem 2

T hird P artyS ystem

S ystem 2

Enable Enterprise Planning - System Interaction Diagram


Enable Enterprise Planning - Process Flow Diagrams

Informa tion Store

Sys tem

R ole

Information Flows

Information Flow

s

Sta

tic In

form

atio

n

Information Flows

Static Inform

ationProc es s 1 Proc es s 2

Proc es s 3

Informa tionStore 1

Proc es s 4

Informa tionStore 2

StartProc es s

StopProc es s

Enable Enterprise Planning - Workflow Diagrams


Enable Enterprise Planning - Holistic Requirements Analysis


Priority Stages Governance

Implementation Requirements

Process Products (Capabilities) Information



Governance Product (Capabilities) Process

1.a Establish foundation for Information Management

-Role: Enterprise coordinator of all possible WS credit accounts available to guests, the systems on which the accounts reside, and the channels that can be used to access the credits (23)-Role: Enterprise coordinator of all possible transactions that can use WS bank (eg. central GR coordinator)(21)- Role: Enterprise coordinator of all financial analses and reports required against guest credit usage and credit management (2)- Role: Information coordinator for transactional systems (1)

- Central Repository for all Governance and Information Management artefacts (eg.Policies, Definitions, Info.Sources)(including SOPs) (31)

Pre-conditions:- Standard, centralized enterprise process for setting up new transactions and recording all information about the transactions (16)- Standard, centralized enterprise process for setting up new forms of credits and recording all information about the forms of credits and how they are managed (14)- Standard, centralized enterprise process for coordinating the release of new transactions and recording all information about the transactions including impacts to other transactions and affected stakeholders (12)- Process to identify all stakeholders that can provide information about transactions that use credits (leveraging known existing systems of records for transaction revenue data could help) (12)- Business process to ensure credit issuance rules and procedures are consistently and accurately followed and applied at all points where credits are issued or revoked.(5)- Standard, centralized enterprise process for recording and setting up reporting requirements against credits and payment/credit transactions (2)

1.b Establish foundation for Operations Control

-Role: Rules owner (9)-Role: Central administrator to control accessto credit accounts and credits within accounts (7)-Role: Rules Specification Coordinator (7)-Role: Rules Auditor (3)-Role: Central Compliance and Regulatory Coordinator (3)- Role: Solution owner/operator (3)- Role: Central authority to review and approve terms and conditions between WS and Guests on access, use, and update of credits (1)-Definition of voucher vs credit and the difference in how they need to be treated (18)-Standard: all WS credit accounts are electronic (10) -Policies and rules on access control (10)-Rules:WS Credit usage rules for each transaction (10)-Consistent and concise rule definition structure (10)-Compliance and regulatory rules and policies (4)-Standard and policies for financial accounting and auditing (3)- Standardized and documented methodology for building rule specifications (3)-Policy: There is a single system of record for each type of credit a guest can have. (4)-Standard: approved agreement between WS and Guest on access to and use and update of guest WS credits (1)-Policies around credit liabilities (??) (1)- Rules on credit conversion (where necessary) (1)

Pre-conditions:- Credits must be entered into a guest credit account before they can be used (12)- Centralized process to review and approve access controls to guest credits (4)- Centralized process to validate rules for compliance with standards and policies (4)- Centralized process to consolidate regulatory and compliance policies , standards, and rules (4)- Process to translate regulatory and compliance policies , standards, and rules into applicable rules for transaction processing (4)- Centralized process to review and consolidate accounting and auditing standards and policies (3)- Process to translate accounting and auditing standards into applicable rules for transaction processing (3)- Central 'contract' process to establish and approve terms and conditions between WS and Guests for all payment and credit policies on guest transactions. (1)

Processes required:- Procedures to address failures in credit processing (2)- Determination of what credits are valid for a transaction made before the guest is presented with credit choices (1)

2. Manage Functional Requirements

- Role: Business Analyst/Credit Management strategist (4)- Value metrics for business use cases (4)- Role: Process Analyst/Modeler (1)

-Bank makes determination on optimal use of credits before presenting options to guest (3)

Pre-conditions:- Discounts and other special adjustments are applied prior to requesting a payment or providing a credit (1)

Processes required:- Credit-card processing done outside the bank, but the bank informed of the outcome of using CCs (5)

3. Establish Technology foundation

-Standard reference interface to guest WS credit accounts (7)-Standard reference interface to guest-facing apps (6)-Design guidelines/methodologies to promote flexibility and reusability of designs (4)

- Interfaces to guest-facing apps on multiple platforms (1)- Integration across systems (25)-Rules Management: (17) Configuration - human-readable interface;minimal training requirements - ability to provide universally unique identifiers for rules Audit - ability to identify accounting and auditing rules - ability to identify compliance and regulatory rules Repository- Security and Access control (17) - provide information about agents involved in access- Real-time access to guest credit accounts and credit amounts (7)

Pre-conditions:- Guest is authenticated prior to accessing accounts they own or accounts they are designated to access (3)

Processes required:-Design review process (2)- Low latency for updates. (Updates are performed as soon as possible to ensure consistency) (6)-Standard operating procedure (SOP) for adding new rules (3)

Implementation RequirementsPriority Stages

* This slide contains a link to a document with proprietary content that is shown at the conference, but not available for handout



Ø  Enable Enterprise Planning Ø  Promote Best Practices and Consistency

Promote Best Practices and Consistency – Folder Structure

Promote Best Practices and Consistency – Engagement Model

Metadata Repository

D ata D ictiona ry D efin itions

Informa tion & Process Flow Mode ls

Analysis & Reporting Requirements

D a ta Schemas:Sources and Ta rgets

Mode lling Standards and Best Practices

Enterp r ise Business Process Know ledge

Mode lling Standards and Best Practices

Enterp r ise In fo Mgmt Policies &Gu idelines

D a ta Stew ard R o les andR esponsib ilities

Data

Ste

ward

Rol

e Re

com

men

datio

ns

N e w I n f o r m a t i o n S e r v i c eR e q u i r e m e n t s

D a ta Transforma tion R ules

Informa tion Services Specifica tions

Business Objectives and Processes

Informa tion Service R equests

Business Analyst

Business IntelligenceAnalyst

DataCzar

DataGovernance

Analyst

Business ProcessOwner/Stakeholder

InformationCoordinator

- ESBBusinessArchitect

Data Architect

Da taDe f i n i t i on

Team

B us i nes sS uppo rt

TeamS y s t ems A na l y s t

ESB Serv icesTeam

DataGovernance

Team

IT SecurityAnalyst

*Note*

Bolded Roles: are roles primary to discovery,clarification and validation of business informationneeded by the process owner

Non Bolded Roles: are supportative roles toclassify, structure, organize, maintain data about

Visuals – Architecture Toolbox

Ø  “A picture is worth a 1000 words” – cliché, but also very true.

Ø  Collaborative

Ø  Promotes discussion/engagement

Ø  Keep simple, easy to understand

Ø  Always keep your audience in mind

Ø  Remember: A diagram is nothing more than a communication tool –

if breaking modeling conventions helps to convey your message,

break them

Lessons learned - the approach, the collaboration, the patience

Ø  Unique perspective enables the business architects to see

opportunities for re-use across the enterprise

Ø  Start simple: abstractions vs. details

Ø  Engage through visuals

Ø  Baby steps on multiple fronts

Lessons learned - the approach, the collaboration, the patience

Ø  Establish consistency

Ø  Architecture is a process, not an end state

Ø  Business Architecture “nirvana” is a journey without destination

o  Constantly evolving state

o  Always adapting to a fast changing world

o  Accept the grey, no black and white

Ø  Patience

Summary

30 10/19/12

Business Architects - Provide enterprise views of business operations: cross-functional linkages

- Identify opportunities for enterprise services and solutions

- Research and develop methods and artifacts for complex problems

- Provide consultation and support to project teams

Business Analysts

- Provide detailed views of functional operations

- Identify required features and use-cases for enterprise services and solutions

- Apply and provide feedback on analysis methods and artifacts

- Influence key stakeholders to facilitate operational change

Summary…thank you

Sometimes you can’t see the forest for the trees…

Business Architecture enables a view of the forest,

while Business Analysis studies the trees.

31 10/19/12

A case study of the evolution of the Business Analyst and ... · Oracle Siebel CRM New System...

Documents

Transcript of A case study of the evolution of the Business Analyst and ... · Oracle Siebel CRM New System...