Twenty-two pages on the Cisco Enterprise Agreement tier-design decision across Networking, Security, Collaboration and Observability. Smart Account hygiene, growth-allowance arithmetic, true-forward economics, the Catalyst subscription transition and the Splunk and AppDynamics rationalisation inside the EA Observability suite.
The Cisco Enterprise Agreement is a three-year, suite-based commercial wrapper covering networking, security, collaboration and observability product groups under a single anniversary. It is sold against the buyer’s installed Cisco footprint and priced against the installed-base metric for each suite, with an embedded growth allowance and a true-forward true-up applied at the anniversary against use that exceeds the allowance.
The publisher’s commercial logic for the EA is straightforward. The EA removes the per-product negotiation surface; it anchors the installed-base metric across a three-year window; it embeds an annual price uplift; and it pulls the renewal across all four suites into a single conversation. The buyer’s commercial logic for entering an EA is access to the suite-wide capability under a single commercial wrapper, the growth allowance that suspends true-forward inside organic growth, and the simplification of the procurement.
The EA negotiation is principally a tier-design exercise. Each suite carries a tier structure that maps the buyer’s installed base into a price band; the choice of tier (and the choice of which suites enter the EA at all) is the principal lever the buyer has at the renewal. This paper sets out the methodology for making the tier-design decision against the trailing-period evidence.
The Cisco EA covers four principal suites, each with its own tier structure, its own metric and its own commercial logic. Networking covers Catalyst, Meraki, Nexus and adjacent infrastructure with DNA Essentials and Advantage tiers. Security covers Cisco Secure across Umbrella, Duo, Secure Endpoint, Secure Email and Secure Firewall. Collaboration covers Webex Suite, Webex Calling and Webex Contact Center. Observability covers Splunk and AppDynamics under the post-acquisition consolidation.
Each suite carries an internal tier. Networking has DNA Essentials, DNA Advantage and DNA Premier for the Catalyst stack and a Meraki Enterprise / Advanced split. Security has the Cisco Secure tier set, with Umbrella, Duo and Secure Endpoint each carrying multiple SKU tiers. Collaboration has Webex Suite, Webex Calling Standard / Professional / Premium. Observability has Splunk Cloud Standard / Premium / Workload and AppDynamics tier sets.
The publisher’s framing positions the highest tier as the default because the highest tier maximises the publisher’s anchor. The buyer’s tier-design exercise contests this framing by reading the trailing-twelve-month telemetry and selecting the tier that the evidenced use actually requires.
The Cisco Smart Account is the licence-management construct under which all Cisco licence entitlements are managed. The Smart Account architecture, the Virtual Account topology and the consumption read inside the Smart Account together determine what the EA actually covers, and what it actually leaves out.
Many enterprise Smart Account topologies are accreted, not designed. Acquired entities sit in separate Virtual Accounts. Lab and production environments are co-mingled. Historical perpetual licences sit alongside subscription entitlements. The result is a topology in which the EA scope is unclear: which Virtual Accounts the EA covers, which sit outside it and which are duplicated.
The Admodum Smart Account hygiene protocol begins with a topology audit: every Virtual Account, every Smart Licence, every Right-to-Use entitlement, every reservation. The audit produces a baseline against which the EA scope can be defined and against which the trailing-period consumption can be read.
The Smart Account also carries the licence-conversion mechanic. Perpetual entitlements (held under PAK or under specific perpetual SKUs) can be carried into the EA under a conversion protocol; conversion converts a perpetual entitlement into a subscription seat inside the EA tier, but the conversion mechanic and the conversion economics differ by suite. The conversion conversation is part of the EA tier design.
Cisco Catalyst 9300, 9400 and 9500 ship with an embedded DNA subscription that is, in the publisher’s framing, integral to the switch. The DNA subscription has two principal tiers: DNA Essentials (baseline software entitlement) and DNA Advantage (broader automation and assurance capability). DNA Premier adds Stealthwatch and Identity Services Engine into the bundle.
The Catalyst transition is the move from the perpetual-licence era (where the switch shipped with a perpetual licence and software entitlements were sold separately) to the subscription era (where the switch ships with an embedded subscription). The transition has commercial implications. The Catalyst price line itself includes a subscription that begins at the date of installation and renews against the DNA tier; the absence of subscription renewal triggers a feature reduction over time.
Meraki sits in a different commercial bracket. Meraki devices are sold with a hard-attached cloud-managed licence that is required for the device to operate. The licence is sold in fixed terms (one, three, five and ten years); the absence of an active licence results in the device entering a non-operational state at the end of a grace period. The Meraki licence is not contestable inside the EA in the same sense as Catalyst DNA, but the term length, the licence-co-termination strategy and the EA-versus-stand-alone choice are all live.
Cisco Secure is the umbrella that covers Umbrella (DNS-layer security), Duo (identity and MFA), Secure Endpoint (EDR), Secure Email and Secure Firewall. Each carries its own tier structure and its own deployment metric, and the EA Security suite bundles them at a tier that maps the buyer’s installed base across all five.
The Security suite design exercise begins with the use case map. Which Cisco Secure products carry transactional use in the trailing period; which carry deployments but not use; which sit dormant. The map informs the tier selection inside the Security suite and the bundle-versus-stand-alone arithmetic.
The AnyConnect transition is the worked example inside Security. AnyConnect (the remote-access VPN client) has been folded into the Cisco Secure Client umbrella, and the licensing has migrated from the traditional AnyConnect Plus / Apex / VPN Only mix into a Cisco Secure Client subscription model. The migration timing, the renewal anchor inside the EA Security suite and the conversion mechanic against legacy AnyConnect entitlements are part of the tier-design conversation.
The Cisco acquisition of Splunk has consolidated the Cisco observability portfolio. Splunk sits alongside AppDynamics under a single observability commercial framework, sold inside the EA Observability suite or as stand-alone subscriptions outside the EA. The portfolio overlap (between Splunk Observability Cloud and AppDynamics Cloud) is the principal rationalisation conversation.
Splunk sells through three principal commercial frameworks: Splunk Cloud (workload pricing, SVC pricing, ingest pricing across editions), Splunk Enterprise (on-premise CPU- or workload-based) and Splunk Observability Cloud (per-host, per-MTS, per-trace pricing). The Splunk side of the EA Observability suite covers the buyer’s choice of these frameworks at a tier that maps the buyer’s ingest and host volume.
AppDynamics sells against the agent (Java Edition, Database Edition, Premium, Peak), with an agent-count-based pricing model. The AppDynamics scope inside the EA Observability suite covers the agent count and the agent tier. The overlap with Splunk Observability Cloud (both of which cover APM telemetry, infrastructure metrics and trace data) is the rationalisation question: which platform retains the workload, and which is decommissioned.
The rationalisation runs on the use evidence and the integration topology, not on the publisher’s preference. The Admodum Observability protocol begins with the use case map across the two platforms, the integration cost of migration in either direction and the EA tier-design implication of consolidating onto one platform or retaining both at a smaller scope.
The Cisco EA growth allowance is the contractual band inside which organic deployment growth does not trigger a true-forward. The band is sized at the EA negotiation and is typically expressed as a percentage of the EA installed-base metric for the relevant suite. Inside the band, the buyer can deploy additional capacity without incremental fees.
Outside the band, the true-forward mechanic applies. At the contract anniversary, Cisco reads the buyer’s deployment against the contracted installed-base metric. Deployment above the growth-allowance band is converted into an annual fee that applies for the remainder of the term. The true-forward is one-way: deployment above the band converts into fee; deployment below the band does not refund.
The growth-allowance design and the true-forward arithmetic are the two most contestable terms inside the EA. The growth-allowance band size, the metric definition that drives the true-forward calculation, the carry-over treatment between years and the renewal anchor are all live at the EA negotiation. The buyer’s position is documented at the EA close and forms part of the BATNA at the renewal.
The exit architecture is the post-EA position the buyer carries out of the term. The four exit patterns recur across the Admodum Cisco practice.
Pattern one: full EA exit, with all four suites moved to channel-and-stand-alone procurement, each licence renewed against its own SKU, and each suite rationalised onto its own commercial framework. Pattern two: suite-selective EA renewal, where the most-used suite (typically Networking) is renewed inside the EA and the others (typically one of Security, Collaboration or Observability) are released to stand-alone procurement. Pattern three: EA reset at a smaller tier, where the same suite mix is renewed but at a tier that more accurately maps the trailing-period use. Pattern four: EA non-renewal with perpetual residual treatment, where applicable, and a maintenance-only commercial posture for the remaining catalogue.
The exit architecture is documented as part of the renewal preparation regardless of whether the buyer intends to exit. The credibility of the exit position is what disciplines the renewal economics.
The Cisco EA tier-design paper sits inside a four-paper Cisco reading list. The companion papers extend the methodology into the adjacent commercial mechanics:
The methodology in this paper is the methodology Admodum has applied across more than twenty Cisco EA renewals. Each engagement is structured as fixed fee, contingency / gainshare or annual retainer, depending on the buyer’s posture at the renewal window.
A senior Admodum advisor will walk the methodology through with your CIO, CTO, Network Engineering Lead or procurement team on a private call. Engagements run as fixed fee, contingency or annual retainer.