Quiz Question: If Capital electrical platform engineering software stated its’ version at the first year of release at 1.0 and we moved through a new number before the decimal point to denote each new version the current version instead of being called 2013.1 would be called what?
Answer: By my calculations, I believe it would be Version 9.
What’s in it for you?
This Blog post is a little bit longer than usual. I advise you to read on because any enterprise implementation of Capital or VeSys leaves value from using the software untapped by not keeping up to date with the new releases. If you get your upgrading policy right you save potentially tens of thousands of person hours and millions of dollars over the many years you will use Capital to manage design, define, build and service data for your products. More time, more money. Lots of it.
In close to a decade of the Capital Software being released and in productive use by customers the world over, there have been plenty of situations in which the tension of available benefit versus the work to transition to the latest version can be seen.
It is a balancing act. And when one side or the other exerts a winning force, the effect is to promote the desire to move to a later version, or to suppress the adoption of the later version.
The later the version of the software – is an indicator of better quality more usefulness, because more new features are contained in Capital.
It is difficult to calibrate exactly how many new features there are. What is your definition of what is a new feature and what is not? Do you count extensions of existing features as new? So your personal preference for understanding what level of new functionality is the unit of measure may affect the results. My answer is an average of 115 significant new features per year according to my definition & a count over the last 4 years.
- Furthermore the user community has fed into the software reports of bugs to be fixed – so your software becomes more stable over time.
- Plus, you may have contributed to the enhancements which have come into the newer versions of Capital or VeSys by logging your suggestions via the Mentor Graphics’ Ideas web site. In these cases your motivation to bring forward these new features into production will be considerably stronger.
Do you have technical resources and knowledge to perform the upgrade?
Not enough: Use Customer Support Division to boost your expertise, answering your questions via the maintenance agreement you have with Mentor Graphics, or taking premium services on a paid-for basis from the Mentor Graphics Customer Support Division experts. If your bottleneck is that you lack system administrator time and staffing, or have not the budget to devote to this goal, there is a limit to a person like myself as your software vendor can do. The answer is to look ahead to your annual maintenance strategy and be proactive. The cost of ownership of enterprise class software should be acknowledged to be one involving providing for the maintenance and uprating of the environments involved.
Gaining confidence that the latest Capital Software is adequately acceptance tested.
Mentor Graphics very thoroughly tests each release and service pack. The scenarios cover different data sets, some of which are donated by customers and are covered by non-disclosure agreements so I can’t tell you which ones, and what areas of the software are covered. What I can say is that test conditions include load/stress testing and using different hardware configurations. Replication of customer patterns of use of functionality takes place too of the different “design flows” of Capital as QA/testing procedures are followed.
Information Technology Infrastructure tasks, and end-user engineer tasks for a successful upgrade.
Beyond what the maker of the software does, each customer testing the software under their own usage conditions is normal. And here is where some risks for you need to be managed:
IT people understand the need to regression test, coverage test, and ensure response test benchmark timings come out clear. IT people understand you need to give a “thumbs-up” on these areas, however they know they are very seldom the right people to do it. To give the tests fidelity to the actual practical use to which Capital is put on a daily basis, the actual practical every-day users of Capital really should be the ones doing the tests. IT may devise a test plan, and develop metrics for the testing.
There is more than Product Engineering users often realize in marshalling the IT resources to perform the software upgrades. Plans need to be put in place to validate how the upgrade will migrate the data, and the mechanics of how to release the client binaries to your computer, hook-up the customizations and plug-ins have to go through careful validation. A halt in production is to be diligently avoided, a loss of service to users equally so. And finally your corporate IT professionals help is often constrained to a window of opportunity to perform the upgrade. Sometimes a project to upgrade is jeapordized because “all hands” are diverted to different priorities. Secure your commitments from IT early and hold promise makers accountable for what they say so they become promise keepers. Freezes on activity because of hardware or other software uplifts can also intervene. Whether the tasks are insourced or outsourced or flipping between the 2 can be significant and introduce delays. Upgrade projects have to be managed carefully from an IT perspective.
Product Engineers with production experience.
Hands-on-the-application-engineer users replicating the workflow as far as possible on a test system are also needed.
o Oh, and the environment should aim to be very close to the production environment too. Almost identical is attainable, full replication preferable.
o Oh, and those every day users, guess what, they are often using the Capital software, well, hmm, every day, and it is not easy to stop them so they can work on a test system. Because they are working on a live production system, doing designs for real customers, and it isn’t quite the same priority to stop these users doing that to make sure they can do designs more efficiently with new features in the new version some time in the future.
o Ohm and another thing, whilst we are on the subject of new features on Capital for corporate-wide consideration there are usually at least 15-20 new features for which there should be exploration of the business case and the technical detail of the functionality in order to evaluate a proposal that one includes them in the workflow/best practices. To do this you have to have some of the valuable time of those day-to-day engineer users to see whether best practice going to be better best practice.
The requirement is for documented, clear test plans. The people who can do this are subject matter experts on your staff. You need space in these experts calendars to review the results, report and resolve any issues on top of time operating the tool to test.
It is a familiar story of the management of scarce resources. Skilled users, knowledgeable people who know about the workflow and the details of the software in the process – they are in short supply.
If you find these people – hold on to them. Because upgrading to the latest Capital software like other crucial systems in your business does come down to human expertise as the critical factor in tipping the scales one way or the other. Someone sometime has to do some work. Schedule for it, budget for it.
Costs and Benefits of Upgrading Capital.
I’ve reviewed some of the areas of concern which pull you in the direction of upgrading, and of course there are some often strong counter-pressures pushing you back to staying with the version you are on.
Articulation of the “Pro” side shows features driving efficiencies and business benefit, and on the “Con” is the cost of ownership. You know your own environment better than a summary/abstract from me here can start you off developing some metrics.
It is sometimes hard to for Capital users to get a picture of the true costs on one side of the argument, let alone both. Perception of whether an upgrade could/should happen is seldom a clear debate. The deciding factor can be whether the IT department can sandbag/tough it out/ lie low as the Engineering users run out of steam with their desire for service. You have to be forward looking enough to plan for maintenance with Capital like you plan for maintenance with other enterprise tools.
Getting on the latest software is always beneficial. Doing so takes planning and resource allocation and is a vital part of your ownership tactics. Just like taking your car in at regular service intervals is part of what you accept when you take ownership – it is an annual investment which pays off very well in longevity and utility.