An SAP landscape grows one decision at a time, and the architecture is the record of those decisions: which systems run where, how they connect, and how they are secured and recovered. At Oblytech, we set that record out before a migration or new build starts, so the project team begins from a design.
The phases below run from strategy and hosting choices through migration, security and integration to ongoing evolution.
An SAP landscape is the set of systems, environments and connections that carry the business’s processes, and the architecture is the set of decisions about how that landscape is arranged. The person who should own these decisions is the enterprise architect or CTO, working with the SAP basis lead and the security owner. The decisions are slow to reverse. Once production runs on a particular hosting model or integration pattern, changing it becomes a project of its own, so the time to settle them is before a migration or new build begins, not during one.
The main choice is where the systems run. The options are on premises, a hosted or managed arrangement, a public cloud deployment, or a hybrid in which some systems stay on site and others move. Each option changes who controls patching, backup, network access and the cost profile. The table lists the questions that tend to decide the matter. It is a decision aid rather than a recommendation, because the answer depends on data residency requirements, existing contracts and the skills in the organization.
| Factor | Largely on premises | Public cloud | Hybrid |
|---|---|---|---|
| Control over infrastructure and change windows | Full, held by internal teams | Shared, with responsibilities set by the provider’s model | Split by system, which must be documented |
| Data location and residency | Easiest to evidence | Needs region choice and contractual clarity | Needs a map of which data sits where |
| Exposure to change in the provider’s services | Low | Continuous, so it needs a monitoring routine | Mixed, with the same routine applied to the cloud part |
| Typical reason to choose it | Strict control or long-standing investment | Elastic capacity and a managed platform | A phased move with some systems that must stay put |
High availability and disaster recovery are often specified as a single phrase in a project brief, and that phrase hides three different requirements. The first is how long the business can tolerate a system being unavailable during working hours. The second is how much recent data the business can afford to lose. The third is how long a full recovery is allowed to take. Each requirement points to a different design: redundancy within a site, replication to a second location, or a documented restore process that has been rehearsed. A recovery plan that has never been exercised is an assumption, so the architecture should include a restore test on a schedule, with the results recorded.
Landscape design also decides how many non-production environments exist and what each one is for. A shared quality environment used by three projects at once produces test conflicts that look like defects. A clear purpose for development, quality and sandbox systems, with a refresh policy for copies of production data, removes much of that friction.
The integration layer is the part of the architecture that most often picks up unplanned complexity. Point-to-point connections multiply quickly, and each carries its own credentials, mappings and monitoring. An architecture decision should state whether integrations pass through a central layer, whether specific high-volume flows use direct connections, and who owns monitoring for each.
Master data is the other half of the integration question. If customers, suppliers and materials are maintained in several systems, the architecture needs a rule for which system is the source for each attribute. Without that rule, every integration turns into a reconciliation exercise.
Access design, encryption and audit logging belong in the architecture, not in a later hardening phase. The architecture should say how users authenticate, how roles are structured, how privileged access is granted and recorded, and how the landscape is watched for unusual activity. Data-protection obligations and sector regulation add requirements that vary by country and industry. The architecture should name each requirement and the control that meets it, so an auditor can trace the design back to the obligation without a separate narrative.
An architecture review produces decisions and a target picture. It does not build anything, and its output is a document a delivery team can execute. Buyers sometimes expect the review to deliver configuration or code and are disappointed. The reverse also happens: a delivery team is asked to make architecture decisions as it goes, and the result is a landscape that reflects the order of the work rather than a considered design. Keeping the two activities separate, with a sign-off between them, is one of the simplest protections available.
The S/4HANA implementation and migration page is the related pointer for migration, and the architecture should be settled before a migration plan is committed.
Its length depends on the number of systems, the number of integrations and the availability of the people who know the current landscape.
The two are often best decided together, because the release can limit which hosting options are supported and the hosting model can affect the migration method.
The options considered, the requirement each one met or failed, the owner who accepted the trade-off and the date it should be revisited.
It can be a sound end state, but it is also a transition state. A hybrid landscape needs more documentation and monitoring than either pure model, and the plan should say which systems move later.
Sizing is often treated as a hardware question, but it is really a question about how the business will use the system across the period the architecture must cover. Transaction volumes, peak concurrent users, batch runtimes and the growth in retained data all feed the sizing. A useful starting point is the set of peaks the business already experiences: a month-end close, a seasonal sales surge, a payroll run or a year-end inventory count. Each peak should be mapped to the load it creates, and the architecture should show how the landscape absorbs that load without degrading the other workloads running at the same time.
Growth needs an explicit assumption and an owner. An architecture built for today’s data volume and user count will come under strain within a few budget cycles if the business expects to add entities or sales channels. Documenting the growth assumption, and the point at which the landscape would need to change, turns a future surprise into a planned decision. Archiving and data retention policies belong in the same conversation, because they change how fast the database grows and what it costs to keep it responsive.
If the target landscape is still open, write down the systems in scope, the recovery requirements you already have and the integrations that cannot change. Bring that list to a technical conversation. Discuss your SAP landscape architecture once that list is written down.
At Oblytech, we design and implement high-performing SAP architectures that drive efficiency, security, and innovation. Whether you’re migrating to SAP S/4HANA, adopting cloud solutions, or enhancing security frameworks, our SAP architects are here to help.
SAP process automation is a workflow layer that sits on top of systems that already hold the data, so the architecture question is less about which tool to buy and more about which systems a workflow is allowed to call and who owns each step when it fails. Settle those two points before any process is modelled, because they decide whether the automation is still maintainable after its first release.
Typically the workflow engine runs on the SAP Business Technology Platform, while the systems of record stay where they are. Each call from a workflow into an S/4HANA or non-SAP system is an integration with its own credentials, error handling and change control. A workflow that reaches into five systems carries five dependencies, so list them before the first step is built.
The table compares the three places process logic usually ends up. None is right in every case.
| Placement | Where it tends to fit | What it makes harder later |
|---|---|---|
| Workflow on SAP BTP | Approvals and cross-system steps that touch several SAP and non-SAP applications | Each connected system needs its own connection, monitoring and owner |
| Logic inside the core SAP system | Steps that only touch one module and must run inside its transaction | Upgrades and custom code now carry the process logic |
| Custom middleware | Organisations that already run a mature integration layer | Process logic is spread across interfaces that few people read |
The common failure here is building the workflow first and deciding its placement afterwards. By then the workflow is usually wired into production under an undocumented service account, and moving it becomes a project. A practical order runs as follows:
The point of this order is that the placement follows from the dependencies rather than the other way round. Teams that skip it usually find the dependencies during testing, when each one is more expensive to resolve.
Where a workflow depends on a migration still in flight, the sequencing belongs with S/4HANA migration planning, and the connection work itself is covered by SAP technical services for custom integrations. Once the workflows are live, ongoing SAP support and optimisation keeps the monitoring and the authorisations current.
SAP software solutions fall into a few families, and the right one depends on what the business has to run, not on which product name is newest. In most implementations, the core system holds the finance, stock and order records, and the platform layer around it carries the custom apps, approvals and integrations. Decide which system owns the core records first, then choose the products that extend it.
Three questions separate the options in practice:
The table below compares the usual starting points. None of them is right for every business.
| Need | Typically fits | Main trade-off |
|---|---|---|
| A full ERP core for a large or multi-entity group | SAP S/4HANA | A longer programme, with data migration and process design before go-live |
| A packaged ERP for a mid-sized business with a smaller footprint | SAP Business One | Heavy custom structure is harder to carry, so process fit matters more |
| Approvals and workflows that span SAP and non-SAP systems | SAP Business Technology Platform services | Each connected system needs its own owner, credentials and monitoring |
The common mistake is buying a product family for its feature list before the record ownership is settled. Teams often build reports and workflows against copies of data that nobody is accountable for. A short fit check against the current process map usually answers the question faster than a feature comparison does.
Confirm editions, licensing and supported releases on your own instance and with the vendor, because these change over time. If the real question is whether to stay on an existing release or move, the SAP upgrade services page sets out that path. For the wider range of SAP work, see our SAP solutions overview.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.