Strategic portfolio management for ITBrian Loomis

Microsoft Corporation

Agenda

• Know your model and your goals with IT

• Business architecture and strategy

• A prototypical organization

• Prioritization based on cost and value

• Architecture standards

• Differentiated service architecture

• Service management

Four types of business operating models

Coordination

•Shared customers, products or suppliers.

•Impact on other business unit transactions.

•Operationally unique business units or functions.

•Autonomous business management.

•Business unit control over business process design.

•Shared customer/supplier/product data.

•Consensus processes for designing IT infrastructure services; IT application decisions made in business units.

Unification

•Customers and suppliers may be local or global

•Globally integrated business processes often with support of enterprise systems

•Business units with similar or overlapping operations

•Centralized management often applying functional/process/business unit matrices.

•High level process owners design standardized processes

•Centrally mandated databases.

Diversification

•Few, if any, shared customers or suppliers.

•Independent transactions.

•Operationally unique business units.

•Autonomous business management.

•Business unit control over business process design.

•Few data standards across business units.

•Most IT decisions made within business units.

Replication

•Few, if any shared customers.

•Independent transactions aggregated at a high level.

•Operationally similar business units.

•Autonomous business unit leaders with limited discretion over process.

•Centralized (or federal) control over business process design.

•Standardized data definitions but data locally owned with some aggregation

Hig

h

HighLow

Lo

w

Business process standardization

Bu

sin

ess p

rocess I

nte

gra

tio

n

Source: David C. Robertson, Jeanne W. Ross, and Peter Weill. Enterprise Architecture As Strategy. Boston: Harvard Business School Press, 2006.

Operating models of a business can be classified based on the degree of business process

integration and standardization.

Business architecture processes

Innovation

Support

PLAN

BU

ILD

RU

N

Demand generation / portfolio planning

Project management

Value realization

IT as co-innovator in business delivery

• Directly adds to product or service

• Customer-facing service applications

• Embedded technology in products

IT as automation of business process

• Indirectly reduces COGS

• Reduces risk from compliance,

satisfaction goals

Typically not a BA function, but

generates data for planning, VR

PMO & portfolio

planners

Project managers

(work with non-IT

sponsors)

Project implementers

(often an SI)

CoE’s

BUILD

PLAN

An organization modelAlign for managing demand

Service leaders

Operations staff

Trainers, evangelists

Help desk

RUN

Use

rs

Busi

ness

unit

s

External partners (suppliers, down-streams, etc.)

Work processes (sales, R&D, HR, etc.)

dem

and

External liaisons

BU

lia

isons

WP l

iais

ons

CIO

CTOCSO

Systems architects

(sub-systems)

Lead/strategic architects(data, info, app dev, client systems,

SAP, extranet, platforms, integration,

PIO’s)

Annual planning modelAligning different streams of value in a recurring review

Partial information on certain

aspects:

• Cost (estimated)

• Schedule

• Value (differing categories)

• Resources

• Pre-reqs and dependencies

• Impact if not started

• Alignment to major

program/business (maybe

from heatmap)

PROJECT TITLE (excludes normal operations costs and major program AA)

Joint venture IT review

Acquisition integration (small)

Windows platform definition for SAP basis

Sales and cust svc database performance tuning

Business intelligence dashboards from SOR data

Define SLAs for major services

Improve reliability of System X

Automation/monitoring improvments for Major Platform Y

R & D portfolio planning (multiple projects)

Advanced manufacturing portfolio planning (multple projects

Implement Phase 2 of sustainability project

Decrease cost to operate core capabilities by 5%

Next-generation workstation & user segmentation

Mobile app Z

Simplification project for extranet

Onboarded acquisition app reductions & app governance

Intranet rehosting and app hosting platform definition

Manufacturing systems upgrade (cloud?)

Center of Excellence for SharePoint development (collab)

Accelerate IP protections for non-Office documents

Insource Active Directory from current SI

Implement CMDB

Increase database availability (burning platform)

Customer satisfaction survey

Phase 2 collaboration service

Implement external collaboration

Replace current Enterprise search solution

Define info arch (10 years too late!)

Implement controls for audit defense

Test new vendor cybersecurity system

Core Model Relationships – A Shift in Architecture towards Business

Benefits Dependency Network

How What Why

Business Capability Model

IT Services Model

IT Portfolio Assessment

Conceptual Architecture

Roadmap

WhenValue Model

Funding modelsService management tells us…

• How things get paid for, matters – for operations and projects and “architecture”

• To know if we are being good stewards of these funds, we tie specific value to projects and systems (program of change) and we measure change to current value

• This value has to match the source of funding well: commodity service may be per adoption unit, KPI’s may be used for a business project

• Changes to services, and new services imply change in cost to serve – know these costs through a CMDB or formal recharge mechanism

• The other piece we need to know is the units consumed (adoption)

• A tax per user is often abused and hard to get meaningful numbers out of

• Without meaningful data, we cannot apply management techniques other than “gut feel”

Source: Gartner, 12 December 2006/ID Number: G00144853

Responsible stewards of resourcesBut we’re comparing apples, oranges and spaceships!

• Differing funding sources and different definitions of value• Business architects may represent projects with business value (in metrics aligned to VP),

can also dip into or evangelize low-cost commodity services where available, even if not paid by the business directly

• IT architects represent current commodity services and major programs (like an SAP migration) with benefit to all users, often focusing on per user cost savings

• External project sponsors may not even have a value proposition in quantitative terms for many years

• Security & compliance – where do they fit?

• How do I pick a list of projects, then? Pragmatically, in part.• Pick a balance of demand sources, to maximize return for given resources and schedule

• Just like investing, the S&P 500 is better than trying to pick favorites*

* Don’t worry, favorites (a.k.a. major programs) will still continue. The key is to make sure they get a specific funding “line”

and don’t rob from other areas and we don’t rob from them (blurring other priorities)

Guiding IT architecture principles

1. Safety, plant resilience (DR), complies with all regulations

2. Speed to implement (generally favor COTS over custom)

3. Available in country

4. System complexity (including vendor standardization)

5. System longevity (supported lifecycle of 10+ years desired)

6. Standard, adopted technology preferred (existing system cited or direction doc)

7. Overall system cost (including operations & maintenance)

8. Business value case for differentiation/innovation (vice outsourced)

9. Follows industry standards, where not differentiated

Priorities are often ranked by culture, and by operating model (CISR-Coordination, Unification, Diversification, Replication) as a proxy for financial OM

Consistent Core versus an Agile Edge (MSIT)

•Optimize for velocity of delivery and business flexibility

Agile Edge

• Evaluation by relevant governance body for potential moving to the coreGrey area

• Optimize for re-use and cost reduction with a focus of delivering value to more than one organization

Consistent

Core

• Processes

• Information

• Data

• Platforms/Services

• Architectures

Govern

ance

Architectural Points of View inform situational decisions/governance

Risk premium – when do we make exceptions?

• In some areas, we build for flexibility (maybe by using two competing solutions) or other -ilities. In these cases, we are trading off cost and speed for a functional solution or building in a risk premium – paying for the ability to change our mind.

• Speed of change may vary based on domain or work process.

• Domain priorities may vary in a diversified business model – one product group/business may be moving faster than another business

• Depth (cost) of implementation may vary per domain priority – build versus buy, extra monitoring/troubleshooting, investment for future versions, integration with help desk, etc.

Questions and answers

Feel free to contact the speaker directly with any follow-up questions

IASA is on the web at http://www.iasaglobal.org

Be sure to check our online listings for courses, certification events, local architecture communities, and future webinars.

Thank you for joining us!