The Workplace Technology Devices session on May 26, 2014, addressed the architecture framework and provided updates on the consultation roadmap and service desk options. Participants discussed user segmentation focusing on mobility and security, emphasizing common processes in service delivery, while highlighting challenges like application integration and legacy systems. The meeting concluded with plans for further procurement activities in the Workplace Technology Devices initiative.

1. Workplace Technology Devices: Session 5
1
Architecture Framework Advisory Committee Meeting
May 26, 2014

2. Agenda
TIME TOPICS PRESENTERS
9:00 – 9:15
Opening Remarks
Benoît Long, Chair
Wade Daley, Vice-Chair
9:15 – 9:45
Presentation and
Recap
Natalie McGee
Senior Director,
Distributed Computing
Transformation Program
2
Transformation Program
9:45 – 11:30 Discussion Period
Moderator: Chair
Participants: All
11:30 – 12:00
Closing Remarks Benoît Long, Chair

3. 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

4. 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
Model
Segmentation
ModelPilot
Functional
Direction
• Meetings
• Demos
• Written
Submissions
Formal
Industry
Engage-
ment
March 14,
April 17, and
today.

5. 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/integrator
across multiple locations
• Integrator with multiple
levels
Level 1 Level 1 Level 1 Level 1
• Multiple toolsets/processes
• Multiple service desk
contractors/locations
Level 1 Level 1 Level 1 Level 1
SD Tool SD Tool SD Tool SD Tool
#3

6. 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).

7. 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 distributed
across 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 sets
are 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?

8. 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?

9. 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.

10. Reference
10

11. 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
3
Legacy 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

12. 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

13. 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.

14. 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

15. 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

16. 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