Model an application
Model an application adds the common case in one go: the business service, an offering of it if there is one,
the application service behind it, and the configuration items it runs on, all joined up. Open it from
Configuration items or Services: Model an application at the top. It needs the Service Manager role
(service.settings); adding new CIs on the way also needs ci.write.
Nothing is added until the last step, so you can go back and change anything first. A preview beside the steps shows what you are modelling as you go.
The steps
| Step | What |
|---|---|
| Business service | What people use and talk about: Online shop, Payroll. Pick one that is there, add a new one, or choose None to add the application on its own. |
| Offering | A variant of the business service with its own name and code, such as a Premium plan. Most applications have none. Pick one of the service's offerings, add a new one, or leave it out. |
| Application | The software that delivers it, in one environment: its code and name, environment, tier, units, owner and support team. |
| Runs on | The CIs it needs. Pick ones that are there, or add new ones with a name, class and environment. For each, pick how it is joined: usually Runs on, or Uses for something it keeps working without. |
| Review | The list of what will be added and joined. Add it all does it. |
A new service's code is made from its name (Online shop becomes ONLINE-SHOP) until you change it; an offering's
starts with its service's code. Everything new goes in the units picked on the Application step. A picked
business service's units and tier are the starting point.
New services and CIs are Live. The owner and support team picked for the application are those of the new business service too; the support team also looks after the new CIs, and you own them when you work in their units.
What is joined
SHOPbusiness service
SHOP-PREMIUMoffering
SHOP-WEBapplication service, depends on
virtual machine, runs on
database, uses
The business service (or its offering) depends on the application service, and the application service runs on its CIs. On the Dependency map, a service and its offerings are drawn joined as well: an offering relies on its service, so trouble on the business service reaches its offering, never the other way.
If something goes wrong
Each line on the review ticks off as it is done. If one fails, for example because a code is taken, what is ticked stays done and the message says what went wrong. Fix it (go to the record, or change what you can) and Try again: it carries on from the line that failed and doesn't add anything twice.
When it is done, Open the application service, or Open on the map to see it with everything around it.
Every record added is kept in its history and the audit log, the same as when it is added on its own. To change anything afterwards, edit the records on their pages.