Page 1 of 1

Embedded software frameworks as CIs

Posted: Wed Feb 29, 2012 11:42 am
by Pathfinder-ICF
My client has an interesting dilemma.

The group I am assigned to develops and supports a software "framework" that provides various low- to middle-level services to the host business applications that use it. The "framework" components are developed and maintained separately, and then built into the applications at build time. Effectively, they are indistinguishable at run-time from the business application.

The "source code" components for the framework are properly listed as individual CIs in the CMDB. All CIs are under change management. I'm curious as to how others have handled software that gets embedded in host applications, especially around 2 key issues:

Issue 1. Detailed level mapping; the procedures require application dependencies be documented and diagramed. Do we document the CIs in source form, or at run time?

Complicating this is the fact that the framework also invokes other routines to do very low-level work (e.g. data fetches).

We've figured out that the options for diagraming the framework are:
- ignore the framework completely, not really "allowed", but the host could simply show the external data inputs and fetches without referencing the lower-level framework and other very low-level routines
- document the framework separately and simply have the host applications use an off-page connector to reference it

Is there another option we're missing?

Issue 2. Run time incidents are written against the host application, but are often bounced to our support team without investigation. Tracking incident bouncing is tough, as the incident tracking tool is not really set up to report on this bouncing. So the data is tough to document.

We are also concerned that if a critical incident is issued, the SLA will be breached during the bouncing before the incident is even investigated.

From my Quality days, Philip Crosby's Costs of Quality comes into play here, especially the cost of failure. That is, use the failures to make the point. I'd like to be more pro-active than that, so any ideas on how to break this bouncing?

Posted: Wed Feb 29, 2012 1:06 pm
by Diarmid
Issue 2:

incident bouncing is a crime. If it can happen then there is something wrong with the service management system. It needs to be fixed at that level, rather than with respect to individual teams. It is essential to identify who is responsible for initial diagnosis and what that entails.

Issue 1:

I don't really understand this, but it looks like the approach could be determined only by understanding the build process and it should probably, at least in some respects, be driven by those responsible for build.

Posted: Thu Mar 01, 2012 6:03 pm
by Pathfinder-ICF
Updates -

Issue 1: I finally traced the problem to a logical disconnect between ITSM and applications development, resulting from the organization's use of ITIL in the development world. Based on what I found yesterday, here's my updated take on the situation.

Service maps typically look to executable / run-time applications that are linked to services and the hardware infrastructure. The tool this company uses for incidents, problems, changes, etc., reinforces the focus on run-time code, in fact. When dealing with infrastructure hardware, like servers, network devices, et al., this makes sense, and is pretty cut and dried.

However, there is an internal requirement that the support groups also map every "source code" CI in the CMDB as well. Note that this is a different CMDB than the one that tracks the run-time components and incidents/changes/et al. The 2 CMDBs are not linked to the best of my knowledge, but I could be wrong on that.

For this support team, this is where the problem arises, as our code (typically in the form of Java files) is embedded with other applications.

Since I am no longer as technical as I used to be (my role here in fact is in SLM), the closest I can relate are the client/server DLLs we used to use. In a number of cases, clients purchased class libraries and incorporated them into their home-grown c/s applications.

Same concept here, only the "DLLs" are in fact Java files developed internally and then embedded into the main applications, and therefore invisible to anyone at run-time.

Posted: Thu Mar 01, 2012 6:14 pm
by Pathfinder-ICF
Issue 2: I agree 100% with you, Diarmid. It is another example of the classic finger-pointing I've seen in IT for years - - my application can't possibly be broken, so obviously it is someone else's fault!

Part of the issue stems from the plethora of tools, and the rather loosey-goosey way some of the "CIs" have been set up. There are apparently more than a few that are logical CIs that point to our realm that get used. I am also hampered at the moment by a lack of access to information that I am in the process of changing so I can get reports out of the incident tool. I want to start looking at the bouncing frequency compared with severity.

My thinking is also that we should formalize the relationship with the using applications to get away from the simple OLAs we have today. I'm thinking more along the lines of a defined Supplier Management service with an underpinning contract. I am getting initial pushback to the idea from my own group, as the focus is on change, incident, problem, CMDB and SLM. UC discussions also tend to put people to sleep apparently!

I can only imagine the reaction from the using application support groups if/when we trot the idea out!! :D

Posted: Fri Mar 02, 2012 5:37 am
by Diarmid
The number of databases that make up the configuration management system is irrelevant. configuration management needs to look at all aspects of the configuraion and make the whole information available in the areas it is used (such as change and incident management). If two sets of configuration information are difficult to relate to one another then configuration management as a function may be on the verge of being broken.