ALM implementation thoughts

Joanne

My team are about to implement ALM on several of our most significant and complex models.  We're all happy with the process but are a concerned with the extra work it will take to implement quick fixes.  I'd love to hear your thoughts on this extra work.

 

At the moment if an end user calls with an issue we can very quickly implement a fix. Small fixes (e.g. a typo) can be fixed there and then, giving the end user some great customer service.  Once we have ALM'd even a typo will require all model builders working in the affected model to down tools while a revision is rolled back, new tag created, typo corrected, new tag created, sync, roll back to previous revision, re-correct the typo etc.  A more significant urgent change could stop others from building for hours at a time.  It feels painful, costly and burdensome.  I'm sure the pros of implementation outweigh the cons.

 

What is your experience / your customers' experiences?  Are we right to think that we'll feel some pain?  Do you have any tips to minimise the impact?  

Paul

Hi Jo, 

 

Yes I think there will be some pain here. It'll be interesting to hear peoples thoughts around a solution. I will canvas opinion outside of this forum too and big it back.

 

Paul

andrewtye

What sort of thing would a "typo" be correcting? Is it a list item - why not make the list a production one, if it's a line item name correction then is it not possible to just bundle it up as part of the next delivery drop?

From my perspective moving to ALM gives far more control over development and delivery - plus if someone wants to do anything at the moment they probably can't unless the model is "off". The other point of course is revision and often when in development mode, this will aid doing "back to the future" for small hotfix changes.

We've never had issues where hotfixes to formula, etc have delayed development too much, one other thing of course is that with UX being off-model you can still create, amend boards providing you're not needing to change anything in the underlying modules, actions.

Joanne

Thanks Andrew.  You are right: it is hot fixes and back to the future that I'm talking about - the typo being a line item in my example.  I think most of our lists will end up being production.

 

Do you tend to bundle up hot fixes rather than do them individually.  E.G. A weekly drop of hot fixes?

 

I didn't realise that about UX pages.  That's very useful.  So for example if I wanted to change a the view on a grid - e.g. change the colour of the conditional formatting or the line item order - could I do that without revision tags?  Now that I'm thinking about it that does seem logical.  Like you say, they are off-model.

james_lo

Having implemented models that use ALM and models that stay directly deployed, the level of testing and control that you can do with ALM probably outweighs the benefit of being able to do hotfixes instantly.

 

I think there are a few things that are worth considering as you move to implement ALM:

 

Ways of Implementing Model Changes

Rolling back a model is required because changes since the last deployed revision tag should not be deployed in the model while in development.

What if the changes can be deployed, and therefore you do not need to roll back the model?

There are many ways to achieve this, such as:

• not linking the new build to existing build by formula until they are ready;
• using a boolean as a switch, and only turning on the new calculation / methodology when you are ready;
• hiding new dashboards / modules / line items through user access controls

 

UX vs Classic dashboard

We are only starting the use the UX, but the flexibility to have titles and texts that are different to the line items are refreshing, as @andrewtye mentioned.

 

Plan ahead

If there any settings that needs to be changed on a regular basis, and they are structural in nature, such as role-based access to version, you can plan ahead and create all upcoming changes as revision tags before you start the significant build that would require rollbacks.

An example of this is creating revision tags that update access to the Current Version from write to read, then from read to write again.

Having said that, with version switchover and current period settings now production data, and the possibility of using Dynamic Cell Access (DCA) as access control, this should no longer be a big issue.

 

Customer Expectation

When we first implemented our models we effectively trained our users that all fixes are near instantaneous.  The fact that ALM introduces a necessary time delay provide you an opportunity to introduce a Service Level Agreement (SLA) type expectation that is more in line with a complex model.

You can of course aim to exceed and delight your customer by delivering quicker that your SLA.

 

I'm sure there will be other considers that are more specific to your situation, and I hope the above helps you to devise a delivery governance structure that works for you.

andrewtye

Generally once a model has been deployed there's a period of live commissioning where all the snaggings are generally picked up and in that period would be doing fairly regular syncs. Beyond that and on the assumption that all the enhancements have been delivered broadly they're delivered as completed and signed off.

Normally we wouldn't be doing proper development into something already deployed unless it was to add in something additional requested by the end users

Only thing on UX is to make sure that you're not using saved views as clearly they will require a revision tag to amend.

Joanne

Thanks all.  It sounds like there is no way of getting past the hot fixes pain without affecting customer service but we can manage this.  The NUX page being divorced from the model is a great enabler and will mean certain fixes won't need revision tags at all .  We'd already moved away from using saved views when creating pages but we'll be even more careful about this to give us the ultimate flexibility.

 

We're also going to put in place a named workspace admin to own synchronisation for each production model.  They'll be the only person allowed to sync the production model - thankfully we have various workspaces to accommodate this.

 

I think we'll also tag each user story and minor enhancement with the revision it was enacted in - but we'll see if this becomes too onerous.