TBM Framework & Taxonomy

Folks, the Version 3.0 draft for comment is now available and can be downloaded here (TBM Taxonomy V3.0 Draft for Comment). All members are welcome to download the document and post comments or questions here for the Standards Subcommittee on Taxonomy Evolution and/or for other members.

Subcommittee members include:

• Michel Brassart (chair)
• EHayman@apptio.com">Ed Hayman (technical advisor)
• Brian Wolk
• dirk.vonderbrake@exxonmobil.com">Dirk Vonderbrake
• Eric merkle
• Kathy Rudy
• qi_chen@fanniemae.com">Qi Chen
• Tony Agent

Please respond to this thread with substantive comments, suggestions, questions, etc.

Thank you,

Todd

Thanks for adding a description to the Cost Pools and Towers.

Thanks for the effort to keep the taxonomy updated! It must be a chore to orchestrate 1000 opinions!

One of my concerns with a taxonomy is not to create logical do-loops, which have been the downfall of more than one architectural reference model in the past.

I would propose 2 changes, one of which is simple.

The simple one is to replace the term "data center" with "computing facilities".  While the term may be correct as defined, it is widely used by non-TBMers to mean "all the capabilities that such a facility typically houses."  In the organizations I have ben working with, this is the number one source of confusion and holding to it as defined in TBM frankly threatens the credibility of the framework in the eyes of the people who are really doing the IT work.

A more complex one may or may not be a proposed change, depending on how the language ends up, so I'll state it here in terms of what I think we need to shoot for.

With regard to business services, shared services and platform services. Again it is matter of making the model clear enough that regular IT managers can grasp it, as well as maintaining comparability across organizations and even sub-organizations. The IT Services basically represent the manageable layers of the OS stack and conform to the majority of EA structures that already exist.  Until you get to the business services at the top of the model, everything else below it is function-agnostic. We should not start setting up separate service groups for things that really belong in one of the other service groups; that is where the death spirals begin.

.

My suggestion would be to retain business applications services as just what it says: applications that deliver specific business functionalities. Now I know that we are not casual observers, but most IT and finance managers are (at least with regard to TBM) and they are the ones who will make it work or fall apart as they sustain what we put in place. When the casual observer sees "business services" without the "applications" word they can get confused about where we are in the architecture, and they tend to think of an end-to-end business process [purchasing] vs [purchasing management software]. If they are thinking IT at that point, they are thinking "system" because that is what they have contact with: a purchasing system that includes end-to-end IT (application, platform, infrastructure and all) and the next thing you know all the costs of those other services will be lumped in there, putting us right back to where we were before TBM tried to break them out. This what led to the practical demise of the last round of the DoD reference architectures: including entire systems at the "business applications" level.

Adding the Shared Services could work if we wanted to distinguish IT functional applications (such as dev-test or collaboration tools) that a person could use in support of any business or IT function (i.e. Shared Service) from Platform IT, meaning afunctional solutions that users can't "use" directly (such as enterprise service bus, hosting layers, database clusters, middleware etc for any business or IT  from user-invisible applications that manage infrastructure.

I guess that is a lot more than 2 cents ;-)

Douglas,

Thanks for your feedback and I will bring up your two points with the Standard Committee in our next meeting this week.  

1. I like your proposal to use "Computing Facilities" rather than "Data Centers".  Many IT people consider data center to include the infrastructure it houses.  Compute Facilities would more clearly describe the data center services we mean.  One challenge is that we want the taxonomy to stay relatively stable so users aren't forced to make frequent changes to their TBM model to account for the new taxonomy.  In this case, the change is relatively minor as the definition remains the same.  However, it will require updates to reference data, mapping files, benchmark alignment and reporting.  We will consider this in our next meeting.

2. Regarding Business Application Services, I have two separate points to call out.  First, we separated Business Application Services into two categories: Business Application Services and Shared Application Services.  Business Application Services would be for vertical specific capabilities that are unique to different industries (e.g. healthcare provider, investment banking, oil & gas, etc.).  Shared Application Services would be for those business capabilities that are common across companies and verticals (e.g. back-office capabilities like Finance, HR, etc.).  However, with the term Shared Application Services, many people might think it refers to Platform Services (e.g. enterprise bus, hosting, database, etc.).  As a result, we simplified the categories to just "Business Services" and "Shared Services".  This of course brings up the potential confusion you brought up where people would include business operations along with IT applications and systems.

Possibile category names include:

• Business Application Services / Shared Application Services
• Business Services / Shared Services
• Vertical Application Services / Corporate Application Services

Do you or anyone have thoughts on a better name for these two categories?

THanks, Ed!

You bring up a good point, of not further confusing the issue with Platform Services which many customers have a hard time grasping also, and I agree that "shared services" risks doing just that.

There would probably be value in having a section early on in the taxonomy to explain the issue with Applications, because software can appear in any tower and in all of the Services (end user productivity software, business functional software, enterprise applications, platform applications, software to control infrastructure, software to manage IT delivery, and software to manage IT management and security aspects).

Perhaps "business application services", "enterprise functional application services" and "platform services" ?

A lot of it will depend on the bullet points in the examples of what goes in each box; they must not fuzz the picture back up again.

I'm not sure that making a distinction between back-office functions and line-of-business functions really matters, as I think that for benchmarking or formulaic cost allocation you would have to go down another level to the specific function anyway. If you really need to do that then you'll probably want "line of business application services" and "back-office application services"

.

More critical is defining the separation of usable but non-business-function specific services that most organizations do have to deliver regardless of functions (e.g. collaboration, mail, eFax, records repository, VTC, etc.).

As a simplistic definition I like to believe that platform services are things that business users cannot really use to do anything and probably cannot even access directly.  The current model does make that fairly clear, for those who bother to read past the high-level picture. One area that seems to cause debate is test labs, which don't really have a business function but "people" can "use" them. Personally I prefer to consider this a platform service, but it doesn't matter as long as everyone is consistent. It does matter, though, because for anyone who is doing it, it is a good chunk of money that is enough to totally contaminate any benchmarking.