See things clearly
A question was posed the other day on the OBASHI LinkedIn group:
"At what point does a piece of software fall into the Application Layer instead of [Operating] System?
I'm busy documenting a bunch of Windows IIS and SQL servers: IIS (which is included with Windows Server) should logically be on the same layer as MS SQL (which is a separate install but thus in the Application Layer).
Also wondering about Server Support Software (i.e. backup, scheduling, monitoring, asset management) - I feel this should be in the System Layer as it cannot be linked to a customer. Any thoughts, suggestions?"
Due to space restrictions on LinkedIn I had to give a truncated reply, but here is a more complete response:
The question of what constitutes an Operating System (or part of an Operating System) is one which we debated long and hard over the years when we were designing OBASHI.
I think you are correct in placing IIS at the same layer as SQL Server because, despite it shipping with the Operating System, it is not actually part of it, but runs as a separate application on top of the Operating System.
The same can be said of the server support software you mentioned. We would class those as applications which are run in the Application Layer, even the software which ships with the Operating System.
Taking it to an extreme, you could say that just because Notepad (or NT Backup) ships with, and is installed by, Windows, we wouldn’t call it part of the Windows OS, rather it is an application which is run on top of the OS.
On the ‘linking to a customer point’, we generally find that such support software is maintained and operated by the IT department (or those tasked with IT Support). The staff which perform this role, together with the software they are using, all contribute to the cost of operating the server.
Consequently, we would tend to map the IT Support with its own Ownership and Business Layers, to show the service which is being offered to customers, with the support applications which are supporting those processes in the Application Layer.
So, our rule of thumb would be to turn your question around.
Rather than considering “At what point does a piece of software fall into the Application Layer instead of [Operating] System?” it’s easier to consider “At what point does a piece of software fall into the System Layer instead of the Application Layer?”
We place all software in the Application Layer unless it is the actual Operating System itself, or (as you’ll see in section 8.8.1 of the OBASHI Manual) it is a virtualisation application such as a hypervisor which runs an Operating System.
To place a hypervisor in the Application Layer would mean that any Operating Systems running on the hypervisor would also need to be in the Application Layer, which would not be logical… so virtualisation software is considered an Operating System too, as it act as an abstraction layer to the hardware on which another Operating System can run.
That makes sense to me, but on a similar vein, where would a data centre sit? Within section 6 of the manual it is hinted that the data centre is part of the Owner element, but I can't see how that would be. Surely the owner is the a member(s) of the wider business who sit above / use the Business Processes.
Personally I would have the data centre as an infrastructure element as it underlines all other elements.
Am I wrong?
Thanks for a very good question.... We have recently been working with a client who wanted some clarity around the three cloud services they utilised, hosted in three separate data centres, split over two parts of the business, and how they integrated with the corporate in house accounts and archive systems.
So what were the OBASHI options....
Let's create an OBASHI diagram for each Data Centre first.
Who owns the data centre... let's say it's 'Third Party Data Centre Inc.' - add the element to the Ownership Layer.
What Business Processes do 'Third party Data Centre Inc.' need to provide the data centre service to the client/end user... Add the element(s)
What Apps are used by the 'Third party Data Centre Inc.' to provide the data centre service to the client/end user... Add the element(s)
What Hardware is used by the 'Third party Data Centre Inc.' that they provided and what hardware is used by the 'Third party Data Centre that is provided by the client to provide the data centre service to the client/end user... Add the element(s)
.... you get the picture
So we mapped out the Data centre assets that the clients business is dependent on ... for all three data centres. In essence 3 B&IT diagrams.
We now had a clear view of all the assets and their relationships to each other and consequently the paths of how the data flows through the data centre layers and through the routers and switches that connect to the clients Corporate routers and switches...
So in this instance/project we treated the data centre as a third party business that had its own B&IT diagrams. Through element persistence we can re-use some of the key elements from the Data Centre B&ITs to show how those elements are used by the business.
This also highlights of course the 'Risk' to the business of failure of any component part of the data centre they have outsourced the service to.
However, you might not want to be so detailed and may have decided the audience for the B&IT diagrams don't need to see all the detail of the Data Centre operation, in which case you could adopt the approach in the following example:
Firstly, lets take a look at Figure 8.36 from The OBASHI Methodology, which shows how three applications (SAP, SIEBEL and ORACLE) are used by some business processes within the Account, Logistics and Production departments.
(*click the images to zoom in)
Let’s imagine a project just relocated SAP, SIEBEL and ORACLE into a data centre.
We could easily show that on a single diagram like this.
By mapping this out on a single B&IT diagram, and putting the data centre first, we’re highlighting that the SAP, SIEBEL and ORACLE applications are housed and run within the data centre but the Accounts, Logistics and Production departments utilise them and would suffer a potential impact should they fail.
So I guess the first question is “Who is your audience?”. This usually defines how much detail you need to show. You could always start off small as per the example above and expand the detail later as time and budget allows.
Hope that helps …