Re: [cisco-voip] CUCM SU release cycle

2019-08-19 Thread Lelio Fulgenzi
You've hit a few more nails right on the head.

I'll add this, just 'cause it's so much more fun.

On more than one occasion, people have come back from EDU conferences, where 
they meet someone who says their system has feature XYZ and their team said it 
was easy. So we're asked to implement and given strange looks when we say it's 
not as easy as it sounds and needs quite a bit of back end work.

We're very forthcoming in the effort involved in doing something, I'm guessing 
other places simply re-priortize and get things done and don't mention the 
impact. 



-Original Message-
From: Pawlowski, Adam  
Sent: Monday, August 19, 2019 8:25 AM
To: Lelio Fulgenzi 
Cc: cisco-voip@puck.nether.net
Subject: Re: CUCM SU release cycle 

I agree on several points you've made. As we continue to "run lean" (meaning, 
in some cases, on fumes) and our management and leadership are bombarded with 
firms offering to deliver everything we do as a managed service that just 
fountains in over the "cloud", the reality of it is that we're compared against 
these claims.

We've built here a responsible and flexible service, with which we can offer to 
any of our customers a robust set of features. That being said we see on 
average a 4% take on features such as SNR, Jabber, etc. We are not aggressive 
in our marketing, and at times I'd term it elusive even, so we could do better. 
But that means that 95% of people will probably deal with the basics.

That is somewhat what I am trying to prepare us for, not building rube Goldberg 
line forwarding and shared line arrangements, and insisting on each customer 
having their own extension. I feel like if we switch platforms, or delivery 
methods, this will make things easier. Even this has been painful to implement, 
and not always practical. 

Regarding upgrades, we've limited ourselves to major upgrade windows 
biannually, and quarterly for SUs, non-critical COPs, etc. Despite everything 
being rubber stamped "24x7" , in reality very few things are. We push our 
maintenance to run overnight, or Friday evening into Saturday, and we go from 
there. IIRC you were cloning or rebuilding VMs within VMWare and juggling their 
connections to try and minimize downtime, but, we've found that as long as 
security and physical plant can operate in some regard, no one else really 
cares.

Best,

Adam
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip


Re: [cisco-voip] CUCM SU release cycle

2019-08-19 Thread Anthony Holloway
That's some good insight.  Thanks for sharing.

On Mon, Aug 19, 2019 at 7:25 AM Pawlowski, Adam  wrote:

> I agree on several points you've made. As we continue to "run lean"
> (meaning, in some cases, on fumes) and our management and leadership are
> bombarded with firms offering to deliver everything we do as a managed
> service that just fountains in over the "cloud", the reality of it is that
> we're compared against these claims.
>
> We've built here a responsible and flexible service, with which we can
> offer to any of our customers a robust set of features. That being said we
> see on average a 4% take on features such as SNR, Jabber, etc. We are not
> aggressive in our marketing, and at times I'd term it elusive even, so we
> could do better. But that means that 95% of people will probably deal with
> the basics.
>
> That is somewhat what I am trying to prepare us for, not building rube
> Goldberg line forwarding and shared line arrangements, and insisting on
> each customer having their own extension. I feel like if we switch
> platforms, or delivery methods, this will make things easier. Even this has
> been painful to implement, and not always practical.
>
> Regarding upgrades, we've limited ourselves to major upgrade windows
> biannually, and quarterly for SUs, non-critical COPs, etc. Despite
> everything being rubber stamped "24x7" , in reality very few things are. We
> push our maintenance to run overnight, or Friday evening into Saturday, and
> we go from there. IIRC you were cloning or rebuilding VMs within VMWare and
> juggling their connections to try and minimize downtime, but, we've found
> that as long as security and physical plant can operate in some regard, no
> one else really cares.
>
> Best,
>
> Adam
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip


Re: [cisco-voip] CUCM SU release cycle

2019-08-19 Thread Pawlowski, Adam
I agree on several points you've made. As we continue to "run lean" (meaning, 
in some cases, on fumes) and our management and leadership are bombarded with 
firms offering to deliver everything we do as a managed service that just 
fountains in over the "cloud", the reality of it is that we're compared against 
these claims.

We've built here a responsible and flexible service, with which we can offer to 
any of our customers a robust set of features. That being said we see on 
average a 4% take on features such as SNR, Jabber, etc. We are not aggressive 
in our marketing, and at times I'd term it elusive even, so we could do better. 
But that means that 95% of people will probably deal with the basics.

That is somewhat what I am trying to prepare us for, not building rube Goldberg 
line forwarding and shared line arrangements, and insisting on each customer 
having their own extension. I feel like if we switch platforms, or delivery 
methods, this will make things easier. Even this has been painful to implement, 
and not always practical. 

Regarding upgrades, we've limited ourselves to major upgrade windows 
biannually, and quarterly for SUs, non-critical COPs, etc. Despite everything 
being rubber stamped "24x7" , in reality very few things are. We push our 
maintenance to run overnight, or Friday evening into Saturday, and we go from 
there. IIRC you were cloning or rebuilding VMs within VMWare and juggling their 
connections to try and minimize downtime, but, we've found that as long as 
security and physical plant can operate in some regard, no one else really 
cares.

Best,

Adam
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip