Built for R&D / L3 Support ┬╖ Protected by IS ┬╖ Services on demand

Tell us what you need. Polaris does the IT translation.

This page is a simple guide for R&D / L3 Support. You describe the workload, project or existing lab environment in normal words. The planner then suggests the right protection model, the useful services and the roles that help you ΓÇö so you can keep working while the environment stays InfoSec compliant.

Start with my workload Show the protection idea

What this page does for you

1
No IT language neededAnswer practical questions: What exists? What must run? What must not change?
2
Keep working systems stableExisting Hypervisors, hardware, vendor systems and lab setups can stay in Layer 0-1.
3
Use services instead of building everythingLayer 3 offers things like backup, VM capacity, storage, monitoring and ML compute.
4
One local entry pointLocal IS helps collect the local facts and connects R&D / L3 Support with the right teams.
01 ┬╖ Start here

This is a guided conversation, not an infrastructure exam.

R&D / L3 Support should not have to decide which firewall, network zone or platform pattern is correct. You explain the need. Local IS, Architects, IS and the Hosting Provider turn that need into a safe and supportable setup.

Use this planner when you need a place to run a new workload, or when you already have a working environment that should be connected to Polaris without being rebuilt.

The planner starts with simple questions: Is this new or existing? Does it need ABB connectivity? Is it legacy or end-of-life? Can it be patched? Can global ABB tools such as Splunk, Zscaler or MDE be installed? Do you need services such as backup, storage or VM capacity?

The result is a clear recommendation: which protection model fits, what R&D / L3 Support can do, what should not be done, which Layer 3 services are possible, and who is responsible for which part.

R&D / L3 stays focused

Work on the project, test stand, VM, Hypervisor or support task ΓÇö not on network design.

IS handles the protection

The security boundary, access paths and InfoSec evidence are built around the workload.

Services are reusable

Layer 3 turns common needs such as backup, storage and VM capacity into standard services.

Built for You architecture overview
Concept image: R&D / L3 describes the need, Polaris adds protection and servicesClick to enlarge
02 ┬╖ The three layers in plain language

Your work stays inside. Protection and services are added around it.

The easiest way to understand Polaris is this: Layer 0-1 is where your work happens. Layer 2 is the protection around that work. Layer 3 is the service shelf you can use when you need backup, storage, VMs, monitoring or extra capacity.

Layer 0-1 ┬╖ Your work area

This is where your systems and development work live.

Layer 0-1 contains the real work: project systems, lab hardware, test stands, Hypervisors, VMs, simulations, vendor tools, old systems, certified versions and local development environments. If something already works and should not be rebuilt, it can usually stay here.

  • You provide: what the system is for, who uses it, what must run and what must not change.
  • You decide: which workload, data, tools and services are needed for the project or support task.
  • Polaris adds: protection and services without taking ownership of your R&D / L3 technical work.
Layer 0-1 Shared Platform and Workload Basis
Layer 0-1: your actual workload and local project realityZoom
Layer 2 ┬╖ Protection by IS

Layer 2 is the managed security shield around your workload.

Layer 2 is the outer protection layer. It lets R&D / L3 Support keep working in Layer 0-1 while IS controls the network boundary, access paths, firewalling, monitoring and InfoSec evidence around it.

The simple idea: You work inside your environment. IS builds the secure boundary around it. That boundary can protect even difficult systems, such as legacy, end-of-life or unpatchable systems, without forcing R&D / L3 Support to become network-security experts.
  • No direct corporate connection by default: connections are only added through approved and controlled paths.
  • Good for difficult systems: if patches or security agents would break the workload, the control can be placed outside the workload.
  • InfoSec ready: the security argument is built into the design instead of being solved manually for every project.
Layer 2 Security Shield and Workload Zone
Layer 2: the controlled security and network boundary around the workloadZoom
Layer 3 ┬╖ Services for R&D / L3 Support

Layer 3 is the service shelf you can consume.

Layer 3 provides useful building blocks when R&D / L3 Support needs more than the local project currently has. Examples: backup, restore, storage, Hypervisor or VM capacity, ML/analysis machines, monitoring, templates or secure access components.

