The document summarizes a global infrastructure planning kickoff meeting. It discusses developing a common understanding of the planning process, assigning roles and responsibilities, and defining deliverables and timelines. Specific roles of IT operations and engineering managers are outlined. Architecture, design, and roadmap philosophies are also defined, describing the purpose and composition of these documents and their appropriate audiences. Finally, expectations are set for architecture, design, and roadmap deliverables, and an exercise is described to develop an initial technology roadmap.

1. July 30, 2008
Global Infrastructure Planning
Kickoff

2. Agenda
 Objectives
 Roles and Responsibilities
 Definitions
 A Sample process
 Deliverables
2

3. Today’s to do list
 Develop a common understanding of the
elements of the process
 Assign ownership to the process steps
 Develop a set of deliverables
 Define a timeline for delivery
3

4. IT Ops Manager Roles and
Responsibilities
 SLA compliance
 Queue management
 Escalation management
 Maintenance contracts
 Vendor ops relationships
 Staff management
 Staff and peer communication management
 Staff training plans: existing technologies
 Cost control
 Customer relations / IT advocate with the business
 Standards compliance
 System monitoring
 Transition from engineering
4

5. IT Engineering Manager Roles and
Responsibilities
 Architecture
 Standards
 Design
 Vendor relationships: “forward looking”
 Staff management
 Staff and peer communication management
 Vision and roadmap
 Develop management tools
 Staff training plans: new and future technologies
 Cost forecasting
 Customer requirement forecasting
 Transition to operations
5

6. Architecture Philosophy
 An plan for implementing a set of technologies within the
Sybase environment.
 It is a high level document that does not contain time
commitments, vendor or model decisions, or implementation
specifics.
 It is meant to be a lasting document that can be used to cover a
technology in the broadest manner.
 It is meant to be used by engineers and engineering managers
to ensure that designs are consistent and to guide the roadmap.
 Information in the document is sensitive, and should only be
shared with vendors in the pre-sales phase in the most general
terms. It may be shared with vendors that are engaged based
on a need to know in order to successfully execute. The
engineering manager determines the need to know.
6

7. Architecture Composition
 Scope of the Architecture – What the architecture covers
and where it applies
 Business drivers – Functional, Legacy support, External
standards, Legal / Regulatory requirements, Others
 Requirements – Describes the characteristics of the
system encompassed by the architecture.
 Functions– Describes functions without detailing model,
version numbers, or manufacturers.
 Support requirements – Processes and metrics that must
be in place to assess the implementation of the
architecture requirements.
 Interaction – How this architecture is linked to other
functional areas.
7

8. Design Philosophy
 A blueprint for implementing a particular technology within the
Sybase environment.
 It is an intermediate level document that contains vendor and
model decisions, implementation specifics, and support
requirements.
 It is meant to be a repeatable model to be used for
implementation projects.
 It is meant to be a means for documenting technology
decisions.
 It is meant to be used by engineers, implementation personnel
and managers to ensure that implementations are consistent
and to document technology selection.
 It supports project scope statements and serves as the basis for
the technical work done during a project.
 Information in the document is sensitive, and should only be
shared with vendors in the pre-sales phase in the most general
terms. It may be shared with vendors that are engaged.8

9. Roadmap Philosophy
 An time-based plan for implementing a set of technologies
within the Sybase environment (a program).
 It is an intermediate level document that contains time
commitments for specific projects or activities that will support
the ongoing architecture.
 It is meant to be a continually updated document that can be
used to drive work-effort and budgetary planning in the near
term and guide project selection in the longer term.
 It is meant to be used by engineering managers to estimate
work effort, develop a capital budget, and schedule projects for
the next 3 to 5 years.
 Visibility is by quarter, with lower fidelity being used after the first
4 to 6 quarters.
 Information in the document is very sensitive, and should not be
shared with vendors except in the most general terms. It should
be shared outside of the organization only in an interactive
conversation.9

10. Expectation setting
 Architecture = word document
 With supporting Visio / Excel
 Design = word document
 With supporting Visio / Excel
 Roadmap = Project with Description paragraphs
10

11. A Roadmap exercise
11
Microsoft Project
Document

12. Roadmap description
 Request inputs from your customers
 Plan based on skill set and level (i.e., architect, engineer,
implementer, operations)
 Costs should be in $1K increments, nothing smaller
 Plan for the unforeseen
12

13. Your deliverables
 Draft due 8/20
 MS Project roadmap with at least 4 quarters of planning
 Resource plan for 2009
 Capital plan for 2009
 Final due 9/10
 MS Project roadmap with at least 4 quarters of planning
 A first cut at years 2 and 3 without costs
 Resource plan for 2009
 Capital plan for 2009
13