Naming standards is a crucial thing in our job!
This post is about time spent in naming standards, possible costs of developing naming standards and possible costs not to have a well-thought-out naming standard for the orchestration projects.
First I need to say, our basic aim is to provide organization-wide uniqueness for a configuration. This is the first step in automation. If something about the naming standard is not well-considered, most probably the orchestration project will not fit in the budget. It will cost you a lot of reworks and you know how the story goes on after that particular point. In fact, on average every person/hour spent on qualitative work items saves 7.7 person/hours of quantitative work items globally. orchestration projects are not an exception!
As every software project needs relatively constant requirements to decrease costs. Above all software projects, orchestration projects are the easiest one to solidify the requirements because responsible personnel is directly working in IT. That is a clear advantage. So what I do to harvest naming standards is conducting a meeting. The main deal here is the attendees' profile. The attendees should have enough authority and know-how to decide. If attendees are some juniors sent for just to understand what is going on, you should cancel the meeting and directly escalate the situation.
Usually, I work with one group at a time. To concretize everything I trap a small and authorized group of IT operators (like Senior firewall administrators, storage administrator team leads, etc.) and set a meeting about just the naming standards (!). It is very important to work with a small and proficient group to make things work. Their decision will be applied to everyone after that meeting.
My meeting lasts at most 4 hours! For almost every single technology! After every naming standard meeting, I am very accustomed to seeing the shocked expression in attendees' faces. That's totally normal, there were a lot of undecided things that they were not aware of. But the key is, THEY will decide what their rules are! So give them time to think about every variation. But beware, this kind of long meetings has quicksand risks everywhere. You should note down every variable type or you should stick in the mud of the same ideas in no time.
One of the most important things is to divide configurations! Don't design complex configurations, a configuration must do one and only one thing! So divide the configurations to simple particles. This will cause long naming standards and more rules but that's the point! No one will do these configurations manually once you finish this project!
Another crucial thing is, you will encounter a lot of undecided cases. "The small team(!)" should decide these kinds of cases. They can be changed later, but everyone in that room should conclude tentative decisions and what kind of cases have been decided when they leave that room. After that, I give 1 day to think about the decisions and a fresh poll about the newly achieved naming standard.
As the last step, I trigger an update in the naming standards documentation!
And now we are ready to automate!
To wrap up, I'll summarize this post as;
1-Work with one and only one group at a time!
2-Invite small groups which consist of 2-3 people and who have the technical know-how (team leaders or senior specialists are preferred).
3-Make sure attenders have right to speak and authority over teams
4-Make sure that attendees totally understand this meeting is going to decide team strategy and is going to change their way of work!
5-Respite IT operators, let them think about every scenario in the meeting. Just guide them not to stuck a point!
6-Probably the meeting will last long, note down every single identification point
7-KISS the configuration objects :) Divide them into simple pieces! And persuade them they are not going to do that manually anymore.
8-Force the teams to decide everything that supports the naming standard at that meeting like abbreviations, undecided situations and so on!
9-After the meeting, give everyone one more day to think about the standard. Let them discuss the standard with you.
Well everyone knows to deal with the old configuration is a pain! But after the orchestration project, the old configuration will be easier to deal with.
I hope this post will save your project a lot of person/days!
This post is about time spent in naming standards, possible costs of developing naming standards and possible costs not to have a well-thought-out naming standard for the orchestration projects.
First I need to say, our basic aim is to provide organization-wide uniqueness for a configuration. This is the first step in automation. If something about the naming standard is not well-considered, most probably the orchestration project will not fit in the budget. It will cost you a lot of reworks and you know how the story goes on after that particular point. In fact, on average every person/hour spent on qualitative work items saves 7.7 person/hours of quantitative work items globally. orchestration projects are not an exception!
As every software project needs relatively constant requirements to decrease costs. Above all software projects, orchestration projects are the easiest one to solidify the requirements because responsible personnel is directly working in IT. That is a clear advantage. So what I do to harvest naming standards is conducting a meeting. The main deal here is the attendees' profile. The attendees should have enough authority and know-how to decide. If attendees are some juniors sent for just to understand what is going on, you should cancel the meeting and directly escalate the situation.
Usually, I work with one group at a time. To concretize everything I trap a small and authorized group of IT operators (like Senior firewall administrators, storage administrator team leads, etc.) and set a meeting about just the naming standards (!). It is very important to work with a small and proficient group to make things work. Their decision will be applied to everyone after that meeting.
My meeting lasts at most 4 hours! For almost every single technology! After every naming standard meeting, I am very accustomed to seeing the shocked expression in attendees' faces. That's totally normal, there were a lot of undecided things that they were not aware of. But the key is, THEY will decide what their rules are! So give them time to think about every variation. But beware, this kind of long meetings has quicksand risks everywhere. You should note down every variable type or you should stick in the mud of the same ideas in no time.
One of the most important things is to divide configurations! Don't design complex configurations, a configuration must do one and only one thing! So divide the configurations to simple particles. This will cause long naming standards and more rules but that's the point! No one will do these configurations manually once you finish this project!
Another crucial thing is, you will encounter a lot of undecided cases. "The small team(!)" should decide these kinds of cases. They can be changed later, but everyone in that room should conclude tentative decisions and what kind of cases have been decided when they leave that room. After that, I give 1 day to think about the decisions and a fresh poll about the newly achieved naming standard.
As the last step, I trigger an update in the naming standards documentation!
And now we are ready to automate!
To wrap up, I'll summarize this post as;
1-Work with one and only one group at a time!
2-Invite small groups which consist of 2-3 people and who have the technical know-how (team leaders or senior specialists are preferred).
3-Make sure attenders have right to speak and authority over teams
4-Make sure that attendees totally understand this meeting is going to decide team strategy and is going to change their way of work!
5-Respite IT operators, let them think about every scenario in the meeting. Just guide them not to stuck a point!
6-Probably the meeting will last long, note down every single identification point
7-KISS the configuration objects :) Divide them into simple pieces! And persuade them they are not going to do that manually anymore.
8-Force the teams to decide everything that supports the naming standard at that meeting like abbreviations, undecided situations and so on!
9-After the meeting, give everyone one more day to think about the standard. Let them discuss the standard with you.
Well everyone knows to deal with the old configuration is a pain! But after the orchestration project, the old configuration will be easier to deal with.
I hope this post will save your project a lot of person/days!
Comments
Post a Comment