Task 1: IT Operations Plan
IT Operations Plan
Course: Managing Technology Operations and Innovation - C927
Student Name: Timothy W. Curd
WGU ID: 012749196
Date: 04/15/2026
PAGE 1
,Task 1: IT Operations Plan
A. Current IT Environment Analysis
(The rows in the table will expand as you type.)
Current IT Environment
Components (including examples of service and delivery, scalability, flexibility,
interoperability, resilience, and security)
TreasureChest is a nationwide SaaS provider focused on treasury management,
serving more than 3,000 clients. Approximately 70% of its customers are small
businesses, 25% are medium-sized firms, and the remaining 5% are large
enterprises.
The company earns revenue through tiered monthly subscriptions that scale with the
SaaS Operation
number of users. While setup is standardized, larger organizations typically enroll
more users per account, resulting in higher per-account revenue. Because larger
enterprises add many more users per account, their usage spikes can create localized
demand surges that the platform must be able to scale out quickly and isolate,
ensuring performance remains consistent for the many smaller customers.
TreasureChest owns its own servers, but rents rack space in four data centers
worldwide to run its business and product apps. The network is overseen from its
main offices in London, New York, Paris, and San Diego, and the Paris site also
houses on-premises email, ERP, and messaging.
The case study doesn't say how old the hardware is, but from what we know, it's
probably past its prime – and the desktop setup isn't mentioned either, so those
machines are likely outdated too. Because the servers are owned but housed in four
separate data-centers (and the desktop fleet is likely obsolete), capacity can only be
Hardware
increased by buying and physically installing new hardware at each site. That
process is slow, costly, and constrained by the space, power and cooling available in
each rack. It also forces the company to over-provision to cover peak demand,
which wastes resources.
TreasureChest is considering migrating all its physical servers to the cloud. Since it
already runs a hybrid setup, a full cloud migration should be fairly straightforward
and end up cheaper in the long run. A cloud provider would let the company
consolidate servers and services, making scaling simple.
The case study never says which server operating systems are in use. In most shops
you’d expect a mix of Windows Server—perhaps 2003 R2, 2008 R2, 2012 or
2012 R2—and maybe a few Red Hat boxes. Any of those that are several years old
are likely out of the regular patch cycle, which raises the breach risk. Because the
inventory isn’t documented, it also hints that there’s no centralized
server-management platform. Without a single pane of glass you can’t see drift,
missed updates, or capacity bottlenecks, and you lose the flexibility to apply bulk
Operating Systems (OS)
changes (e.g., automated patching, configuration-as-code, or a coordinated
migration to the cloud). Even a lightweight inventory tool (CMDB, ServiceNow
Discovery, or open-source NetBox) would provide the visibility needed to plan and
execute those flexible, automated changes without disrupting services. Having an
undocumented mix of Windows and Linux servers limits interoperability—without
a single inventory or management system, scripts and automation can’t reliably
work across the different OSes.
Networks To hit a 99.995 % uptime goal, the network is spread across global co-locations and
monitored by two groups: the internal IT Operations team (just two network
engineers) and OnsOne Ltd, a banking-network provider based in Paris. Relying on
OnsOne for after-hours monitoring is risky—French labor rules limit their ability to
PAGE 2
, Task 1: IT Operations Plan
staff 24/7, which could push downtime beyond the target and weaken the service's
resilience. Because after-hours monitoring depends on a single external provider
that can’t guarantee 24-hour staffing, the network’s ability to bounce back from
failures is compromised, reducing overall resilience and jeopardizing the 99.995 %
uptime target.
TreasureChest has been writing its own Python and Java code since 2007. The
development teams are split between Paris and Minsk, and each office uses a
different development method—one runs Agile, the other sticks with Waterfall.
That mix creates friction; while both approaches have their pros, switching to an
all-Agile model would make it easier to scale for bigger customers because it's more
Software
flexible and growth-friendly.
Agile breaks projects into small, manageable pieces and keeps teams focused. You
can even split the work so that one group handles planning, design, and coding,
while another handles testing and validation. Having development split across two
locations with different life-cycle methods means security controls—such as code
reviews, threat modeling, and automated testing—are applied inconsistently,
increasing the risk of vulnerabilities slipping into production.
TreasureChest runs its day-to-day on a Microsoft server, so it also uses
Microsoft SQL for its database. The problem is that the app interacts with the
Database
database through multiple programming interfaces. That makes coordinated
migrations harder, increases the risk of duplicate data, and slows down the database,
which can hurt customer service quality. To keep the business running smoothly,
TreasureChest needs to streamline those interfaces and improve interoperability.
PAGE 3
IT Operations Plan
Course: Managing Technology Operations and Innovation - C927
Student Name: Timothy W. Curd
WGU ID: 012749196
Date: 04/15/2026
PAGE 1
,Task 1: IT Operations Plan
A. Current IT Environment Analysis
(The rows in the table will expand as you type.)
Current IT Environment
Components (including examples of service and delivery, scalability, flexibility,
interoperability, resilience, and security)
TreasureChest is a nationwide SaaS provider focused on treasury management,
serving more than 3,000 clients. Approximately 70% of its customers are small
businesses, 25% are medium-sized firms, and the remaining 5% are large
enterprises.
The company earns revenue through tiered monthly subscriptions that scale with the
SaaS Operation
number of users. While setup is standardized, larger organizations typically enroll
more users per account, resulting in higher per-account revenue. Because larger
enterprises add many more users per account, their usage spikes can create localized
demand surges that the platform must be able to scale out quickly and isolate,
ensuring performance remains consistent for the many smaller customers.
TreasureChest owns its own servers, but rents rack space in four data centers
worldwide to run its business and product apps. The network is overseen from its
main offices in London, New York, Paris, and San Diego, and the Paris site also
houses on-premises email, ERP, and messaging.
The case study doesn't say how old the hardware is, but from what we know, it's
probably past its prime – and the desktop setup isn't mentioned either, so those
machines are likely outdated too. Because the servers are owned but housed in four
separate data-centers (and the desktop fleet is likely obsolete), capacity can only be
Hardware
increased by buying and physically installing new hardware at each site. That
process is slow, costly, and constrained by the space, power and cooling available in
each rack. It also forces the company to over-provision to cover peak demand,
which wastes resources.
TreasureChest is considering migrating all its physical servers to the cloud. Since it
already runs a hybrid setup, a full cloud migration should be fairly straightforward
and end up cheaper in the long run. A cloud provider would let the company
consolidate servers and services, making scaling simple.
The case study never says which server operating systems are in use. In most shops
you’d expect a mix of Windows Server—perhaps 2003 R2, 2008 R2, 2012 or
2012 R2—and maybe a few Red Hat boxes. Any of those that are several years old
are likely out of the regular patch cycle, which raises the breach risk. Because the
inventory isn’t documented, it also hints that there’s no centralized
server-management platform. Without a single pane of glass you can’t see drift,
missed updates, or capacity bottlenecks, and you lose the flexibility to apply bulk
Operating Systems (OS)
changes (e.g., automated patching, configuration-as-code, or a coordinated
migration to the cloud). Even a lightweight inventory tool (CMDB, ServiceNow
Discovery, or open-source NetBox) would provide the visibility needed to plan and
execute those flexible, automated changes without disrupting services. Having an
undocumented mix of Windows and Linux servers limits interoperability—without
a single inventory or management system, scripts and automation can’t reliably
work across the different OSes.
Networks To hit a 99.995 % uptime goal, the network is spread across global co-locations and
monitored by two groups: the internal IT Operations team (just two network
engineers) and OnsOne Ltd, a banking-network provider based in Paris. Relying on
OnsOne for after-hours monitoring is risky—French labor rules limit their ability to
PAGE 2
, Task 1: IT Operations Plan
staff 24/7, which could push downtime beyond the target and weaken the service's
resilience. Because after-hours monitoring depends on a single external provider
that can’t guarantee 24-hour staffing, the network’s ability to bounce back from
failures is compromised, reducing overall resilience and jeopardizing the 99.995 %
uptime target.
TreasureChest has been writing its own Python and Java code since 2007. The
development teams are split between Paris and Minsk, and each office uses a
different development method—one runs Agile, the other sticks with Waterfall.
That mix creates friction; while both approaches have their pros, switching to an
all-Agile model would make it easier to scale for bigger customers because it's more
Software
flexible and growth-friendly.
Agile breaks projects into small, manageable pieces and keeps teams focused. You
can even split the work so that one group handles planning, design, and coding,
while another handles testing and validation. Having development split across two
locations with different life-cycle methods means security controls—such as code
reviews, threat modeling, and automated testing—are applied inconsistently,
increasing the risk of vulnerabilities slipping into production.
TreasureChest runs its day-to-day on a Microsoft server, so it also uses
Microsoft SQL for its database. The problem is that the app interacts with the
Database
database through multiple programming interfaces. That makes coordinated
migrations harder, increases the risk of duplicate data, and slows down the database,
which can hurt customer service quality. To keep the business running smoothly,
TreasureChest needs to streamline those interfaces and improve interoperability.
PAGE 3
