We're in the process of planning our roll out of an IT Cost Model according to ATUM 2.0 guidelines.  I've built a customized cost model in Apptio at another organization, but it was pre-ATUM.  Since we're still in planning mode and haven't yet purchased Apptio, I'm uncertain what the user accomplishes between the IT Towers and and Services layer.  In our customized model, we used this layer to primarily allocate IT Resource Tower costs to specific applications.  However, if I look at the Services  definitions, you have Delivery and Infrastructure Services.  

• Are the services just another categorization of resource towers?  
• How do you get to App TCO if costs still reside in "development" or "physical compute".  
• Do you categorize IT Towers into Delivery and Infrastructure Services and then later allocate to Business Application Services?

Hi Nancy,

Good question! Ultimately like most things I believe it depends on your objectives with Apptio/TBM. Depending on the questions you want to answer, that layer in between the ITRTs and Services can actually be by far the most powerful.

The way I see it is that you can use the model to build/layer up Total Cost of Ownership - first, a functional TCO view at the ITRTs. Second, an infrastructure TCO in the layer between the ITRTs and Apps/Services (recognising that, for example, a server also consumes data centre, networking etc). Thirdly an App/Service TCO. You may have another layer before/alongside the app/service layer which comprises some of those delivery/infrastructure services, which can then be allocated to the business apps/services.

You could bypass the infrastructure TCO and drill down into an App/Service straight to the ITRTs to give a summarised breakdown, and actually this is a fantastic, rapid way to produce reporting/insights.

However, what I believe is more powerful is being able to drill into the infrastructure items themselves - particularly servers by host name.

Consider the two scenarios:

1) Without infrastructure TCO - ok, I know that my app's Windows costs are £x, but how do I affect that? I could switch some servers off, or move to Cloud, but how do I know which servers to go after?

2) With infrastructure TCO - ok, I know my app's Windows costs are £x, and I know that I have 20 servers contributing to that. I can see these 5 servers are running a non-strategic OS, are under-utilised and are sitting in a Data Centre which is a candidate to be exited. Great, I'll prioritise these 5 servers for Cloud migration.

• Are the services just another categorization of resource towers?  
  • In most cases, services will be comprised of multiple IT Resource Towers, however in some cases there may be direct alignment between the two.
• How do you get to App TCO if costs still reside in "development" or "physical compute".  
  • This is where the infrastructure layer helps, because you can allocate physical compute to individual servers, which you should then be able to align to individual apps. With something like "development" (assuming application development), you'll probably need some kind of data to back the allocation (projects, labour/contracts mapped to apps, time tracking...). If you're refering to development servers, again the infrastructure layer makes this trivial, assuming you can identifiy development servers.
• Do you categorize IT Towers into Delivery and Infrastructure Services and then later allocate to Business Application Services?
  • This one comes down to your operating model. If you're presenting business units with a bill by application/business service, then to me it makes sense to roll those enabling services into the apps/business services. The services we present to the business are actually the infrastructure services themselves, so that forms our service catalogue.

Thanks Steven.  I appreciate your enthusiasm about the topic  .  You make a great case for infrastructure TCO.  In a way, you get this TCO by reporting straight out of the Server Object and looking at the resource towers that feed into the object, but it may lack the granularity that you mention (ie datacenter location). 

How does the model look structurally?  Did you have to create a secondary layer of infrastructure objects or does this fit within the standard ATUM model?  

Our model is similar to your diagram, but without the Infrastructure TCO box, and without the grey boxes. We roll the servers straight up into an applications object, which in turn rolls up to services. We'll use the server object to report on the server TCO in the future, once our data is better. We're generally trying to keep to the standard model where possible.

I think in the future we may look towards an "enabling services" or "infrastructure services" object. The purpose would be to capture any servers which don't map directly to Business Applications (eg: Exchange servers, FTP servers, Management servers etc).

Ok, I think I understand.  It sounds like conceptually you're costing out the infrastructure services, but you don't show all of them in an aggregated view in a report.

Here are some of the documents that I was referencing that were causing confusion.  It gives the impression that each category in the the services layer are on the same level rather than hierarchical:

   1) ATUM v2 Reference Lists (Zipped CSVs) -- Updated 11-16-2018 

         [See Service Taxonomy Tab in the TBM_Taxonomy_V2.0 FINAL download file]

   2) Introduction to the TBM Taxonomy 

If the ATUM model doesn't have a Infrastructure TCO or Services object, where does the "Service Taxonomy" come into play?  Are the "Service Type", "Service Category", and "Service Name" fields mapped in some objects or across several objects?

Hi Nancy,

I'm glad you brought up the issue of the Services layer being hierarchical.  I had been staring at the v2 taxonomy for the better part of a year before realizing that the standard model depicts Business Application and End User Services consuming the "IT Facing" services.  This adds a level of complexity that we had not thought about when working out the allocation logic in our model.  The concept of Services consuming Services is also difficult to explain to stakeholders who are just being exposed to TBM for the first time.  Ultimately, after several conversations both internally and with our Apptio delivery team, we decided to treat all Services the same for this phase of implementation. 

I think this is an important topic and I'd be interested to hear what other organizations have done.

Steve 

Well said, Steven. Really helpful in understanding the impact of the infrastructure layer!

Hi Nancy,

Ah - ok - understand your original question a bit better now. I'll have to defer on the academic/official answer to this, but my opinion would be that there's an element of flexibility in how you implement/present the Service Catalogue, due to the differing operating models across all organisations using TBM.

For example, I've worked in an organisation where the Business Application Services and End User Services were included in the Service Catalogue, as part of a single "Business Services" object. The Infrastructure Services had their own objects (Servers, Mainframe, Storage etc), and were allocated into the "Business Services" object as components of "Business" Services, rather than Services in their own right. So for example, the Mainframe object would map into many Business Application Services based on each app's consumption of Mainframe.

My current organisation does not include Business Application Services in our Service Catalogue, but does include Infrastructure Services. In this case the Infra Services do appear as distinct Services in the catalogue. They still have their own individual objects (Servers, Mainframe, Storage etc), but generally, for example, the Mainframe object will map up to one/two "Mainframe" Services. Again, a single Services object is used to considate all of the Services we present out to our consumers as part of our Service Catalogue.

So it really comes down to how your organisation operates - the services you want to present to your consumers should define your service catalogue. That may be by application (my personal preference), but it may also be by infrastructure types, or it may even be a hybrid of both!

"Service Type", "Service Category", and "Service Name" are different ways of grouping Services, and you can hold those groupings within a single Services object. You would most likely allocate costs to individual services in your model, but when it comes to reporting, you're able to summarise by Category or Type.

Steven