Advance notice of scheduled HSM updates please?

[Trevor Tinsley]

Good afternoon,

We invariably raise internal change requests to update our HSM version on Wednesday or Thursday evenings as Hornbill often publish new updates on Fridays.

In general, we perform system updates at least a week following publication to allow us to review any issues the Hornbill community have reported and which you have remediated.

Having prepared a change to take version 1466 this evening, as you have published 1471 this morning, we will be unable to proceed with this change.

Would it be possible to a) publish a forward schedule of change and b) publish updates on a fixed day of the week?

Looking at the most recent updates, you appear to publish them on any day of the week:

1. 1471 Wed 27/03
2. 1466 Fri 22/03
3. 1464 Wed 20/03
4. 1459 Fri 15/03
5. 1453 Tue 05/03
6. 1452 Mon 04/03
7. 1451 Mon 04/03
8. 1443 Tue 26/02
9. 1439 Thu 21/02

Regards.

Trevor Tinsley.

[Victor]

@Trevor Tinsley only patch updates are published close to weekends, not the major updates. Patch update will be deployed as soon as we identify an issue that requires an immediate patch. Major updates are usually deployed early in the week. For any patch update, it will be impossible to publish any schedule. 

I do apologise if this conflicts with your change management process but, I have to ask, what would be your process regarding our automatic updates? All our updates except application updates (Service Manager is an application) are automatic. So platform, collaboration and admin tool updates are all automatic, all instances get updated automatically when they are deployed, there is no choice in applying or not one of these updates. We are also close in implementing automatic updates to all our applications as well so in the near future all updates in Hornbill will be fully automatic. I can imagine at this point your change process will no longer apply, I cannot see how it could since there won't be an option for a customer to perform an update at a date and time of their choosing.

This all fits in with the continuous delivery concept we promote and (with the limitations explained above) adhere to. You can find more information about this on our wiki here: https://wiki.hornbill.com/index.php/Continuous_Delivery

[Trevor Tinsley]

Hi Victor,

Hornbill benefits greatly from its user base, you only have to look at the community fora to see this, especially following system updates where users have often found issues not identified prior to an update being published.

We like to have at least a weeks grace on applying updates as we aren't always 100% confident that Hornbill releases will be issue free.

We hope that at the point where Hornbill makes all updates automatic that the your test/beta processes will be mature enough to give us the required level of confidence.

Regards.

Trevor.

[nasimg]

Hi

Agree with Trevor - I would like a week notice (or have a fixed change window eg. every Wed 21:00) between releases. This allows us to raise a change on our side and get it approved and have confidence they are not causing issues for early adopters.

If you are doing the patch updates like the livenode ones so we don't have to do anything - then you can apply them when you like, although I still prefer a schedule so we can be prepared.

Nasim

[Victor]

Everything about how updates are applied to your service is detailed in the wiki link I provided. I reiterate again that there won't be any manual updates going forward and I am unsure what benefit an advanced notification would do for a change management process. Let's theorise a bit and say that we could do the advanced notification. You raise a change requests, which is not really a change request because you are not managing this update, Hornbill does. Let's go further and say the change does not get approved for whatever reason. This will not stop the automatic update from happening, so at this point, your change request and the update itself are no longer "connected" (they never were)... I simply ask again, what is the change management process for all our updates that are automated already (i.e platform, collaboration core and admin tool)?

I do aplogise if by any chance I am missing something from this whole idea or process. In my view, I simply do not see how change management works for an automated Hornbill service. Because automation, customers cannot manage or control any Hornbill change.

[nasimg]

Thanks Victor

I agree less for us to worry about if you are automating the updates - I would be happy with an email notification (like Live Node ones) so we will know something has happened.

Nasim

[Gerry]

@Trevor Tinsley

I wanted to jump in here and expand on what @Victor was saying, I hope you don't mind.  It is difficult for us to add forward publishing of change in a way that would be consistent and would not stifle progress.  In delivering our SaaS platform we made a very conscious decision about going down the route of continuous delivery. To make that sort of commitment we had to really rethink pretty much everything we do.  You mentioned. 

Quote

Hornbill benefits greatly from its user base, you only have to look at the community fora to see this, especially following system updates where users have often found issues not identified prior to an update being published.

 

This is a fair statement and I can understand your concern, but if you actually look at the numbers as a relative measurement, the number of issues is a microscopic number in comparison to the number of changes that we do make and push out to improve the overall service to our customers, and I believe that in counter to your comment above, I would hope that our customers derive a great deal of benefit from a service that is overall predictable, available, safe, secure, always up to date and essentially evergreen. Customers (save for the current app update button) do not have to be concerned with updates, upgrades, migration plans, data migrations or planning or time for any of the above, the idea behind our approach is we do all of that for you, all of the time so you are unencumbered and are free to doing your day job rather than maintaining a system you use to do your hob.  Now, I will be the first to admit that we are a software company, run by human beings, and as such there will be something we miss and there will be the odd thing that will go wrong, and by accepting that we are able to commit to continuously drive improvements in functionality, performance, security improvements, and we strongly believe that if you look at the service over its lifetime, overall that's a far better approach for our customers.  We cannot ever guarantee to never break anything, no software company can, but we do everything we can to minimize this and we can guarantee that if something does go wrong, we have an office full of the worlds most experienced Hornbill platform and applications people, who will prioritize fixes and resolutions to problems above all else, most problems we can (and do) fix in literally minutes.  This approach appears to work exceptionally well for our customers in the vast majority of cases, but it's not an approach that is on the face of it, naturally aligned with more traditional change managed approach. 

