@Elias2 I go back to my old days of writing function point test plans for my pseudo code. At At&T we used to have to do that and get it approved before we could write any actual C code. Can you do that here? Test scenarios for incidents, changes, etc..,:
- Can the tier 1 support team and the customer quickly and accurately agree that the problem is with Drupal or WordPress? Is that what the customers would say if they created an incident or an enhancement request to the service? "My Drupal site isn't working." In an ideal world, you could even have the customer pick the service because they're familiar enough with the language. If they pick Drupal hosting or WordPress hosting, you could ask at submission if it's dev/test/prod, so you don't have to call or write them back to ask. What else can you do with the model to limit the back-and-forth between the tier 1 and 2 teams? Maybe prompt for the URL or site name? Perhaps the site name becomes the service offering, then you don't have to ask if its test or prod.
- I can see two reasons to divide the app services. First, you have different SLAs on dev and prod. Second, you have different owners and support teams. If neither of those is true, you could go straight to the team supporting Drupal or WordPress. Could you think about the run book for the tier 1 agent trying to route the incident or enhancement request? How could you make it easier for them or use automation to route the ticket to the tier 2 Drupal or WordPress teams more easily? Interestingly, people think of CSDM as system modeling, but it's more about organizational modeling and routing work to teams or automated assistants. That's what makes it hard to critique these models. It would be easier with an org chart. You and people in the tier 1 and tier 2 support teams, not the general public, will be better sources of information for you to build applicable models.
- When the application service teams get the incident or enhancement, how do they determine where to pass the ticket? It's the same type of thinking as tier 1, but tier 2 is just a different level of support.
For things like change, vulnerability, risk, etc.., just run the scenario backward from the ci up to the services. Think of the goal or the model to be to route work better and faster. In the case of bottom, it's mostly about understanding the impact instead of identifying the root cause.
