Following on from last week’s blog where we discussed our Hierarchy of Change. I am looking to expand on this and look at the first use to put this to.
To recap, I defined four levels in the hierarchy of change:
- Configuration
- Customisation
- Extending
- Developing.
This week, I am also going to add in “3rd Party extensions”. You may have decided to use the levels I suggested, or you may have come up with your own. There’s no right or wrong answers other than there should be no more than six levels. However, I’m sure many of you will have pencilled in a yes or a no against each of your levels of change. There are some wrong answers here if you did this.
If you thought yes, that’s ok to every single level, then sorry, that’s a wrong answer.
If you thought no, we don’t do that here, to any of the levels that’s also a wrong answer I’m afraid.
Let me delve a bit deeper in to why this is the case, we will come back to the hierarchy of change shortly
That’s another fine mess you’ve got us into
I find that some people can’t wait to tell me with glee about an organisation whose Dynamics 365 (D365) environment was in a mess because it had been heavily customised. They’re often eager to provide the anecdote as support for a negative view of D365.
I smile politely and nod whilst thinking, don’t you mean it was in a mess because they let any person and their dog make changes to the system with no consideration of its effects, good practice or supportability?
I’ve seen a few systems which are pretty much pure out of the box as can be without a single piece of code. And they have been in a mess.
I’ve seen a few systems which have had developers all over them adding plugins and bolting things on here there and everywhere and they’ve been great.
OK that second statement might be an exaggeration, but it doesn’t have to be. Heavily customised is not the same as badly customised.
But why do D365 systems often end up in a bit of a mess? Well maybe it’s something to do with people’s perceptions towards it, both from a technical side, and the business side:
- It easy enough for anyone to change, so anyone should
- It’s not development so we will let the business look after it all on their own
- We will approach it exactly the same as any other development.
- It’s just a tool to help develop quicker.
Yes, some of these may seem a bit rude but hopefully it will help people sit up and listen. However, once again us D365 evangelists are sometimes our own worse enemies.
Trust me, I’m a D365 Specialist
How many times have we told architects and department heads “oh it doesn’t work that way”? For those of you who are end users, how many times have you heard this? And how many of those times have we been able to provide a clear description of the issue and point to documentation of how it is addressed within D365?
If you are anything like me the answer to the first question is quite high, and the answer to the last question is rather low. Given that, how can anyone differentiate between someone who knows their stuff, and someone that is blagging? You are effectively saying, ignore all you know and trust me.
This is one of the motivations behind these blogs, to provide that back up material for the quirks of D365 and the Power Platform(PP) (my next installment will look at more reasons for this series). But for now, the message is, we need to be shouting good practice from the get go, and explain what good looks like in the world of D365 and PP. And what better place to start than good, effective governance.
Governance isn’t a two-option set
Governance and effective governance are different things. Whilst it’s a rabbit hole I don’t want to go down in this blog hopefully you can trust me (yes I’m a D365 Specialist) when I say:
Following a policy or protocol ensuring all the steps have been covered to come to a yes/no decision is governance. Knowing the context of the policy or protocol you are following and knowing the right questions to ask to come to a decision which has conditions attached is effective governance.
So, where does this leave us, and what does this have to do with the Hierarchy of Change?
Lets go back to my list
- Configuration
- Customisation
- Extending
- 3rd Party Extensions
- Developing.
Now we have defined these levels, we can decide which type of changes our business wants to utilise. So for you who have pencilled in yes and no against each level, let’s look again.
Whilst not an exact science, we can see from top to bottom, there is an increasing degree of effort required, which may mean an increased cost and risk. This is why a blanket yes to every type of change is a bad idea, however, there is also an increasing amount of flexibility which can be offered as we go through the levels so maybe ruling stuff out isn’t always the best idea either, no matter how well intended.
This is about effective governance and controls. Whether it is an in-house support team, or a consultancy delivering a new system, it allows you to be clear which type of change can be utilised freely, and which ones need to have explicit approval.
Once again, I am going to get you started so here is That Queer 365 Guys Hierarchy of Change and Control….
Using a fairly simple imaginary structure of front-line support, D365 support and Technical Design Authority (TDA) I can envision a basic set of controls and governance structure below.
| Level | Who by | Controls |
|---|---|---|
| Configuration | Front line support | Must be documented in change log |
| Customisation | D365 team | Testing signed off and release notes approved by TDA prior to release. |
| Extending | D365 team | As above, but each extension must be explicitly called out in test plans and release notes. |
| 3rd Party Extensions | D365 to identify and prepare documentation for it to be approved | TDA approval required |
| Developing | TDA to assess before any development commences |
One thing to note, is that the controls become slightly more burdensome as we go down each level. This is intentional. It forms what is known as an administrative filter (also known as a bureaucratic filter) It should help encourage your team to find solutions which remain as close to vanilla as possible without tying their hands.
It’s really that simple – almost
This is the starting point. Obviously, every organisation is different. In a small organisation your TDA might just be your IT manager. In a consultancy the TDA will likely be the client. It’s basically a slimmed down and tweaked RACI chart
You may want to add exceptions as well. For example, any new relationships to the contact entity needs approval of a senior team member. You might suggest that a formal discussion is held (and documented) amongst the D365 specialists for any new entity.
To code or not to code – now it’s the question
So now I am looking specifically at the final level, rather than the odd line of JavaScript. The simple approach should be never-say-never. Yes, you can make it as burdensome and as unlikely to be approved as you want, but you need that path just in case. There will always be that one use case that needs that extra bit which D365 cannot offer.
You need to ensure there is a path to get this coding approved. It protects against someone going rogue, it also encourages collaboration. If a D365 Specialist can only see a solution by developing some standalone functionality, taking it to TDA means they get chance to suggest alternatives (that’s right, even when they say no, they should be giving options) or allow you to tap in to support from the wider business. It also means if it is an absolute must have for the business, you can take it to TDA, and then let the business and TDA have the discussions between themselves whilst you get on with other work.
Homework time
Yup once again there is some homework to do.
Think about your hierarchy of change, and think about what level of controls you would like around it. Think about your as-is, and think about what would be a better way. Even if you have free reign, it’s useful to ensure there is some oversight. If you think your current set up is restrictive, what would you like more freedom to be able to do you? If you are an end user about to embark on a project with a consultancy, think about what changes you want them to speak to you directly about.
Copy mine from above if you like – let me know how you get on.
Now, here’s the interesting bit. Once you have it. Take it to your TDA, or whoever fills that role, and get them to approve it. Not just a quick nod. Walk them through what the levels mean, explain what you mean by change, and show them that you know what you are talking about. Give them confidence that whilst D365 may have its quirks, it also has its own good practices and they are to the same standard as any other software and project good practices.
Once you have it agreed, then why don’t you publish it let people know on the forums, share amongst your networks. Let’s make sure when people are new to D365 and PP, they can search the internet and D365 specific good practice will show up.
Please like follow and comment. My next instalment will be slightly different and I will be looking at why we should develop good practice, expanding on my introduction.
That Queer 365 Guy 