Skip to main content

Our Strategy

To empower IT to deliver strategic solutions for our customer’s needs, we will follow a cloud first methodology for all IT services and solution.

We will prioritize Software-as-a-Service (SaaS) as our cloud model of choice whenever possible.

While we will enable access to Microsoft Azure, Amazon Web Services, and Google Cloud, we will utilize a single cloud provider for most IT solutions to reduce duplication of cloud services.

We will simplify and optimize cost for internally-managed solutions by using Platform-as-a-Service (PaaS) offerings when possible and use Infrastructure-as-a-Service (IaaS) only when required.

cloud-2104829_1920

While we will prioritize cloud solutions over traditional infrastructure, “cloud first” does not mean “cloud always”. Current requirements or constraints will dictate when the cloud makes sense. Our goal is to align with strategic objectives but not introduce unnecessary risk. We will limit on-campus infrastructure to only what’s absolutely necessary based on very specific use cases.

UCF IT will follow a SaaS first methodology and strive to run as high up in the “cloud stack” as possible.

Software-as-a-Service (SaaS) will be the cloud model of choice whenever possible. We will seek to streamline all custom-designed solutions using our trusted cloud provider Platform-as-a-Service (PaaS) offerings where available and Infrastructure-as-a-Service (IaaS) when needed.

This strategy will enable us to make the most efficient use of UCF IT resources by reducing complex solutions, shifting more risk to our vendors, and taking advantage of their expertise and specialization. As a result, we can offer a better solution to our customers.

Why We are Saas First

Most SaaS solutions are sold through a subscription model where the total cost of ownership is shared among many customers allowing for economies of scale. While subscriptions may appear expensive at first glance, it’s worth considering what’s included. Besides access to the software itself, on-going maintenance, timely updates, and most importantly, customer support are added benefits which can be very expensive internal IT costs.  Finally, there are no large, upfront investments required for hardware and software installation.

The process to fully implement traditional on-premises software typically involves planning, design, review, testing, installation, and configuration that will span several months, if not longer. Because SaaS solutions are already installed and accessible over an internet connection, many of these steps can be reduced or even eliminated.

Most SaaS solutions are delivered through flexible cloud environments that scale as your needs change. And as you scale with a SaaS vendor, there’s no need to invest in server capacity and software licenses. Simply adjusting your subscription gives you the benefit of predictable costs both for the software and to some extent, the administration. This allows for more accurate budgeting, especially when compared to the costs of internal IT to manage upgrades and address issues for an owned instance.

With conventional software, updates and patches require enormous amounts of time and money. Even worse, version discrepancies between members of your workforce can lead to compatibility issues and wasted time. SaaS providers manage software updates and upgrades for you, ensuring that you’ll always have the latest version.

With SaaS, the complexity of securing and maintaining the underlying IT infrastructure is all handled by the vendor. This usually includes automatic data backups and built-in redundancies to ensure high availability. A SaaS provider may also be a good fit for data with complex regulatory requirements too costly to secure on your own.

SaaS vendors will typically commit to a “service level agreement” which guarantees availability and uptime of 99% or more. Missing these expectations will result in financial consequences for the vendor in the form of fees or customer credits.

Because the software is accessible via familiar web browsers, SaaS applications tend to have lower learning curves and higher adoption rates. This can be especially significant given the high cost of on-premises software development and implementation compared to the low cost of entry for SaaS.

Because SaaS solutions are web-based, your application can be accessed easily from any location with internet capabilities. Many solutions also offer mobile versions of their applications for even more flexibility.

How we will follow our strategy

We want to identify reasons for not using the cloud rather than why we should. We will work with our customers to find the right solution using the knowledge gained from previous UCF IT projects and peer institution experience from around the country with similar strategies.

To align new services and solutions with our cloud first strategy, prioritize Software-as-a-Service, and reduce duplicative offerings whenever possible, we have developed the Service Strategy Review. This process contains four categories of general criteria which are assessed during the technical requirements phase of new project planning. 

Service Strategy Review Process

Below is a list of the criteria we use within each of the four categories: 

  • Is a similar solution already in use and if so, is there a compelling reason for duplicating this offering?
  • Does this solution offer a Software-as-a-Service (SaaS) delivery model?
  • Will this solution pose a high impact to the university if it were unavailable and if so, are adequate replication and disaster recovery mechanisms in place?
  • Is the data subject to any additional security, privacy, audit, or any other compliance requirements?
  • Are the features provided in the proposed solution sufficient to address the needs of the users? If not, are the gaps significant enough where a suitable work-around could not be developed?
  • Are specific skills or technologies needed to implement and/or maintain this solution that our staff currently does not support?
  • Is there a need for third-party capabilities and if so, are their terms adequate?
  • Will the solution sufficiently integrate with campus identify and access management systems?
  • Is there any effect to ‘downstream’ dependencies such as existing reports, dashboards, and data feeds that may have specific formats, transmission, or data structure requirements?
  • What existing UCF systems, if any, will the solution need to connect to or integrate with and how will those connections occur?
  • Are there any dedicated network connectivity requirements that UCF IT would be unable to meet?
  • Will this solution be responsible for, a dependence in, or in any way support the physical safety and security of the campus or control sensitive physical plant infrastructure?
  • Will there be a significant increase in latency or bandwidth due to required connectivity with university-managed infrastructure or end user workstations?
  • Will there be a measurable negative impact to existing business processes if this solution is hosted in the cloud?
  • Is specific hardware equipment or physical infrastructure necessary for the solution?
  • Is there a compliance requirement that the data involved reside on university managed/owned infrastructure?
  • If an existing system is being retired or migrated, will there be a significant value loss of existing depreciating assets or related physical infrastructure?
  • Are there specific IOPS requirements that cannot be sufficiently provisioned in the cloud?
  • Have all business-related SaaS considerations been sufficiently addressed by the vendor to meet customers expectations?
  • Is it possible to monitor the general health of the solution, either in real-time or historically? Is proactive alerting supplied, and if so, can it be adequately integrated into existing IT operations management tools or process if needed?
  • Is there a need to delay version updates?
  • What capabilities exist to protect the organization’s data?
  • Are the provided SLAs suitable for this solution’s use case and needs? Are the financial penalties for missing an SLA target sufficient to offset some amount of impact to the business?
  • Is there any prohibitive licensing restrictions or terms that may exclude the use of licenses that the business already owns?
  • For third-party solutions, will the vendor provide support if a Platform-as-a-Service (PaaS) offering is used to deliver some functionality?
  • Can the application support load balancing and/or horizontal scaling?
  • If a database is required, is there a requirement for a stand-alone database server or can the database reside within a shared cluster?
  • Are there any granular firewall URL filtering requirements?