Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: waynegretzky11
New Today: 3
New Yesterday: 67
Overall: 148302

People Online:
Visitors: 60
Members: 1
Total: 61 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - Embedded software frameworks as CIs
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Embedded software frameworks as CIs

 
Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management
View previous topic :: View next topic  
Author Message
Pathfinder-ICF
Newbie
Newbie


Joined: Feb 29, 2012
Posts: 3

PostPosted: Thu Mar 01, 2012 2:42 am    Post subject: Embedded software frameworks as CIs Reply with quote

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?
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Thu Mar 01, 2012 4:06 am    Post subject: Reply with quote

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.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Back to top
View user's profile Send e-mail
Pathfinder-ICF
Newbie
Newbie


Joined: Feb 29, 2012
Posts: 3

PostPosted: Fri Mar 02, 2012 9:03 am    Post subject: Reply with quote

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.


Last edited by Pathfinder-ICF on Fri Mar 02, 2012 9:17 am; edited 2 times in total
Back to top
View user's profile
Pathfinder-ICF
Newbie
Newbie


Joined: Feb 29, 2012
Posts: 3

PostPosted: Fri Mar 02, 2012 9:14 am    Post subject: Reply with quote

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!! Very Happy
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Fri Mar 02, 2012 8:37 pm    Post subject: Reply with quote

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.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Back to top
View user's profile Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.