Create an SDA Application that implements a hotfix or workaround Hot

by Scott Hofmann on June 23, 2016

For some product issues that arise, where a workaround or solution must be performed that entails the running of a script or performing a series of server administrative tasks and scripting steps, we could create an SDA Application that performs the whole workaround. For example, Case 5485277 Desktop Baseline Save as  - the CM defect that $G$G not getting updated during commit because of pulse table updates versus original DimCM tables defect could have been resolved with an SDA Application but instead a PS consultant or the client must run scripts until a hotfix or patch is applied.

Using an SDA Application offers Serena the opportunity to turn a negative client experience into positive experience by giving the client an easy solution, makes for an easy implementation for Support or Professional Services and could result in a new sales opportunity.

  • For some product issues that arise, where a workaround or solution must be performed that entails the running of a script or performing a series of server administrative tasks and scripting steps, we could create an SDA Application that performs the whole workaround. For example, Case 5485277 Desktop Baseline Save as  - the CM defect that $G$G not getting updated during commit because of pulse table updates versus original DimCM tables defect could have been resolved with an SDA Application but instead a PS consultant or the client must run scripts until a hotfix or patch is applied.

    Using an SDA Application offers Serena the opportunity to turn a negative client experience into positive experience by giving the client an easy solution, makes for an easy implementation for Support or Professional Services and could result in a new sales opportunity.

    This suggestion offers the following benefits:
    1) provides an automated solution that solves the problem. Since SDA tends to force an abstraction of the process steps from the environmental proclivities of a client’s server and network environment, the actual resulting application should be more reliable. Creating a script is often a task that we are already performing so this burden is already an expenditure of time that must be expended.

    2) It rewards a client that already owns SDA. If a client already owns SDA, then the solution is easily deployed and used. It reinforces their loyalty and might inspire them to purchase another agent license for the SBM or CM server if they did not have one already.

    3) It encourages our clients to learn about SDA. If a client does not know about SDA, they might be inspired to learn more. Compared to opening a command window and typing in a series of batch script commands, the execution of an SDA Application in SDA is really easy to execute. The instructions for the workaround would show a stark contrast of how loading and running an SDA Application verses the series of steps and scripts.  

    4) Isn't SDA available for evaluation with 1 agent? If so, client could be encouraged to download and use the evaluation copy of SDA to solve their problem using the Application. They might become an SDA customer if the experience is easy.

    5) Members of other Serena organizations outside of SDA R&D would have to learn how to use SDA. This may inspire more cross-product considerations of the use of SDA. For example, developers or Support engineers might be inspired to consider using SDA for installation, or configuration tasks like updating key stores with SSL certificates.

    6) 1  more reason to buy SDA.

     
    The disadvantages are as follows:
    1) Additional burden required to create a workaround or solution.

    2) Installation of SDA complexities can arise based on unique client environments. The SDA installation could backfire and cause client more issues that result in Serena supporting a product that client has not bought.

    How to do it:
    The implementation of this solution is critical to the success or failure of this suggestion. In other words, I think people should be allocated to this project to make this work. It could be considered a marketing expense. I recommend that someone from the SDA or Professional  Services team is assigned to act as a 'Services' consultant to Support, CM, SBM and SDA R&D teams. The SDA consultant will perform the following:
    1) Determine the types of workarounds that this solution can be used to solve.
    2) Define standards, conventions or an architecture for how Serena will create their own process Applications.
    3) Start working with R&D and Support by making the first 5 Process Applications. Hone the process and update the standards, conventions and architecture.
    4) Each R&D product team must identify 1 person to be the lead on this endeavor. The product lead person will be trained and mentored by the SDA consultant to make the SDA Applications.
    5) SDA consultant will train the Support team.

    Future possible implementations:
    The program can be expanded to provide a ‘client server’ managed by Support so that customers can have upgrades delivered from Serena using SDA to an agent on their server. I know, there are security issues to overcome but I think using the SDA agent / and agent relay architecture, we may be able to overcome security issues.

  • Please login to view any attachments.

  • There are no user comments for this idea.
    Already have an account? or Create an account
     

PrintEmail

Recent Tweets