TBM Framework & Taxonomy

 View Only
  • 1.  TBM Taxonomy v4.0 Approved, Endorsed and Released

    Posted 12-18-2020 15:08

    Hello everyone,

    It's my please to announce that version 4.0 of the TBM Taxonomy has been approved by the Standards Committee (on December 16) and endorsed by the TBM Council's Board of Directors (on December 17). 

    This version benefitted from the most feedback, reviews and discussions we've ever had for a taxonomy update. We've held dozens of education webinars, open forums (feedback sessions), one-on-one reviews, stakeholder meetings and more throughout the latter half of 2020. If you participated in these, you have seen us propose and discuss some fairly significant changes and inclusions of new elements to test the waters. Always, our goal was to improve the relevance and value of the TBM Taxonomy for the rapidly evolving business technology landscape that we live in. Top of mind were shifts that we're seeing in the adoption of agile-at-scale models, DevOps-type methodologies, public cloud adoption, IT service management maturation, business and enterprise architecture practices, and more. 

    We feel strongly that this version represents the proper balance between what is changing and what we've had to support over the last decade with TBM. 

    You can find v4.0 here: https://community.tbmcouncil.org/viewdocument/tbm-taxonomy-v40-final-documents

    I'd like to thank all of our standards committee members, especially our chair,  @Atticus Tysen, and our technical advisor and "chief taxonomy architect"  @Edward Hayman. And I'd like to thank all of you who spent time with us this year as we went evaluated the various changes and talked about your needs related to TBM and the taxonomy.

    There's still a lot more work to do. We will follow up in early January with a workbook that contains the terms and definitions that you find in the taxonomy. We have additional content we need to produce, too, such as metrics tied to the taxonomy and deeper dives into TBM model archetypes. We will be tackling these starting in January.

    Meantime, I hope you find greater value from this new release. We look forward to more conversations in 2021!

    Todd Tucker
    VP, Standards and Education
    TBM Council

  • 2.  RE: TBM Taxonomy v4.0 Approved, Endorsed and Released

    Posted 12-19-2020 10:06


    Excited for 2021.


  • 3.  RE: TBM Taxonomy v4.0 Approved, Endorsed and Released

    Posted 02-24-2021 19:30
    Hi Todd,
    We've just adopted the TBM v4 taxonomy as our starting point for a new IT Service Catalogue. I'm working with colleagues across IT to agree which Services we provide, and to defined owners and Service Offerings. 
    I have what I'm hoping will be a very easy question to answer: "DR facilities" is listed as a Sample Service Offering under the BC & DR Service. In this context, does this refer to actual cold or warm DR sites/buildings to which a business can relocate in an emergency, or is it a more general reference to technologies and equipment used in an emergency (e.g. 'office in a box' equipment: laptops, 4G connectivity, battery packs etc.)?

    Service Type Service Category Service Name Service Definition
    Delivery Services Security & Compliance Business Continuity & Disaster Recovery Business Continuity ensures the continuous operation of the enterprise. Services include business impact assessments, business resiliency plans, disaster recovery capabilities and the associated exercise, testing, training and awareness to support people, process and technology recoveries in case of an incident.


    Quentin Kynoch
    Business Technology Partner
    KPMG Australia
    Sydney VIC

  • 4.  RE: TBM Taxonomy v4.0 Approved, Endorsed and Released

    Posted 02-25-2021 18:31
    Hi Quentin, it's a great question.

    It's worth starting at the tower level to answer this question.

    At the Tower level, the "Disaster Recovery" subtower should NOT include the facilities or equipment or things like that. Instead, it should include those resources and expenditures that are owned by a traditional BC/DR team. Those costs are likely in the budget of the BC/DR team, including the team's labor, tools they buy for BCP, outside services they employ (e.g., consultants for business impact assessments), etc. But the backup data center facilities, power & cooling, servers, storage, etc. are included in their respective towers (Data Center, Compute, Storage, etc.). 

    However, at the solutions level this is different. Here, the BC & DR services would include the totality of what is needed to provide them. That would include the BC/DR team's spending (from the DR subtower) as well as the facilities, equipment, etc., that were found in the other towers.

    Not to complicate things further, but consider whether or not you need to define BC/DR as "services" at all. If, for example, you offer them to application owners or architects and they have a choice about how they consume them, then perhaps you would include them in your service catalog. However, if BC/DR is simply built into your solutions (apps, products, services), you may not need to put them into a service catalog and call them out separately. If that is the case, you would simply allocate BC/DR tower costs as well as the DR resources in the other towers (Data Center, Compute, Storage, etc.) to the solutions that are consuming them.

    In my view, the following factors should be considered for whether or not BC/DR is defined as services:

    • There is a clear consumer of the service. By the way, this does not mean the consumer has to be given the option about consuming the service. For security, compliance, etc., services can be mandatory in certain situations (based on policies). But if you're having trouble identifying a consumer, then you probably don't have a service.
    • There is a standard way to describe the service that is being offered. In other words, it is not bespoke every time it is consumed. Of course, you may have tiers or service level packages, etc., such as "hot site backup" vs. "warm site backup" vs. "cold site backup", but these are standard service configurations. Similarly, you can have standard options/add-ons/etc. But if the service varies in unpredictable ways from consumer to consumer, then it's not a service and you need to rethink it. Maybe it's a consulting service?
    • You can put a price or rate on it so that it's easily understood by your consumers. They should be able to determine how much it will cost them based on their own plans and designs.
    • There is a clear owner of that service. You know who designs the service, prices it, and is responsible for its business value and cost.
    • The service owner possesses and maintains any assets used in providing the service. Services that do not require significant assets could be provided and therefore assets are not required. However, if there are assets used, they remain with the service owners. Example: Your BC/DR team provides "hot site backup" and they own the servers and storage systems in the backup data center. Or: Your BC/DR team provides BCP assessment and design services to internal application owners and no significant assets are required.

    I hope that makes sense and is helpful. If not, please respond further.

    Todd Tucker
    VP, Standards and Education
    TBM Council