CHARM - not so charming - or is it?

CHARM - here's what I thought about it before using it.

It will:

• Remove conflicts between developers.
• No missing objects.
• Transport objects outside of SAP.
• Defects
• Less transports

This is living in Michelle's world of what CHARM does - not what it claims to do.  So looking at the diagram - that you can barely read.  I, as a developer,  would make changes to an object.  There would be changes in an outside system.  developer 2 would also make changes - he would need a different object.   All of that would be bundled and moved by Charm to various different systems.   Emergency and Non-Emergency transports will be taken into consideration.

Dum, dum, dum - drum roll - Charm to the rescue!

So was my vision correct?  Actually - yes.  But...  There is always a hesitation.

In practice:

1. The transport for the release is created with a some changes to a table.
2. Emergency transports are transported as they are complete.  They are emergencies.  The emergency contains new fields for the table.
3. A developer is working on a regular transport.  It is using the same object as the emergency transport.   The developer backs out their changes.   Once the emergency is transported to production,  the developer puts back their changes.   The table is not changed from step one as it is working correctly.
4. Everything tests clean.
5. The release is ready to move to production.   All emergency transports move first.   Everything is great!
6. Regular transports move next.  The regular transport removes the extra fields added by the emergency transports.  It returns a 8 code.

So at this point their is an object in production that is broken.   To fix, the table with all the fields must be moved.  Then the emergency, and then the regular transport.  YUCK.  Now you get to explain why there was an error.  If you have trouble following the steps above don't feel alone, my BASIS group was ready to scream at me a couple of times.  They didn't, because they were too nice.

In theory - all transports will go to production.   In practice, they don't always go.  So the changes are backed out, and the object is grabbed by a different developer.   Now each time the transport for the new development is moved between systems there is a conflict...   Now your developers can no longer move emergency transports without BASIS help.    The batch job will not automatically move transports that are in conflict.   And that is what CHARM is supposed to do.  So your BASIS group still gets calls.

In theory - only one developer works on the object at one time..   Let me say that again ONE developer works on an object at one time.   In practice, there can be more than one working on the object.   Not a big deal, if they are all working for the same project.   But if they are not, there are two options.  Either have the object in two different Charm requests or put all the changes in one Charm request.   Either one will give you issues.   If you think about it, you always are doing more than one object for a project.   So one of your objects in someone else's Charm is bad, very bad.   Testing will be impossible.  If one doesn't move the other one shouldn't.  Now your projects are dependent on each other.   Another point, we are getting too used to conflicts.   It's making it harder to know when objects are really in conflict or when something just hasn't moved to production, and we can make changes.

In theory - When a new table is created, you as a developer will notice it is created and not moved into production.  You will either not use it, or you will note the dependencies between your Charm ticket and the other developer.   In practice...   Well let's just say we all aren't as good as checking for that.   So, yes, objects can transport without the other objects that they are dependent on.

OK - my anti-CHARM rant is done.   And yes, my BASIS friends may tell me some of this is configuration - in fact I hope they do.   Here are the things CHARM does well.   And it does them very well.

• Limit the transports - for a normal change, when I release my transport task, a background job "moves" them to our test client.   The transport request stays open.  If the test in the test client fails, then your request is still open, and you can use it.   A task is created under the request.   So now instead of moving many transports to production.  Only one transport request will move with many tasks.
• Group configuration transports and development transports in one Charm request.  We don't need to keep track of those dependencies.
• Defects - defects are attached to already released CHARM requests.
• Locking the test environment down.   Once the entire release moves into testing - no regular transports can move to the testing system.   Emergency transports can move.  This can cause issues with last minute changes.  It can also help to limit those last minute changes.
• The approval process is at the front end.  Transports can't be created until the project is approved.
• I'm not sure about outside objects.  We haven't used that part of CHARM yet.

So there is my CHARM review.  This is from a developer's standpoint.  And please know that like everything in SAP, CHARM will be configured differently in different companies.   So some of what I've written may not apply to you.   Does CHARM do what it claims to do?   Yes...  Does it do what you think it should do?  You be the judge of that.  Personally, I think it has made things easier.  It is not a silver bullet.   There will always be some issues.

Please comment with some pros and cons that you have noticed.   And let me know if I'm out of my mind on some of what I wrote.    (Hopefully not all)