Important wording: L3 means the Operations support unit. Layer 3 means the service layer. In this planner, R&D and L3 Support are treated as one combined workload/customer function that can consume Layer 3 services when the selected protection model allows it.
Backup & RestoreStandard backup and a clear restore path for project systems and data.
Hypervisor / VM CapacityExtra compute when local hardware, CPU, RAM or lab capacity is not enough.
ML / Analysis VMTemporary machines for machine learning, simulation or heavy analysis.
Project StorageMore space for test data, builds, artifacts and temporary datasets.
Logging & MonitoringVisibility and health checks without every project building its own tooling.
Secure AccessJump Server, VPN or managed supplier/admin access when the framework allows it.
Layer 3 Development Activities as a Service
Layer 3: service shelf for R&D / L3 SupportZoom
03 ┬╖ Two simple ways to start

You can start new ΓÇö or connect what already exists.

There are two common situations. Path A is for a new workload. Path B is for an existing lab, Hypervisor, hardware setup or vendor system that should stay in Layer 0-1. In both cases, the same simple questions help IS and Architects build the right Layer 2 protection and the right Layer 3 service options.

Path A ┬╖ New workload

Start a new project without designing the infrastructure yourself.

Use this when you need a new VM, test zone, ML environment, storage, backup, monitoring or a protected development area.

01Say what you want to achieve. What must run, who needs access, how much capacity is needed and when?
02Answer simple questions. Does it need ABB connectivity? Is Air-Gap required? Can it be patched? Can ABB tools be installed?
03Architects translate the wish. They turn the request into an ABB-compliant setup that can actually be implemented.
04IS designs the protection. Layer 2 is defined: segmentation, firewalling, access, monitoring and InfoSec evidence.
05Hosting Provider prepares services. Layer 3 services such as backup, storage, VM or ML capacity are offered where allowed.
06R&D / L3 Support works. You use the approved setup and focus on the workload, development and support.
Path B ┬╖ Existing environment

Keep what already works and connect it to Polaris safely.

Use this when R&D / L3 Support already has a working Hypervisor, lab system, hardware setup, vendor system or project environment. The goal is not to rebuild it. The goal is to protect it and make it supportable.

01Keep the working environment. The existing Hypervisor, hardware, test stand or vendor system stays in Layer 0-1.
02Local IS collects the local facts. Users, IPs, dependencies, data flows, patching limits, vendor needs and support windows are documented.
03The same questions are answered. Is it legacy/EOL? Can it be patched? Can Splunk, Zscaler or MDE be installed? Does it need ABB connectivity?
04Architects turn facts into a pattern. They make the local situation fit ABB standards and prepare the InfoSec argument.
05IS wraps Layer 2 around it. The existing environment gets segmentation, firewalling, Jump Server/VPN, monitoring and compensating controls.
06Layer 3 is added only if useful and allowed. Services such as backup, storage or VM capacity are optional. Air-Gapped systems receive no connected Layer 3 services.
00

Start with need

New workload or existing environment: describe what you want to achieve.

01

Check connection

Does it need ABB connectivity, a protected zone or no network at all?

02

Check limits

Legacy, EOL, patching limits, Splunk, Zscaler, MDE or vendor constraints?

03

Pick protection

Air-Gapped, Fully Segregated, Segregated or Segregated-Integrated.

04

Add services

Layer 3 services are added where useful and allowed.

05

Work safely

R&D / L3 Support uses the approved setup and keeps working.

04 ┬╖ Who helps with what

R&D / L3 Support says what is needed. Polaris roles make it happen.

The roles are simple: R&D / L3 Support describes the workload and validates that it works. Local IS knows the local site reality. Architects translate the wish into an ABB-compliant design. IS owns the Layer 2 protection. Hosting Provider and Common Services provide the Layer 3 services that can be consumed where allowed.

From ΓÇ£who builds what?ΓÇ¥ to a clear service model.

R&D / L3 Support should be able to ask for an outcome: a protected lab, more capacity, a VM, backup, storage, monitoring or a safe way to onboard an existing system. Local IS collects the local facts. Architects, IS and the service providers then turn that request into a usable and compliant solution.

