Written by Colin Vozeh, Director of Sales – Enterprise Services, Datatrend Technologies, Inc.
Simple SoftwareInstance Modeling
Collaborative Application Mapping is a recent effort in ADDM to allow users to create application models without getting mired down in an obscure scripting language that few are inclined to dedicate the time to learn. It offers a relatively simple GUI-based method for defining applications, the components that comprise those applications, and the relationships between them. For many organizations, this is definitely the way to go.
But until now, CAM lacked the ability to include SoftwareInstance nodes – the basic building blocks of modeled applications – that weren’t already recognized by ADDM. There are over 500 off-the-shelf software products recognized by the latest TKU, but if your in-house developers created their own executable for a critical business application, ADDM didn’t recognize it, and so it couldn’t be included in your CAM modeling results.
With ADDM 10.1, that’s no longer an issue. You can select any DiscoveredProcess or DiscoveredService node in the ADDM UI, go to the Actions menu, select Generate Software Instance Pattern, and simply input the data you need to identify that SoftwareInstance – typically, just a “Type” value will suffice.
There’s still a few drawbacks. You can’t, for example, define the uniqueness of a SoftwareInstance on a given host with a complex key – it’ll only ever be “type on host”. And you can’t do any additional logic to determine a version number, or include associated processes. But it’s definitely a step in the right direction, and can be the key to getting the most value out of Collaborative Application Mapping.
Datatrend Technologies, Inc. is the industry leader in large-scale enterprise application modeling projects, having completed tens of thousands of application models for our customers. As part of our application modeling efforts, we’ve seen and done it all – including the mistakes. Here’s a few helpful tips for topics that you may not have encountered.
model.addContainment is not just for SoftwareInstances!
In application modeling, the most common relationship we use and consider is called SoftwareContainment – we add SoftwareInstances to BusinessApplicationInstances, and they then share the SoftwareContainment relationship. We say that this application contains that software, and that is the basis for our model. But we can use model.addContainment in other ways, too. For example, applications can belong to a family of applications, and may contain one another.
Say you were modeling an application called WebSales, that existed in three different locations – New York, London, and Hong Kong, and three different lifecycles – Production, Development, and Test. In ADDM, we could describe this relationship hierarchically: the main WebSales application contained no SoftwareInstances, but only other locations. And each location contained no SoftwareInstances, but only different lifecycles of the application. Only those individual lifecycles for each location would contain any SIs. It could work something like this:
bai_type := “WebSales”;
grandparent_bai_type := type;
grandparent_bai_name := “%grandparent_bai_type%”;
grandparent_bai_key := text.hash(“%grandparent_bai_name%”);
//%location% would be determined by the Location node related to
//the host on which the trigger was running.
parent_bai_type := bai_type;
parent_bai_name := “%parent_bai_type% %location%”;
parent_bai_key := text.hash(“%parent_bai_name%”);
//%lifecycle% would be determined by the LifecycleStatus node
//related to the host on which the trigger was running.
child_bai_type := bai_type;
child_bai_name := “%child_bai_type% %location% %lifecycle%”;
child_bai_key := text.hash(“%child_bai_name%”);
grandparent_bai := model.BusinessApplicationInstance(
type := grandparent_bai_type,
name := grandparent_bai_name,
key := grandparent_bai_key
parent_bai := model.BusinessApplicationInstance(
type := parent_bai_type,
name := parent_bai_name,
key := parent_bai_key
child_bai := model.BusinessApplicationInstance(
type := child_bai_type,
name := child_bai_name,
key := child_bai_key
Note the use of model.addContainment at the end – the triggering SI is not made to have a SoftwareContainment relationship with any but the very lowest level BAI. But we can still see how each BAI is related to one another. It should result in a hierarchy like this:
It’s very common that there are multiple instances of any particular application, differentiated by location, lifecycle, environment, or user base. Without creating relationships between them in ADDM using model.addContainment, there won’t be any way to understand how they’re related – they just all coincidentally have the same value for the “type” attribute.
For more information on ADDM or other BMC tools, please contact Warner Schlais, President of Technology Services, at email@example.com.