Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
0 Kudos

Overview :

In the fast changing IT world there is a demand of constant and rapid development cycle from Customer. It’s very difficult to manage the all these developments effectively and efficiently without proper tools. There may be so many tools available in the market to track the development and project cycles, but when it comes to SAP, they have their own proven product for this purpose, Solution Manager.  This document is just a try to figure out how
we can handle agile development model in solution manager. Please feel free to add comments, suggest as this might be one of possible way to handle this area in Solution Manager. Better possibilities or ideas are more than welcome :smile:

Agile development is an alternative to traditional project management where emphasis is placed on empowering people to collaborate and make team decisions in addition to continuous planning, testing and integration.  It includes constant new developments simultaneously. It’s been proven that SAP’s Solution manager tool is capable of handling the Project developments very efficiently and effectively using CHARMs and other
functionalities.

I have come across one of the client requirement as they wanted to follow an agile development model. There will be so many new things which they want to develop and test as part of Release cycle. An “idea” which will be helpful for the business will be added to a queue every time after business authorities approve it. Every idea will be then developed under either Minor or Major release cycle based on the functionality and scope of idea. 

            Implementation methodology :

Following is the landscape diagram I have consider for this exercise.  We need two separate projects in the Solution manager system. It is assumed that both projects are having CHARM’s and retrofit functionality activated. 

Image 1.1

About Projects

                   Weekly_EF project:

This project will have three tier architecture as shown in Image 1.1

Development – Test – Production.

The project scope is to handle weekly emergency fixes. This project will use Urgent Change document and will follow the CHARM process for production movement. Changes will be moved to production once a week. The "day" can be decided with customer's mutual understanding.

(Refer Image 1.1, lines marked with red colour) To keep all the systems in the landscape in sync, we need to schedule an auto movement/retrofit of changes from Weekly_EF project to Release project. (Please refer Retrofit functionality for more details)

         

                   Release Project :

This project will have three tier architecture as shown in Image 1.1

Development – Test – Production.

Development system (Rel_Dev) will have two clients. One (Client 410) will be used for development and another (Client 420) for Smoke and sanity testing. 

The project scope is to handle Releases. This project will use Normal Change document and will follow the CHARM process for production movement. Minor as well as Major release changes will be carried out as per defined schedule. Changes will be moved to production based on the same. (Refer Image 1.1, lines marked with red colour) To keep all the systems in the landscape in sync, we need to schedule an auto movement/retrofit of changes from Rel_Dev project to Weekly_EF project systems (EF_Dev and EF_Test).

We will have to create "CHARM Categories" as Major and Minor changes to differentiate the identities while reporting. Normal change document can be customised as and when required to match the customer requirement if any.  Suggested method of CHARM usage is to create a separate CHARM document (Normal Change document) for every idea in the development environment to have its unique identity. In short there wll be always 1:1 relation in Idea and CHARM created in the Release project.

            Development in Agile way :

We will be having agile development in Release project cycle only. As mentioned above, Weekly Emergency fixes will use Urgent Change document and continue its journey to production as per defined CHARM process.

Customer requirement is to have continues development as and when new idea comes in a queue for development.  These ideas will be developed in Rel_Dev system (Client 410 where rapid developments in agile way will be carried out) and once ready and tested them in client 420, with customer approval this particular development will be moved to Rel_Test systems.  There will be a Categorisation to differentiate change identify as it will be under Minor release or Major release change. We will have an action profiles designed with conditions to make sure only customer approved changes are getting moved to test system in Release project.

By using CHARM functionality we will able to utilise features like “Cross system object lock” and “Downgrade protection warning message”. These features will enable us to identify the threat of overwriting the developments in case any object is in conflict or locked. This will reduce the risk and will help to keep all the systems in sync. 

By using these functionalities we can handle the rapid developments through Solution Manager System effectively.  In case of refresh of systems, basis should refresh the release environment only when a major release will be moved to production. In case of refresh after Minor release, basis should take
appropriate backup of all the ongoing developments and make sure that it’s available as it is after restore.

 

Labels in this area