Your SlideShare is downloading. ×
Becoming Software Oriented in a Solutions Centric Industry
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Becoming Software Oriented in a Solutions Centric Industry

329

Published on

by Andy Roth, Tekelec Presented at SoftSummit 2010

by Andy Roth, Tekelec Presented at SoftSummit 2010

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
329
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Becoming SoftwareOriented in a Solutions Solutions-Centric Industry Andy Roth, Tekelec 1
  • 2. Becoming Software Oriented in a Solutions- Centric IndustryProblem OverviewProduct AttributesImplementation ChallengesProduct CompositionLicense ModelsApproachConclusion 2
  • 3. Tekelec Tekelec, the session and mobile data management company, enablesbillions of people and devices to surf, talk, and text. Our solutions allowservice providers to dynamically manage network resources and services, p y y gwhile providing end users with a consistent and personalized customerexperience. We handle the complexity of today’s multi-generational andmulti-vendor networks by enabling devices, protocols, services, anddatabases to securely and efficiently communicate with each other. Tekelechas more than 30 offices around the world serving more than 300customers in more than 100 countries. 3
  • 4. Problem Overview Telecom systems possess a distinctive set of attributes and challenges.These products fit somewhere between embedded devices and enterprisesystems. In particular, we need to address the following: • High Reliability—five 9’s+ • Less than one hour downtime per year, typically zero • Operationally live updates, upgrades, and feature activation p y p , pg , • Controlled configuration engineering for any changes • Pricing that reflects value—not in a commodity space • Moving from hardware centric to software centric business processes 4
  • 5. Product AttributesFront Loaded Fulfillment • HW Centric and Sales Driven • Product Quality—For a smaller company this is a primary driver – In the core of the network – Quality metrics are industry reportable • Reputation—Outages are FCC reportable. Telecom is a small world • Price—Price is negotiated from RFx to quote to contract •CCapex C lCycles—Closely ti d t i d t b i cycles Cl l tied to industry buying l • SOX/RevRec Challenges drive tight quote to delivery coupling5+ 9s • Requires Engineering/Dimensioning • Every change must evaluate the system as a whole • Not well suited to a Customer-Pull model • Must protect the Customer from engineering/dimensioning errors • Customer statement example • If a central office switch goes down, we make the local news. If a signaling node goes down we make the national news. We’ve never made the national news. 5
  • 6. Product Attributes (Continued)Reluctance of Customers to share revenue • Infrastructure/table stakes products • High ROI--recurring benefit from purchase • Very competitive p y p pricing in Customers offerings g g • Telecom market is cutthroat especially with all-you-can-eat packages. Customers want maximum benefit and want to keep the profits • Our products can offer competitive advantagesWant to minimize SKUs • Complex dimensioning • Systems are engineered for each Customer and situation • Want to simplify guided selling • Globally distributed sales force across complex product linesWant to decouple product structure from licensing platform as much as possible • Sales fulfillment platform • Core OS and product platform 6
  • 7. Implementation Challenges•Can be difficult to instrument real-time high performance applications real time•Cannot adversely affect performance--Call flow is ALWAYS top priority•Provisioning can result in major product configuration changes and may bedifficult to turn off•Requires systems level dimensioning and engineering•All extensions and upgrades must be in-service pg•Critical to keep installed base accurate for support and extension quoting•Functional and Contractual Customers not always the same•Bringing legacy, new lines, and acquisitions into the fold 7
  • 8. Implementation Challenges (Continued)Entitlement Allocation can be diverse • Each product line has unique architectural requirements • Allocation to elements must be defined per product: System vs. Node vs. SiteVirtualization will add to complexityDistribution is seldom to end node • Dark Offices • Automated activation/registration not always straightforward • System Query not always straightforward •N t Network firewalls—End systems t i ll not on th I t k fi ll E d t typically t the Internett • Need to distinguish between Allocation and DistributionSystems not always turned up in timely manner • Third parties/agents • Warehousing • Extended installation windows 8
  • 9. Product CompositionCore Legacy Product • Embedded/monolithic modelBox Servers • Smaller open-systems based--price point drivenBlades • Larger systems that justify the entrance point form blade systems • Multiple products can occupy same physical system spaces • Shared elements must be allocated to some productVirtualization • Take advantage of newer HW • Cores vs. threads—minimize application changes • Mi i i f Minimize footprint and power/heat i d /h • Will need anchor point to protect IP 9
  • 10. Product Composition (Continued)Custom C fiC t Configurations ti • Each system must be custom configured to meet Customers needs. Not a toaster or consumer model • Built from common base system configurations, but … • Dimensioning, provisioning, geography are installation dependentSystem Identification difficult y • Legacy identification was totally monolithic • System=Site=Node entitlement and fulfillment common for SW, HW, Features, Support • New products very different from legacy and back end systems • Complex architectures (not monolithic) • Geo di ersit means license ser ing ma vary b installation Geo-diversity serving may ar by installation— Needs a general solution 10
  • 11. License ModelsCapability • Core SW • Enable IP protection and fraudulent use prevention • Support Trials • E bl single i Enable i l image di t ib ti with M lti l application b C t distribution ith Multiple li ti by Customer • On/Off Features—Features often analogous to ProductsCapacity • Incremental • Sell capacity in fixed increments • Multiples of SKU for feature active at any time—Can be difficult to track • Aggregate • Sell capacity in multiple upper limits • Only one aggregate SKU active for any feature at a time • Preferred model –Preserves value pricing –Simplifies site manifesting Only one capacity model allowed p feature y p y per 11
  • 12. ApproachEntitlement Determination • Initial View • System • Site • Node • Element/VM • Now considering entitlement by Customer with fulfillment/distribution solved downstreamDistribution • By Flexera Account • Account defined as mapping to sites or systems 12
  • 13. Approach (Continued)Management g • Product architecture dependent • Per monolithic system or element • Central distribution from a system element y • Implement license management at infrastructure level common across all new product lines • Applications implement functional restrictions.Implementation (WIP) • Entitlement Engine • Support Contract Status • Line Items • “Installed Base” Data • Maps attributes into business rules • Product structure • Account structure 13
  • 14. Conclusion•Our challenges are common to companies migrating from HW Centric to SWCentric business models•Decouple sales, entitlement, and fulfillment wherever possible•Create an “Entitlement Engine” model to • Map to multiple product architectures • Provide legacy and acquisition path • Decouple as many attributes of the implementation as possible • Use the Flexera services•Complete thorough use case and requirements analysis and modeling•Get Help 14
  • 15. Questions? 15
  • 16. Thank you y 16

×