Skip navigation
All People > dfsoll > David Soll's Blog > 2017 > October

David Soll's Blog

October 2017 Previous month Next month

Before building an AF hierarchy, an implementation should start by building templates, specifically Element Templates.  Templates are AF's way of making your work simpler and easily repeatable.  After performing numerous AF implementations, we have found that the best way to start defining AF templates is to start with a base template, upon which all other templates are derived.  Doing this allows you to add common components to all templates by simply editing the base template.  Note that there is nothing wrong with starting out with a base template that is completely empty as you may not initially have anything that you feel should show up globally in every element.


It is important to understand that there are two distinct hierarchies within AF (when referring to Elements and their templates): The element template inheritance hierarchy and the element instantiation hierarchy.  The element template inheritance hierarchy (viewable by selecting "Arrange by Template Inheritance" from the Element Template's right-click menu) represents how one template inherits components (such as attributes, AF Analytics, and Notifications).  This has nothing to do with the physical structure of the elements themselves.  The physical hierarchy is the layout of the elements themselves, no matter what templates they use. 


There are a number of best-practice recommendations involving the use of AF Element templates, the first of which is that you should never (or at least rarely) create an element that does not inherit from a template.  There are a number of reasons for this: many tools use the template to determine similarity between elements for things like visualization.  Another reason is that it makes adding components (such as  an attribute) simpler since you can edit the template and the element will automatically inherit it.


Another best-practice is to create a "master" or "base" template upon which all other templates are based.  If you follow these two best-practices, it means that you will easily be able to add or modify all elements in a hierarchy by simply editing the base template.

It is hard to argue that AF would not bring value to an organization, but the barrier to entry may be very high.  For a company that already has a well-established point based PI system, lots of value is likely already being derived.  How can you justify a large infrastructure project to turn the point based system into an AF/hierarchical model based system?


Infrastructure projects are always difficult to sell.  They provide the mechanism to do lots of good and valuable things, but by themselves, they provide new capabilities and no immediate perceivable value.  As a result, it's important to tie an infrastructure project to an application or specific business need.  Of course, no one application is likely to require the full AF structure, but it will require some portion of the hierarchy and/or attributes.  So, the key is to build a reasonable complete hierarchy without concerning yourself with including every attribute.  You see, one of the nice things about building an AF structure (especially if you use templates) is that you don't have to get it right the first time.  As you find additional attributes needed, they can be easily added.  If the attributes are added to templates, then every instance of that template receives the new attribute automatically.  In addition to adding attributes, you can add calculations (AF Analytics) giving you more flexibility and capability.


One of the really great things about AF is that you don't have to get it right or even complete on the first go-around.  It's easy to add attributes, analytics, and notification at a later time, especially at the template level.  When adding components to an existing template, all of the elements based on those templates will automatically become updated once the changes to the templates are checked in.