ANNOUNCING THE ENTERPRISE OPERATIONS CONSOLE 2.1 RC 2 - NOW AVAILABLE!!

Talk to us about the target environment for EOC, please?

• Where is it "required"?
• Where is it simply "nice to have", but not mandatory
• In which network deployments is EOC "unnecessary"?

You know that is a really good point.   I would love to know more about it myself, and how to properly use it before i spend too much energy trying to figure out something that might not be a good fit. 

I had EOC for several years, thinking it was the right solution for joining three separate businesses that had merged.  Each had their own Solarwinds NPM/NCM/NTA deployment.

It wasn't the right product for that need.  I wanted something that we'd all treat as a shared resource, not something that kept the three companies divided.  EOC was slower to update than looking at the individual NPM instances' home pages, and it cost more, and was clunky.

I ended up changing the licensing of all three sites--removing two main instances of NPM/NCM/NTA, getting rid of EOC, and running seven APE's under one main instance that we ALL looked at.  This was the right solution--it shows ALL my sites equally, treats every one of those original three businesses as just part of a whole.  Now my Network Analysts all respond equally to any errors, any alerts, any site, any network room (of ~300 network rooms, across ~100 sites/facilities).

The beauty of doing this was in part the simplicity of getting rid of overlapping IP address spaces.  If you can't do that, then EOC is a good solution for monitoring them separately, using multiple main instances of NPM/NCM/NTA.

When I got rid of two of the main instances of NPM AND removed EOC, licenses and support costs decreased while performance improved dramatically through all switches/routers and APE's ending up at the same main poller.

Later, moving to NAM licensing enabled me to further reduce annual support contract costs while increasing APE count AND increasing element count and server/volumes counted, while simultaneously adding in UDT, IPAM, VNQM, and HA.

To get that much more functionality AND pay a lower annual support cost was a big win.  I'm glad I jumped on that train as soon as I was aware of NPM, because I was able to get a much-improved price from our SW SE, since NAM was not getting as much attention as they wished.  I don't know how pricing has changed since then, only that I'm staying with NAM.  And that I don't have to pay any more for adding up to 20 APE's to monitor up to 100,000 elements.  And I'm doing it across three states without EOC.

On the other hand, in EOC's favor, there are conditions where EOC is the better solution:

• If you have overlapping IP addresses/subnets in various sites
• If you have too many nodes/volumes/elements to monitor with just NAM licensing
• If you have teams that are specifically responsible for certain networks, but not for others
• If you also have a higher-level team (or teams) that need the big-picture view of how ALL networks are working, and they want a single place to view them when a single Main Instance of NPM can't handle all the elements/volumes/interfaces/nodes
• If your organization is spread across so many time zones that it becomes confusing or impossible to properly support and manage multiple networks with a single Main Poller.  In this case, having multiple Main Pollers' information aggregated into one view with EOC gives everyone a big picture idea of what's happening, while still allowing local/regional Solarwinds Admins and users to see their own local NPM instance that is in their own time zone.  EOC is probably a nice solution to a network monitoring need that takes into account multiple countries across a dozen time zones.

In these cases, EOC is the solution to aggreate multiple main instances of NPM, and show the overall results of the network.  EOC also makes it easier to work from just one location and still push out changes and make measurements and plot trends across the entire organization.

Which one works best for you?

Not sure I need to add anything more here as rschroeder​ did an excellent job detailing out when it makes sense to use the Enterprise Operations Console.  I would like to add to his list:

• If you have overlapping IP addresses/subnets in various sites - JB - This can also be addressed by using a single instance and Additional Polling Engines.
• If you have too many nodes/volumes/elements to monitor with just NAM licensing - JB - Note, that as of the release of 2018.2 Core (NPM 12.3), a single instance of Orion can scale up to 400,000 elements.  So this may highlight an increase in current EOC users performing a transition similar to what Mr. Schroeder described above.
• If you have teams that are specifically responsible for certain networks, but not for others
• If you also have a higher-level team (or teams) that need the big-picture view of how ALL networks are working, and they want a single place to view them when a single Main Instance of NPM can't handle all the elements/volumes/interfaces/nodes
• May also come into play for a MSP or any client that does not have dedicated access between sites, or even requires local monitoring/management access for geographically dispersed environments. 

Likely, there will always be a situation in which certain customers may need to run a distributed deployment.  We need to provide the ability to have a consolidated view across that deployment type, and we hope to start investing more heavily in features that make sense for that target customer.

What features, for the users that fall into the categories above, are the most important to you that need to find their way into EOC?

RC2 Is now available!  You may access the RC Forum to download the latest bits, or they will be available from your Customer Portal.