The alternative way to do this would be to stage our releases, to say quarterly or bi-annually where we document every single change and like one of our competitors provide you with a 40+ page document that gives you information on how to "prepare for an upgrade", offloading the responsibility of testing, migration, backups and all that good stuff to you - the customer, that would fit more neatly into a traditional change control process, but honestly, we hate that model because of our past experiences, and think in today's world of IT, complex business applications are better delivered as a service, and the vendor should be entirely responsible for updates/upgrades and data migrations. 

We actively promote this evergreen approach when we sell Hornbill, and this is often one of the factors for customers choosing our solution. Many of our Hornbill customers who have been users of an n-prem solution that does have more traditional upgrade approach, like our own Supportworks tool, I would like to believe would support the idea, that on balance, the Continuous Delivery approach we take with Hornbill is hands-down a better approach than the infrequent "upgrade" model and "upgrade projects" of the past. 

Back to the original question, it's very difficult for us to document an FSC without substantially changing our process, many things are fixed and deployed (and documented in release notes) in a timeframe that's faster than writing and publishing the change in advance of deployment, as soon as we do that we are inviting bigger customers to start wanting to "gate" our releases to tie in with their own change processes, which will be especially true when the application update button has been removed altogether (a very popular request from our customers). 

To try to give some justification to this approach, we are Office 365 users, we have no idea what version we are on, and what updates are applied and when, Microsoft do all of that so we don't have to worry about it, and I have no interest in knowing what they change either, all I care about is when I need to access my email it just works, or if I need to open a spreadsheet I can.  I would like our customers to think of Hornbill in the same way, that's been our vision for our platform since inception. 

I hope that goes some way to explaining our philosophy and approach. 
 

Gerry 



 

[Kelvin]

Just to add my thoughts.

I am happy for changes to be made without prior notification, is there any way that when changes to interface occur that we can get some sort of notification. Not sure how this would be best achieved. I know there is Harry but as I don't routinely log calls so this does not always work.

Example. Recently there was an update to how the add assets within a request have changed. (I really like the change) however I had a new starter learning the system working through some training guides but our documented processes did not match the actual screen. If I had seen a notification I could have corrected these guides.

 

[Keith Stevenson]

Kelvin,

If you follow https://community.hornbill.com/forum/135-announcements/ you will receive email notifications (if configured) of all changes\updates as they become available. 

 

Kind regards

Keith Stevenson

[Gerry]

@Kelvin

Thank you for the vote of confidence. As Keith mentioned above, you can get notice of any change by simply following the above forum topic, that will tell you about every release because posting to it, is entirely automated.  

Gerry

[Kelvin]

@Keith Stevenson @Gerry Thanks, I wasn't aware you could subscription to a part of the forum. I have now

[Trevor Tinsley]

I am amazed Victor has such a blinkered view of how IT departments are run in the real world...

Why do I need a change for a SaaS update? Hmmmm, if HSM updates are automatic, it may well be that our change would be 'information only', however in the event of issues caused by an update (yes, we have experienced system-wide issues resulting from HSM updates), at least our service desk would have visibility on any changes to our estate and be able to direct their investigations.

You should also remember that our user base see our IT department (not Hornbill) as responsible for HSM, so I hope you can appreciate our wish to be as prepared as possible to deal with the worst case scenario (however unlikely).

I do recognise your desire to be Agile with regard to releasing updates but it can be abused and used as a vehicle to simply generate ad-hoc changes as the result of inadequate/insufficient development and/or testing. 

Thanks for all the feedback, I'll head back to Jurassic Park...

[Gerry]

@Trevor Tinsley

Thanks for your comments, the position was not supposed to be dismissive of any need, if it came across that way I apologize.  We do understand that IT is seen as being responsible for HSM and its important for you to be aware of all and any changes, this is why we set up the update forum above so you can be notified of changes in advance of you applying those changes with regards to the Service Manager and other applications. I think @Victor was simply trying to highlight that we are in the future (due to overwhelming customer demand) will be making these updates automatic, which means they will get applied for you in the maintenance schedule window that you define. 

I fully acknowledge that there can be issues that arise but I can assure you we take our testing/validation very seriously, and we always look for ways to improve our approach, and we very definitely do not use an Agile approach so as we can abuse or compromise our approach to quality.  We have good data over the last 15 years or so, and hands down our customers get an overall better experience by a very long way, our the number of support issues and the nature of those support issues tells us this. 

It would be a terrible situation, and we would have failed in our mission, if our customers need to be notified in advance of changes to our software and have to do their own testing/roll-out plan every time we do a release/update, most customers don't want to do that, or be involved at all, which as I said is what I am told by many customers is one of the key drivers for buying into a SaaS solution with a Continuous Delivery approach. We prove our service to all customers with a zero contract tie in which we believe allows our customers to vote with their checkbook, if our approach, our service does not live up to the needs of their organization they can leave without any contractual obligation, everyone at Hornbill knows this so we are compelled to always do the right thing, software quality is a big part of that, if we do make a mistake it is certainly not intentional and we will do everything necessary to put it right as soon as we can.

Thanks,

Gerry