Workplace Technology Devices: Session 5

1

Architecture Framework Advisory Committee Meeting

May 26, 2014

Agenda

TIME TOPICS PRESENTERS

9:00 – 9:15Opening Remarks

Benoît Long, ChairWade Daley, Vice-Chair

9:15 – 9:45Presentation and

Recap

Natalie McGeeSenior Director,Distributed Computing Transformation Program

2

Transformation Program

9:45 – 11:30 Discussion Period Moderator: ChairParticipants: All

11:30 – 12:00Closing Remarks Benoît Long, Chair

Objectives for Today

• Recap of the last Architecture Framework Advisory

Committee (AFAC) meeting on Workplace

Technology Devices (WTD)

• Conclude the consultation roadmap

3

• Conclude the consultation roadmap

• Thank you

AFAC Consultation Roadmap

STRATEGY KEY ACTIVITIES

2014–15

AFAC INPUT

� Recommendations for Strategic Questions

� Guiding Principles/

Common

Requirements/

Service Strategy

Service Delivery

Model

User Segmentation

Model/End-state

Service Strategy

January 20

February 24

4

� Guiding Principles/ Best Practices

� Experience/Case Studies

� Risks/Success Factors

Service

Transition and

Implementation

Technology

Architecture and

Solutions

r Segmentation

ModelSegmentation

ModelPilot

Functional

Direction

• Meetings

• Demos

• Written

Submissions

Formal

Industry

Engage-

ment

March 14,

April 17, and

today.

Discussion: Service Desk Options (updated since April 2014)

• Single toolset/process

• Multiple service desk

contractors/locations

• 2 locations? 3? 4?

Service Desk (SD) Tool

Level 1 Level 1 Level 1 Level 1

• Single toolset/process

• Single service desk

contractor/integrator

Service Desk (SD) Tool

Level 1 Level 1 Level 1 Level 1

#2

#1

5

contractor/integratoracross multiple locations

• Integrator with multiple

levels

Level 1 Level 1 Level 1 Level 1

• Multiple toolsets/processes

• Multiple service desk

contractors/locationsLevel 1 Level 1 Level 1 Level 1

SD Tool SD Tool SD Tool SD Tool

#3

What we heard: User Segmentation and Service Delivery Model

User Segmentation•Members had many opinions, however most rejected segmenting users on number

of applications.

•The idea of segmenting users on level of mobility or security seemed most favoured

by members.

• In general, mobility factors can a be key driver that should be a main focus for GC.

6

•In some cases members spoke about segmentation by “persona”, suggesting that

users could have multiple personas that would be different for different

circumstances.

Service Desk

• In almost all cases participants suggested the need for common processes and

common tools (Option 2).

• Most members did not support Option 3 (multiple tools and processes).

More Discussion: Service Transition and Implementation

STRATEGIC QUESTIONS

Transition/Roll-Out

• What are guiding principles or best practices to manage the interface or point of

integration between a common build and a diverse application stack distributedacross multiple lines of business?

• Based on experience or case studies, what GC current-state information sets

are recommended as mandatory information to reduce complexity of transition?

7

• Based on experience or case studies, what end-user and site-specific data setsare recommended as mandatory information to reduce complexity of transition?

End Users

• How did you approach change management of end users in the

client organization prior to and during transition?

• What do you suggest client organizations could have done

better to collaborate during the transition?

More Discussion: Service Transition and Implementation

STRATEGIC QUESTIONS

Service Transition and Implementation

• Is there value in the GC defining a common image/enterprise desktop baseline,

and then starting to transition to this baseline (including application remediation)?

8

• What process would you follow to get to a common image / base platform?

• What are your suggestions on the on-going operational model between the

desktop management provider and the application teams in departments /

agencies to maintain / patch the baseline?

Thank You

• Conclusion of AFAC consultation.

• Next steps to watch for are the initiation of formal

procurement activity in the Workplace Technology

Devices initiative.

9

Devices initiative.

Reference

10

What We Heard From AFAC (1 of 6)Risks and challenges to prepare for:

Ability to execute

Understanding desktop initiatives are not the same as other initiatives

1 • Doing everything at once poses a significant challenge to GC and industry

