Get in Touch
About Us Insights Newsroom Gallery Why AtomicNorth Get in Touch

Platform and
integration

Oracle Cloud Infrastructure, WebLogic, Integration Cloud and APEX: the platform beneath the applications and the interfaces between them and everything else you run.

Every interface fails eventually. We build the ones that fail loudly and recover cleanly.

PlatformOCI and WebLogic

Landing zones, migration, middleware administration, patching and environment builds.

IntegrationOIC, REST, files

Idempotent, replayable and reconciled, because the interface will fail at some point.

BuildAPEX

Production applications where a full stack would be over-engineering.

ReleaseEnvironment discipline

Dev, test and production that actually match, with a documented promotion path.

What we build and run

The layer under the applications

This is the work that decides whether an Oracle estate is dependable. It is also the work that gets cut first, and then explains most of the incidents.

OCI landing zone and migration

Compartments, networking, identity, tagging, budgets and guardrails established before workloads land, then lift, shift or rebuild as each case warrants.

Cost controls go in at the start. Retrofitting tagging and budgets across a live tenancy is a project nobody funds.

A tenancy someone can still understand in two years.

WebLogic and Fusion Middleware

Domain administration, clustering, patching, certificate lifecycle and tuning for EBS and custom applications.

Certificates and their expiry dates are inventoried and alerted, because that is the outage everyone has had at least once.

Middleware that is patched, clustered and monitored.

Oracle Integration Cloud (OIC)

Integration flows between Oracle applications and third-party systems, with mapping, error handling, retry policy and reconciliation.

Every flow is idempotent and replayable by design, so recovery is a rerun rather than a reconciliation exercise.

Interfaces you can replay instead of repair.

APEX development

Operational applications on the database you already license: approval workflows, data capture, reference data management, small portals.

Used where APEX is genuinely the right tool, which is more often than most architecture reviews assume, and not where it is not.

A working application in weeks, on infrastructure you already own.

Environments and release management

Cloning, refresh cycles, configuration parity, and a documented promotion path from development to production.

Environment drift is treated as a defect with a cause, not a fact of life to be worked around.

A test result that means something in production.

Identity and access

Single sign-on, federation, privileged access and role design across the Oracle estate, integrated with your existing identity provider.

Access reviews produce evidence in a form an auditor accepts on the first pass.

Access that is provable, not just configured.

Technology offerings

The platform, service by service

Each page covers one part of the Oracle technology layer: integration, extension, middleware and the database underneath.

Oracle SOA Suite

BPEL, Service Bus and composites, supported or moved to OIC.

Read the page →

Oracle DBA

Patching, tuning, RAC, Data Guard and recovery testing.

Read the page →

Oracle APEX

Low-code applications and Forms modernisation on your database.

Read the page →

Oracle OIC

Integrations with tracking, replay and reconciliation built in.

Read the page →

Oracle VBCS

Fusion extensions and portals built outside the core.

Read the page →

How platform and integration work runs

StepOneMap the flows

Every integration in and out of the Oracle estate documented: source, target, schedule, volume, failure mode and who notices when it breaks.

The flows nobody can name are the ones that cause the incidents. Finding them is the point of this step.

You receive:

An interface map

Each flow with its contract, its owner, its recovery procedure and its criticality, plus the list of flows with no owner at all.

This document usually changes the priority order the client arrived with.

StepTwoBuild the platform

Landing zone, networking, identity, middleware and environments built with guardrails, tagging and budgets from the first resource.

Environments are built from configuration rather than by hand, so the second one matches the first.

You receive:

A documented platform

Architecture as built, promotion path, patch calendar, cost model and the runbooks for the operations your team will perform.

Including the boring ones: certificate renewal, cloning, and how to restore a domain.

StepThreeWire the integrations

Flows built or rebuilt against the mapped contracts, with retry, dead-letter handling, alerting and end-of-day reconciliation.

Failure paths are tested deliberately. An integration that has never been observed failing has an unknown failure mode.

You receive:

Interfaces with a recovery path

Each flow replayable from a known point, reconciliation reports at cycle end, and alerts that name the business impact rather than the stack trace.

The on-call engineer should know what broke for whom before opening a console.

StepFourOperate and release

Steady state: patching, monitoring, capacity, cost review, and a release cadence for the platform and the integrations on it.

Platform work is never finished. It either has a cadence or it has an incident backlog.

You receive:

A release and patch cadence

Monthly patch position, quarterly cost and capacity review, release notes for every promotion, and a standing environment refresh schedule.

Deferred patches are recorded as accepted risk with a named owner.

01
Coverage

Layer by layer

Technology Offerings coverage
LayerTechnologyScopeModel
Cloud platform OCI: compute, network, storage, IAMLanding zone, migration, guardrails, cost and capacity managementProject or managed
Middleware WebLogic, Fusion Middleware, HTTP ServerDomain administration, patching, certificates, clustering, tuningManaged
Integration Oracle Integration Cloud, REST, SOAP, file transferFlow build, error handling, replay, reconciliation, monitoringProject or managed
Application build APEX, ORDSOperational applications, reference data tools, internal portalsProject
Environments Dev, test, UAT, productionCloning, refresh, configuration parity, promotion pathManaged
Identity SSO, federation, privileged accessRole design, access review evidence, integration with your IdPProject or managed
Integration rules

Every interface fails eventually

Integration design is mostly a question of what happens on the bad day. A flow that works when everything is up is not an achievement; the achievement is a flow whose failure is visible in minutes and recoverable without a data-fixing script.

So four rules apply to everything we build, and they are the first things we check when reviewing what already exists.

Ask for an interface review
  • IdempotentReplaying a message twice produces the same result as once. Without this, recovery requires human judgement about what already landed.
  • ReplayableEvery message is retained long enough to be resent from a known point, so recovery is a rerun rather than a reconstruction.
  • ReconciledCounts and totals are compared at cycle end and the difference is reported, so a silent partial failure cannot survive until month end.
  • Alerted in business termsThe alert names the impact and the affected process, not the exception class. The engineer should know the stakes before opening a console.

These rules are also the review criteria we apply to inherited integrations.

Questions we get asked

Before a platform decision

Can OCI run alongside our Azure or AWS estate?

Yes, and for most clients that is the actual end state rather than a transitional one. Oracle workloads sit well on OCI for licensing and performance reasons; the rest of the estate usually has a good reason to be where it already is. What matters is that identity, network and monitoring are designed across both rather than twice.

Is APEX a serious option for production applications?

For operational applications over data that already lives in the Oracle database, yes, and it is frequently the proportionate answer. It runs on a database you already license, it inherits your security model, and a working application takes weeks. It is the wrong choice for a public-facing product, a mobile-first experience, or anything needing a design system of its own, and we will say so.

What happens when an integration fails overnight?

The alert fires with the business impact named, the flow stops rather than half-processing, and the on-call engineer replays it from the last known-good point. The end-of-cycle reconciliation then confirms nothing was lost. If a flow cannot do those three things, it is on the remediation list.

Do you migrate WebLogic to OCI or leave it where it is?

It depends on licensing, latency to the database and what the application is doing. Lifting a WebLogic domain to OCI is straightforward; the value is usually in the licence position and the consolidation of environments, so that is where the assessment starts rather than in the technical migration itself.

How are releases handled across environments?

A documented promotion path with the same artefact moving through each environment, release notes per promotion, and configuration parity checked rather than assumed. Where environments currently differ, closing that gap is usually the first piece of work, because until it closes no test result is trustworthy.

A platform thatholds up.

Start with an interface review or a platform assessment. Both are short, and both produce a document your own team can act on without us.

Get in touch Book a scoping call