Standard application functionality CM or Not

[Worac]

We are using Oracle ERP and want to change the restriction on passwords from 6 characters to 8 characters. This will be done through standard functionality within the application.

Can anyone tell me if they consider this a candidate for the CM process?

It seems that we are taking CM a little to far when we start reaching into application provided functionality.

[dboylan]

It sounds like you talking about making a change that will affect both written organizational Policies and affect training documentation. If this is the case, and you have version controlled your documents, then yes. You are in fact making a change that will affect the Attributes of items that should be considered Configuration Items.

I say "should be" because I don't know how mature your Configuration Management process is. But even if your Config process is non-existent, you should think in terms of "Would this change affect hardware, software, or associated documentation that should be kept in a controlled state?"

[Worac]

dboylan,

Interesting perspective that I had frankly not considered. I was looking at it more from the point of view of where do you draw the line when using standard functionality within an application.

I am now thinking that any configuration/setup change that might change the way an application works or how the user interacts with the application might be a candidate. Like you indicated, this would also potentially change the policies and training documentation as well.

Thanks for the feedback.

[UKVIKING]

Worac

Also,

think this way as well

1 - Development environment - loose to no configuration or change from an operational POV. Version & revision control applies to code and packages

2 - UAT / Testing Environment - Medium control from a operational environment. You want tto have the UAT & Live environment as == as possible.

So Configuration of the h/w & version of the S/w are kept. and changes to the environment are controlled.

Version and revision code kept.

This is where you write the documentation and test the documentation against the application....

3 - Live - tight control. Push to live for application and documentation in parallel. May have a staggered roll out / training etc...
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[Worac]

UKVIKING,

Thanks for your comments as well. We have restled with having to create RFC's for changes to a Dev instance. We have a fear of never getting any work done if we guard it too tightly.

[UKVIKING]

Womac

There should be a live change control when there are systems added to any environment.
Or O/S or other S/W upgrades and patches.

If you track Databases as CI that are 'permanent' and are created outside of dev tools, then track via change.

If in dev you use some sort of version control, that is your change tool for your work....
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[Guerino1]

Hello Worac,

[Worac]

Frank,

Make sense. We have a long way to go before we are that mature, but it gives us a goal.

[Guerino1]

Hello Worac,

[dsemeniuk]

Hi Frank,

This is what we are struggling with. We have defined our change management process as "gate keepers". So any promotion of code to any of our environments, excluding development of course, requires an RFC.

We are not at the point of how to handle software changes up front with RFCs, we are just getting knowledge of "releases" when they want to be deployed into an environment. But I want to change that like you laid out in your previous post.

How do you track the "release" through each environment without an RFC, how does that process work?

Example:

Somebody wants to change our application because of an incident or the business requested a new feature, so an RFC is submitted, lets say its to fix a defect found in production.

So the user enters RFC stating the change.

This goes to CAB for review.

Everyone agrees, the change is needed and approves the change.

What do you put in the proposed change date? As in when does the requestor want to make this change. Now, to us this means put change into an environment, not actual go and build.

How do you scheduled the actual change date (we have these on our RFC forms as to when the change will be implelented), would this mean when will it be deployed to production?

What CIs do they pick, say they are changing the current version of XYZ 1.0, they would link the RFC to this, but they would also need to create a new CI XYZ 1.??

Now they go in development and make the change, compile the code and test it and are ready to deploy it to our testing environment. How does the current RFC track this and as well track the CI status/lifecycle? Do you enter another RFC to request deploying XYZ 1.?? into Testing? How does this get approved to go into the testing environment? As we track CIs in our testing environment. Once XYZ 1.?? goes into testing, we would update our CMDB to reflect this, XYZ 1.0 would lose its relationship to the server its installed on and we would create a new relationship to ZYZ 1.?? to that server.

Hope this came out right and you understand where I am going with this.

Thanks.