• Based on the user set, 100K users seems like a manageable base to work with in

transformation

• Desktop initiatives have their own set of challenges

• Challenges relate to lifecycle of end points

• Interdependencies with rest of IT

2

11

5

3Legacy applications• Living with an aging application stack represents major constraints to achieving cost

savings

• Application integration – the line between operating systems and application is not rigid

Infrastructure readiness

User acceptance

4 • Strategy and manageability from a Local Area Network/Wide Area Network (LAN/WAN)

perspective

• Being able to deliver a solution that is better than what users have today

• Watch for over-centralization, do not model like an 8-step telephone key pad sequence

What We Heard From AFAC (2 of 6)

Feedback on how to proceed with:

STANDARDIZATION

• The number of

desktop images

might be the wrong

place to start. Start

with a baseline

PILOTS

• If you are going to

pilot, make the pilot

large enough.

VIRTUALIZATION

• Likely the only

viable strategy in

delivering multiple

styles of desktops

to GC users

• Better fit would be

PICK YOUR OWN

DEVICE versus

having retail

devices brought in

BRING YOUR

OWN DEVICE

12

with a baseline

configuration of the

desktop.

• Have a single

common desktop

engineering service

for the GC and

reduce duplication.

to GC users

• Best way to address

diversity of

authentication of

devices (desktops,

phones or tablets)

• Should consider

going beyond

virtualization and

go directly to cloud

devices brought in

What We Heard From AFAC (3 of 6)

Feedback on how to proceed with:

APPLICATION

INTEGRATION

• Future is in browser-

based solutions.

Consider setting up a

team of experts that

bring schools of

DEVICES VERSUS

SERVICES

• Put emphasis on

services and not just

devices.

• A large IT company has 350K

employees in different countries, with

multiple languages, lots of executives,

sales, marketing – they have only one

profile.

USER PROFILES

13

bring schools of

methodology, expertise

and tools to help them

move away from

legacy.

MOVE TOWARD

SELF-PROVISIONING

• Enables self-service and

application store –

metric idea: measure

the reduction of help

desk calls

profile.

• For example, 12 profiles (as would be

the case for one federal agency).

• Ease of use wins – the end-user will

only use a solution if it solves a

problem they have

• ITERATIVE PROCESS – You will never

know what a set of business user's

needs are. We are looking to

automate this task to make common

profiles.

What We Heard From AFAC (4 of 6)Common Requirements and Service Strategy

USER SEGMENTS

• 80/20 (common/specialized) looks reasonable but success will be measured on costs to support 20 percent

DEVICE ENTITLEMENT

• Segment users into roles/classifications where common services can be delivered (driven by security and common workloads)

STRATEGY

Common

Requirements/

Service Strategy

Service Delivery

Model

14

DEVICE TYPE

• No bring your own device (BYOD) but a choice from a ‘pre-qualified’ menu

PROVISIONING SERVICE

• First point of contact (Level 0) is self-service support via enterprise Web portal

• Self-provisioning for common issues, like password resets, restore files, request new applications

Service Transition

and

Implementation

Technology

Architecture and

Solutions

What We Heard from AFAC (5 of 6)Service Delivery Model

SERVICE BUNDLES

• Don’t bundle software, hardware and services together• Buy instead of lease; leverage GC buying power

SERVICE DELIVERY MODELS

STRATEGY

Common

Requirements/

Service Strategy

Service Delivery

Model

15

SERVICE DELIVERY MODELS

• Centralized service desks leveraging industry solutions with integration to federal organizations’ Tier 2 and 3

Technology

Architecture and

Solutions

Service Transition

and

Implementation

What We Heard From AFAC (6 of 6)Service Transition and Implementation

ROLL-OUT SEQUENCING

• Do it by department based on readiness: technical, cultural, technical need and leadership support

• Prerequisite for applications rationalization and ‘spring cleaning’

STRATEGY

Common

Requirements/

Service Strategy

Service Delivery

Model

16

APPLICATION TRANSITION

• Aggressive application rationalization

• Virtualization (and standardization) mandatory

• Consider going directly to the cloud

Service Transition

and Implementation

Technology

Architecture and

Solutions