R&D/L3
R&D / L3 Support is the customerOne combined function for workload need, development reality, support need, validation and service consumption.
IS
IS owns the protection layerLayer 2 covers segmentation, access paths, firewalling, monitoring and InfoSec arguments.
HP
Hosting Provider provides servicesLayer 3 services such as backup, storage, Hypervisor/VM capacity and ML capacity are provided for consumption.
R&D / L3

Customer and workload owner.

Explains what must run, what support is needed, what must not change, which data is used and which services would help. Validates that the delivered setup supports real work. L3 here means the Operations support unit, not Layer 3.

Local IS

Local guide and front door.

Knows the site, local hardware, Hypervisors, users, dependencies, support windows and practical constraints. Helps all delivery roles understand the real environment.

ARC

Translates wishes into ABB design.

Turns the R&D / L3 Support request into an architecture that follows ABB standards, patterns and guardrails.

IS

Builds and owns Layer 2.

Provides the protection around the workload: network separation, firewalling, secure access, monitoring points and InfoSec evidence.

HP

Provides Layer 3 services.

Provides consumable services such as Hypervisor/VM capacity, storage, backup, restore, templates and platform capacity.

CS

Provides shared building blocks.

Provides common services such as identity, tooling integrations, monitoring integration, automation and shared platform capabilities.

1. R&D / L3 Support asksDescribe the desired outcome, not the firewall design.
2. Local IS captures factsDocument local systems, constraints, users and dependencies.
3. Architects translateConvert the wish into an ABB-compliant pattern.
4. IS protectsDefine the Layer 2 shield and InfoSec evidence.
5. HP / CS provide servicesExpose Layer 3 services where the model allows them.
Naming note: Local IS replaces the old ΓÇ£Site / Workload AdministratorΓÇ¥ wording. In compact tables it may appear as LIS. Important: R&D / L3 Support is one combined workload/customer function. L3 means the support unit; Layer 3 means the service layer.
Polaris roles and collaboration overview with Local IS naming
Role view: Local IS is the local front door and R&D / L3 Support is the combined customer functionClick to enlarge
05 ┬╖ Guided questions

Answer simple questions. The tool suggests the protection model.

You do not have to know the architecture name. Start with what you need. If the workload is legacy, end-of-life, unpatchable or cannot run ABB tools such as Splunk, Zscaler or MDE, the tool points to Fully Segregated. If no network is allowed, it points to Air-Gapped. Modern workloads become Segregated or Segregated-Integrated.

Need to change your answer?Restart stays visible so a miss-click does not slow you down.
Step 0 ┬╖ Start from zero
Path: no selection yet

Selected framework

What this means
  • You get a recommended setup in plain language.
  • IS owns the protection around the workload.
  • Layer 3 services are added only where useful and allowed.
Selected architecture
Click to enlarge

What R&D / L3 Support can do

    What R&D / L3 Support should not do

      What the delivery teams handle

        Layer 3 services you can request

        Select the useful services. Hosting Provider and Common Services provide the building blocks; R&D / L3 Support consumes them. The summary updates automatically and can be copied into a ticket or handover message.

        Copy-ready handover text

        Tip: Add project name, owner, target date, data classification, expected lifetime, CPU/RAM/GPU/storage needs and any vendor or patching constraints before submitting.

        06 ┬╖ Responsibilities at the end

        Responsibility Explorer: choose a role or a scenario.

        Most users only need the decision result and the handover summary. If you want to know who does what, use this explorer. You can either select a role, such as R&D / L3 Support, Local IS or Architects, or select a scenario, such as new workload, existing environment, Fully Segregated or Air-Gapped.

        How to read it: R = does the work, A = owns the final outcome, S = supports, C = gives input before decisions, I = is kept informed. R&D / L3 Support is one combined customer function. Local IS may appear as LIS. L3 means the support unit; Layer 3 means the service layer.
        Choose a role:
        Detailed RASCI Matrix with Local IS naming
        Detailed matrix image: Local IS / LIS naming and combined R&D / L3 Support customer functionClick to enlarge
        Standalone HTML ┬╖ All images are embedded ┬╖ No external libraries or online resources required.