Last revised on June 9, 2022
Some terms have flavoring of a Technology shop focused on supporting/developing "Products". Please bear this in mind as the terms are intentionally designed for use by organizations supporting/developing Products as well as Applications.
Application is identifiable software or tightly coupled software components providing functions required by a Service/Product. An Application may be part of one or more Services/Products, but can only be associated to one Application Family. An Application is ran or hosted on one or more Servers or Clients (including Cloud instances).
NOTE: This definition is intentionally generic to permit recognizing desktop applications (eg Excel, Word), off-the-shelf applications (eg Salesforce, Box), and in-house developed applications. Desktop applications should be tracked, but limited to the Application (or major version of) itself…not the various deployments of it unless a business need dictates otherwise. Deployment tracking should be done elsewhere.
Application Family is a collection or categorization of one or more Applications. It is a label generally used within an IT organization (not listed in the Service Taxonomy or "Bill of IT" provided to supported Technology clients). An Application can only be a member of a single family. The use of Application Family enables more generic conversations about Applications when specificity is not needed.
NOTE: Application Families are not directly related to Services except by way of relationship defined between an Application and a Service/Product. Therefore, an Application Family could be related to multiple Services/Products.
Application Portfolio is a collection of all Application Families and, therefore, all Applications.
Application Portfolio Management is a management framework for IT decision makers to work and govern the Applications contained in the portfolio.
Component is a classification of an asset tracked within a CMDB (or CMS). A component is sub-ordinate to a Product. A component is generally regarded as an Application (see definition for "Application").
Bill of IT is synonymous to an "internal invoice" from a Technology organization to a supported client. The bill provides an itemized listing of Technology Services (leveraging the Service Taxonomy) showing what was consumed or supported for the client along with costs and other relevant details (eg rate, user counts, trends).
Configuration Management Database (CMDB) is a repository that acts as a data warehouse for information technology (IT) installations. It holds data relating to a collection of IT assets (commonly referred to as configuration items or CIs), as well as to descriptive relationships between such assets.
Platform is a classification of an application. A platform classification indicates the application is required for the operation of two or more other applications.
NOTE: An application is not a platform if it supports one application. Applications providing a monitoring function are not platforms. Applications providing direct support to large volumes of users (eg Office 365, SharePoint, various desktop applications, etc) do not qualify for platform classification.
Product is alternative label used for a Service. Typically, Product is used exclusively by Agile teams and IT organizations organized as a DevOps practice. A Product is not equivalent to an Application nor Application Family. See Service for further information.
Service is the means of delivering value to customers by facilitating outcomes customers want to achieve without ownership of specific costs and risks nor awareness of underlying resources and processes needed. Services can comprise of none, one, or many Applications and/or other Services.
NOTE: More info can be found by researching "ITIL standards".
Solutions Taxonomy is a framework used to organize and create a hierarchy of Solutions (eg Services, Applications, Products) into parent containers which supported clients can understand and be empowered to have discussions and make decisions about. The standard Solutions Taxonomy has 4 layers or tiers. The entry point of the taxonomy is the Offering (fourth layer) rolling up or collapsing into Name (third layer), Category (second layer), and Type (first layer). Contributing elements to Offerings are outside of the scope of a Solutions Taxonomy and should be managed elsewhere with the understanding they should be mapped to a defined Name that is tracked within the Solutions Taxonomy.
NOTE: The TBM Council's Solutions Taxonomy is available here.
Sub-Component a sub-classification of an asset tracked within CMDB (or CMS) and sub-ordinate to a Component.
Technology when used as a pronoun generically and broadly refers to any technology related organization (eg IT, Engineering, Dev Ops). A business unit's name, department's name, team's name, or a manager should be used whenever a specific team or sub-organization is being referenced.
Total Cost of Ownership (TCO) represents the fully burdened or rolled-up cost (inclusive of labor, hardware, software, facilities, utilities, etc) of an item. TCO can be represented for a Service, Product, Application, Application Family, Product, Server, Support Ticket, etc.
Services
- What is a service?
A service is the means of delivering value to customers by facilitating outcomes customers want to achieve without ownership of specific costs and risks nor awareness of underlying resources and processes needed.
- What is the standard TBM service hierarchy structure and how can I adopt it?
The TBM service structure contains 4 levels:
Level 1 (top) = Service Type
Level 2 = Service Category
Level 3 = Service Name
Level 4 (bottom) = Service Offering
The first 3 levels are standardized...meaning they are pre-defined and linked to their parent level.
For each existing service in your department, you can connect into the standard TBM structure by aligning your service as a Service Offering (level 4) and associating it to a Service Name (level 3).
More information about the standard service hierarchy is available in the TBM Taxonomy documentation.
- Can I change a label or relationship between levels for any of the standardized levels (Level 1-3)?
We don't recommend doing that. Please consider making changes to your Service Offering (level 4) and mapping it into the desired Service Name (level 3).
If you still require a change be made to the existing standard structure, please contact your TBM Team or Service Management Office for assistance.
- Is "Office 365" considered a service?
Using the TBM Solutions Taxonomy, Office 365 is considered an Offering. It would roll-up into the "Productivity" Name (level 3), rolling up to "Communication & Collaboration" Category (level 2), and rolling up again to "End User Services" Type (level 1). An illustration of this roll-up is shown below:
Level 1 = End User Services
Level 2 = Communication & Collaboration
Level 3 = Productivity
Level 4 = Office 365
Applications
- What is an application registry?
An application registry is a list of applications appearing within an Application Portfolio Management system or possibly an Asset Management System and/or CMDB.
- When should I create a new record for an application into the application registry?
For new applications, the record should be created as close to or just before the time any work or cost is incurred.
For existing applications, the record should immediately be created without delay.
- Should I create a new application registry record for a desktop application?
Yes! All applications should have an entry in the application registry.
- Should I create separate application registry records for each lifecycle phase (eg In Development, In Production, Pending Retirement, etc)?
No! An application's lifecycle state should be managed within a single record as an attribute. The attribute should be updated whenever its status changes. For example, an application transitioning from initial development into production use should have its status updated from "In Development" (or similar) to "In Production" (or similar values depending on the Application Portfolio Management system in use).
- How should I reference or link to an application?
The application's unique ID code should always be used. If desired, the ID in combination with its name may be used, but the key is the ID code is present...always.
By relying on the ID, name changes and other attributes can be changed without impacting existing references (since the ID should never change).
- Should my project reference an application?
If your project will create a new application and/or affect existing applications (including retirement and decommissioning activities), YES!!!
- My project is affecting multiple applications. Which one should I reference?
If your project (or other activity/system) refers to more than one application, please follow one of these approaches:
SOLUTION #1
If your system allows, enter the unique ID code for each application created/affected and an impact ratio of the total effect expected. For example, a project affecting three applications (ID 321, ID 5555, and ID 444) could be entered as:
|
321
|
30%
|
|
5555
|
25%
|
|
444
|
45%
|
The sum of the impact ratio should tally to 100%.
SOLUTION #2 (if above solution doesn't work)
If your system does NOT allow for a tablular representation of applications and their impact ratio, enter the ID code for each application into a designated text field where each code is separated by a comma. For example, using the same ID codes in the above solution:
321,5555,444
Data File Transfers
How do I arrange a new data file transfer to TBM?
Send a sample data file to the TBM Team member(s) you are working with. The sample file should adhere to the guidelines below for type and structure.
When dealing with large data sets, your sample data file should be a partial dump of data and a fair enough representation of data values found in a full data extract.
A TBM Team member will advise of any changes or, if no changes needed, give the go-ahead for you to arrange the permanent recurring data transfer.
File Naming
- Preferred format of file names are:
[Source System Prefix]_[Title of Data Set]_[Date and Time Suffix].[File Extension]
- No hyphens. If a separator of some kind is desired, use a single underscore character.
- No double underscores.
- Source System Prefix should sufficiently identify the source system (eg ServiceNow, Workday, PPM, etc) from which the data was extracted from.
- The Source System Prefix should not be "TBM", "Apptio", or similar.
- The Title of Data Set should be a summarized description of the data extracted. Some examples are ComputerAssets, application_parent, External_Labor_for_TBM, and mobiledevicesfortbmapptio.
- Date and Time Suffix should match format of YYYYMMDD[mmSSss].
NOTE: Characters enclosed in brackets are optional. YYYY = 4 digit year, MM = 2 digit month, DD = 2 digit calendar day, mm = 2 digit minute, SS = 2 digit second, ss = 2 digit millisecond.
- An underscore should be placed between the Source System Prefix, Title of Data Set, and Data and Time Suffix values.
- Examples of valid file names are:
servicenow_application_parent_2020092205442101.xlsx
Workday_LaborRosterForTBM_202001010100.xlsx
IDM_user_list_for_TBM_202004120422.csv
File Types and Data Structure
- TBM prefers Excel 2007 or later (xlsx) format, but delimited text files are also acceptable.
- When providing Excel files with multiple worksheets, ensure your TBM team is aware of the worksheet name to import data from.
- If sending a delimited file, you must use a delimiting character not used elsewhere within your data values unqualified text strings or strip out the characters from the data values prior to transferring your data file to TBM.
- Recommended delimiters to consider are | (pipe) or ^ (caret).
- If qualifying text strings with a character, ensure that character is never used within any of the text strings in the data set. Recommended approach is to block the character from being used or remove/replace it before your data file is published.
- Carriage returns in delimited files are supported only to define new data rows. If a carriage return is in a text string (qualified or not), it should be removed before transferring the data file as it will be interpreted as a new data row instead of a line break.
- Once a data feed has been established:
- Do not change the file name structure.
- Do not change the worksheet name (for Excel files only).
- Do not add/remove column header names (including casing/capitalization) without acceptance from the TBM Team.
- Do not add/remove a column header row or rows above it.
- It’s always acceptable to re-ordered columns in new publications.
File Delivery & Frequency
- Unless advised by the TBM Team differently, your data file should be:
- Delivered to the TBM Team on the 1st of each calendar month between the hours of midnight and 7:00 AM PT.
- Represent a snapshot of data from the prior calendar month. For example, a file transferred to TBM on September 1 should contain data for the full month of August.
Cloud
- Using Apptio CT, can I see multiple providers (AWS, Azure, GCP, and others) in a single view?
Yes! Apptio CT initially imports each provider’s data. Then, the data is consolidated and harmonized into a single table. Apptio CT reports reflect data from the harmonized table allowing colleagues to compare apples-to-apples.
- How does Apptio CT compare data across AWS, Azure, GCP, and other providers?
In partnership with the TBM Council, Apptio established the Apptio TBM Unified Model (ATUM). ATUM is a standard taxonomy across Cloud and on-premise investments. ATUM enables a single view of technology costs across usage, utilization, and capacity.
- Can Apptio CT replace or act as an alternative to a Cloud Operations tool (eg Cloudability, CloudHealth, Tubonomic, Flexera One, etc)?
Although possible to support similar basic features, Apptio CT is not a Cloud Operations tool. Some of the benefits Cloud Operations tools have over Apptio CT:
- Designed to ingest and report data hourly; Apptio CT’s Prod environment is usually updated monthly
- Designed to report expenses from the invoice/bill amounts; Apptio CT reports expenses from the general ledger which often contain accounting transactions from a previous period and/or a previous period’s corrections applied to current period
- Designed to provide rich data granularity; Apptio CT aggregates data for purposes of modeling and allocating costs to areas unrelated to Cloud
#ApptioforAll