The Atria Service Model

Service Fundamentals

Service Plans

Atria Service Plans provide Product Options within Atria. A service plan can be assigned a SKU which can then be translated directly into a billable item.

When designing services, service plans can apply at both customer and user level.

Each service plan can have any number of Properties defined. Each property can contain user editable information (i.e. parameters that are supplied at time of provisioning), or defined configuration which is only editable by Atria administrators – the configuration which makes one plan differ from another.

For example, an Backup Service could have multiple attributes – we would define these as plan properties.

Once the schema is configured, you can then define as many plans asyou like – these are created in the system, and are then used when you provision the service to the customer.

Well designed plans ensure that:

1. 1. Your marketing messages and price points translate into the services you provision
   2. It’s easy for services to be provisioned to customers and the right information is always passed.
   3. The parameters included in the plan are instantly available for your automation.

When designing plans, Atria allows you to define validation controls which ensure data integrity, out of the box you can create drop down lists, apply regular expressions, or define data types.

Overriding Attributes

By default you will not need to change plan configuration, but if needed, you can go in and override the plan settings on a customer by customer, or reseller basis.

In our example, imagine that a VIP customer has threatened to leave, they have a competing offer which has more included storage.To keep the customer buying your service, you can just go in and override the storage setting for that one customer. All provisioning stays the same, you don’t need to create a special plan and simplicity is maintained.

Customer and User Service Properties

Aside from plans, Properties can be assigned to the Service at both the customer and the user level.

Where the property is configured determines it’s scope and where it can be changed.In most cases, properties can be overridden down the hierarchy.i.e. a service level setting, could be overridden for a particular reseller or customer.

In our Backup Service example, At the service level, we have the one off config needed for our provisioning process, and at a Customer level, we need to capture more information at provisioning time.

Now, when it comes to provisioning, the service desk or even the customer, is able to pick a plan and then enter the required details.  This then sends off the provisioning request to complete the process.

Storage of Secrets

When integrating systems, there is often a need for secrets to be stored. Usually, the secret is for accessing an API – it could be a token or a password. Atria components have access to a secret store – this can be accessed via PowerShell. Secrets are encrypted then stored.

In our example above, the property for the APITokenSecret would supply the name of the secret to be retrieved. As part of the provisioning process, the secret can be easily retrieved and used without needing to expose the secret to any user.

Provisioning Logic

We have so far discussed how Atria can capture service requests in a standardised and simple format.

The outcome of all Provisioning is a provisioning request, In message form, this contains all of the information needed to complete a provisioning process. The message is passed to a queue and routed to a provisioning engine.

Each provisioning request packages all the information you might need to perform the provisioning task.

The request is a simple data structure – it includes

• Customer level details – e.g. the Customer Entity in Atria
• User level details – if applicable (i.e. a user level service), all of the user details are also contained within the request.
• All the Service properties at all levels, and with any overridden settings applied
• The selected Plan and plan properties

As a cooking metaphor,

Ingredients = Request

Recipe = Provisioning Process

Each Provisioning rule is a step in the recipe that uses ingredients

Provisioning Process

Provisioning occurs in three parts:

• Pre-Provisioning – where the request can be further enriched with data
• Provisioning – where the provisioning is actioned
• Post-Provisioning – where results from the provisioning can be stored

Due to the distributed nature and depending on how Atria is configured, Provisioning may take place in a different network or system, Pre and Post provisioning usually occur within the main Atria platform.

Each provisioning process is made up of a set of provisioning rules, each rule defines a provisioning action to run and a condition which determines whether or not it should run.

Provisioning actions are the building blocks of provisioning processes.

Provisioning Rules are soft – they are defined in the database and compiled into a program when the provisioning engine starts.This means that compiled performance is gained, but the flexibility to change, adapt and enhance is maintained.

Custom Actions

It is also possible to create custom Actions using .NET.  You can use this to encapsulate any complexity and provide a simple interface for other Atria customers or operations teams to use.

For example, a Create Backup Account action, could take the parameters from our imaginary Backup Service, and setup the required storage and account for the new customer.

Provisioning Events

Within core provisioning processes, before and after placeholders exist.These allow customization of existing services.So for example, if you wanted to perform additional processing after a default out of the box Atria service.You can add your logic and this will be maintained across upgrades.

Batch Processing

When integrating systems, it is often the case that recurring scheduled tasks are needed to keep systems in sync, to perform maintenance tasks, or to perform processes such as billing or email notifications.

Atria has an inbuilt scheduling system which can be used to execute any process.

Standardized Logging

An easy to use five level logging system is available and can be used by custom Job Runners (C# code) or can be used through the standard PowerShell Job Runner.

This means that your senior engineers can standardise batch processing and logging across systems and provide error code specific direction to more junior engineers to resolve issues.

Building custom pages

Provisioned Services may require associated administrative functions.

As an example, our Microsoft Online service procures and provisions Microsoft licenses to users. Alongside this Atria also provided delegated admin features for managing Azure AD Groups, Resource Mailboxes, Shared Mailboxes and Exchange Online Contacts.

Through the SDK, you can build pages and publish them out to your users, this means they can self-serve rather than call your helpdesk.

In our Backup Example, a custom page may be able to link through to the backup console for the customer, or show the storage being consumed.

Permissions

Each service added comes with a set of default roles, the roles define the permissions needed for the different functions.

As an example

The Service Provider and Reseller is able to provision or deprovision the service to or from a customer

A customer is able to provision or deprovision the service to or from a user.

Within Atria, you can further define customised roles for your internal teams. For example, L1 helpdesk, you may want to revoke the ability to remove the service, but it might be fine for them to assign the service.

Permissions can be applied to Pages, Menus, and Service provisioning, you can also add your own permissions to use within your code.

Notifications Engine

Services by default have notification events, these can send internal or external emails on completion of provisioning.

In our Backup Service example, on completion of provisioning a notification event is raised. A notification can be defined which is sent out to a user containing all the information they need to get connected to their new backup service.

Variables from the provisioning request can be placed into the notification, it can also contain attachments and even be sent out in different languages.

Importing and Exporting Service Modules

Service packages, allowing you to move services in and out of an Atria instance.

Each service has a Service Schema – the import/export feature allows you to transfer services between Atria systems.

The Service Schema contains

• The Service definition – properties, plans and structure
• The provisioning rules for the service
• Any notifications defined for the service
• Roles and Permissions associated with the service
• Any DLLs or files needed for UI or provisioning