Since both GC and VCDS can be used with multiple NETeXPERT systems, the need to have multiple copies is normally determined by the visibility needs of the end-user. In the case of GC normally the end-user is in the NOC or on a support team and if the division of labor for those people would normally show only some of the total NETeXPERT systems then there might be a reason to have multiple GC Servers with the NETeXPERT systems segregated between them to accomodate the end-users better; I believe that this is essentially the case with [a nationwide wireless provider running Fault Central], they have two seperate groups that are responsible for different segments of their network and thus NETeXPERT Gateways.

In the case of VCDS the end-user are developers or at least people working with the developers doing release management for Rules. In this case the desire to have multiple VCDS systems would probably be driven by the commonality of the Rules in the systems. That is if you had 8 NETeXPERT systems, but 4 had Rulesets A, B, and C and 4 had Rulesets D, E, and F with no overlap then it might be wise to set up two VCDS systems in order to make sure that it was clear which items were actually missing in a system versus those that were just not applicable. This is the case for [another nationwide wireless service provider using NETeXPERT Fault Central] where they have Rulesets that process alarm data in serveral NETeXPERT systems and the Alarms for those systems flow to upper NETeXPERT systems that have Rulesets related to processing those Alarms.

The other time that you might have multiple VCDS systems would be when you have multiple development teams who work on different Rulesets. The licenses that Longview offers allows a single server to run for production and another server to run in a non-production role; normally I would refer to that as a "development role", but it could be used in any way as long as it wasn't tied to a production NETeXPERT system. So I can imagine where the developers on each team have their own non-production VCDS systems there they coordinate their work and sync up with a test or release system. In this case the production VCDS system would show the test/release system for each of the teams and the production system. This type of usage would allow the developers to have a much clearer picture of who was doing what in their area of concern so that they could coordinate better and it could enforce business rules related to how work product traveled from development to production.

BTW, GC could be used in a way that would segregate the development and production systems as well. In the case of [one large NETeXPERT customer using NETeXPERT for nationwide DSL activation] we discussed selling them an additional GC non-production license so that they could control the Gateways in their test environments seperately from development, but also allow them to deploy their Gateways from test to production without any possibility of deploying from their development systems to production which is technically not allowed. During the discussion with [this customer] we contemplated that the cost of a non-production license for the product would be less than 50% of the price of the standard license; that is that the price of the production copy actually represented more than the cost of the non-production copy in the standard license.

We hope this helps you in how to use VCDS and GC.
Add Comments