● people and processes
Each TA is assigned a lead (ideally a senior-level SME in his functional area) and a number of contributors. There should be a large number of contributors, for reasons that will become apparent below. For larger or more complex TAs, a multi-level hierarchy may be desirable.
The benefits are numerous:
● Activities are divided into manageable, definable chunks. This is critical because the IPv6 transition touches so many aspects of your organization.
● The work is spread around. The IPv6 transition is too much for any one person. The idea is to use only a small slice of many people's time as opposed to all of a few people's time.
● You might get hit by a bus, so you don't want to be a single point of failure.
● Everyone gets involved. IPv6 is more than just a transition of technology. By getting everyone involved, there is a sense of collective ownership, and everyone starts thinking and learning about IPv6.
● The collective knowledge and skills of a wide variety of people are effectively utilized.
● Nothing gets missed.
The actual activities of the TAs will be outlined next, but before we get to that, one note: When assigning TA leads, be sure the individuals are reliable and excited about IPv6. You will be leaning on them a lot throughout the transition, so choose them carefully.
Now that the basic strategy is laid out, and the TA team structure is in place, it's time to get to work.
Before you can "flip the switch" and start running IPv6, you first need to assess the IPv6 readiness of your systems. Therefore the first task for your TA teams will be a reconnaissance mission. The TA leads will define a list of all the components within the scope of their TA, and assign one information gathering worksheet per component to a TA team contributor.
What exactly defines a "component" may differ depending on the TA, but a component should be a measurable, definable unit. For example, if one of your TAs is Communications Infrastructure, a component could be a particular router (for example, a Cisco ASR 1013, or a Juniper MX480). If one of your TAs is Processes, a unit might be one process (for example, a subnet request process).
For the technical TAs, components can typically be broken down into two types:
1) Box-level components: typically a physical or virtual device with CPU and memory resources. These should be assigned to more junior-level contributors, as they are typically simpler and more straightforward. Examples: a particular router, a physical or virtual server, etc.
2) System-level components: a protocol or application that abstracts the underlining hardware on which it runs. These should be assigned to more senior-level contributors, as they can be quite complex. Examples: a routing architecture, a network or server monitoring solution, etc.
During the first phase of the transition (Internet-facing content), it is important for you to clearly define the scope of the information gathering exercise to your TA leads, and likewise for your TA leads to clearly define the scope to the contributors on their teams. As contributors fill out their worksheets, they will more than likely run into gray areas in the scope definition ("Is this component in scope or not?").