EmberApplication Platform
Menu
Back to path
Draft complete7 min

Procurement, sourcing, and contract partners

Provider, service, platform, application

Use precise terms before comparing offerings or obligations.

The short answer

A provider is an organization, a service is a capability it offers, a platform is TDE's managed way of combining capabilities and responsibilities, and an application solves a specific business problem. One purchase can affect all four, but the terms are not interchangeable.

01

Name what is being bought

Four nouns prevent one large category mistake.

Procurement language shapes architecture and accountability. Calling every item a platform can hide whether TDE is buying a finished application, a managed runtime, a backend capability, or support from a provider.

The first useful question is not 'Which platform is best?' It is 'Which object and outcome are we comparing?' Precise classification makes price, service, security, data, support, and exit terms easier to evaluate.

The four-object modelEach layer answers a different procurement question.
01ProviderThe organization supplying one or more services
02ServiceThe contracted capability, plan, region, limits, and support relationship
03Ember platformTDE's governed combination of capabilities, standards, workflows, and support
04ApplicationA specific solution for named users, data, processes, and outcomes
02

Classify the service relationship

The provider is the company. The service model divides the work.

A single cloud provider can offer Software as a Service, Platform as a Service, Infrastructure as a Service, and other specialized managed capabilities. The provider name does not tell procurement which duties the provider performs for the particular service.

NIST defines the three formal cloud service models as SaaS, PaaS, and IaaS. Labels such as Backend as a Service are useful industry descriptions, but their exact responsibility split must be confirmed through architecture, service documentation, configuration, plan, and agreement.

  • SaaS: TDE uses a provider-operated application and still governs users, configuration, data, acceptable use, and integrations.
  • PaaS: TDE deploys an application on a managed runtime and still owns application code, data, access, configuration, and use.
  • IaaS: TDE receives fundamental computing resources and manages more of the operating system, runtime, software, and security design.
  • Specialized managed service: define the included capabilities and responsibilities instead of relying on the label.
Management shifts, accountability remainsMore management by the provider changes tasks. It does not eliminate TDE decisions.
01Provider manages morePhysical infrastructure, managed components, and contracted service operation
02Shared detailAvailability options, logging, recovery, support, regions, and integration behavior
03TDE retainsPurpose, data decisions, access, configuration, acceptable use, and business outcomes
03

Compare like with like

A useful comparison includes the work around the license.

Two offers with similar feature lists may produce very different obligations. Compare the specific plan, included regions, data handling, support entitlement, recovery capability, service limits, integration effort, operating skills, portability, and exit process.

Also identify the internal product around the purchase. Ember is not one vendor service. It composes several managed capabilities into a TDE pattern. Replacing one Ember provider is different from replacing Ember or replacing an application that uses Ember.

  • What exact service and plan are in scope?
  • Which application or platform capability will consume it?
  • Which duties are included, shared, excluded, or optional?
  • What people, processes, integrations, and evidence must TDE still provide?

The Ember lens

Ember is TDE's governed internal application platform, not a synonym for Render, Supabase, Vercel, or SendGrid. Current Engineering direction places the primary application interface and default runtime with Render, managed backend capabilities with Supabase, marketing and documentation surfaces primarily with Vercel, and approved optional messaging with SendGrid. Detailed implementation and operating standards are not all approved or evidenced.

Responsibility remains

A provider may operate a service, but TDE still owns why it is used, which data and users it serves, how it is configured, how applications use it, and whether the resulting solution is acceptable for its business purpose.

Apply it

Untangle a vendor comparison

A proposal says, 'Vendor A is a better platform than our current application because it includes a database and email.' Rebuild the comparison using the four-object model.

  1. 01Identify the provider organization in each option.
  2. 02List the exact services and plans being compared.
  3. 03State which Ember platform capability each service would supply or change.
  4. 04Name the application outcome, users, data, and integrations affected.
  5. 05Add three retained TDE costs or duties that the feature comparison omitted.

Check your understanding

Make the ideas usable

2 questions
01Which statement uses the terms correctly?
02What does a service label such as PaaS tell procurement?

Source trace

Reviewable by design

Content owner: Wesley Almeida
Last reviewed: 2026-08-18