Last year I embarked on a customer Proof-of-Concept (PoC) involving mapping their Microsoft Exchange environment with Service Mapping. With the scope defined, it was time to gather information needed to map the application. Information like, how do users access the application, what are the technology layers, how is the application service distributed across networks, are firewalls involved, etc. You know, useful information. But the initial conversation went like this:
Me: "Can you give me a list of the application components?"
Customer: "No."
Me: "Please?"
Customer: "It's Exchange."
Me: "Thanks. Any other applications?"
Customer: "Can't your tool find everything?"
Me: "I'm asking the questions. Do you have an architecture diagram?"
Customer: "Yes."
Me: "Awesome. Can you give me a copy?"
Customer: "No."
Me: "What about just a look?"
Customer: "No."
At this stage you might look at your cat and say "Ellie, the world is a pathetic place". This assumes you have a cat and it's called Ellie.
Let's run through the Service Mapping checklist:
- MID Server: Check!
- Credentials: Check!
- Do they work? Check!
- Application service name: Check!
- Entry point: Check!
Time to whip it and whip it good. Yes, I'm old and millennials reading this can lookup Devo on Spotify.
To quote Aldous Huxley "One can’t have something for nothing" and Service Mapping did well to find two CIs with virtually no information, but not the 96 CIs the customer was expecting. Service Mapping eventually found the other 94 CIs but not without many e-mail exchanges and webexes, phone calls and suckage of blood from stone.
Briefing the customer sponsor at the PoC closure meeting I likened the engagement to bringing a Formula 1 car to a race track I'd never seen before, not being given a circuit map, not allowed to do a sighting lap and then asked to drive the fastest and most perfect lap. The customer's response was "Yes, that's exactly what we wanted!" Hmmm... kinda suspected that.
That's when I dropped the c-bomb: "Collaboration". You expected a harsher word, right? Shame on you! I pointed out that with a collaborative approach the outcome could have been achieved significantly faster and without the need to develop vampire tendencies (remember sucking blood from stone? No? Forget it).
While Service Mapping does an incredible job, it ain't magical (no unicorns or wizards) and it doesn't work by ESP (e.g. telepathy, mind reading, etc). It requires good input and some steering and that takes a collaborative effort between the people mapping the service and the service owners. Information needs to be captured and pieced together to guide the discovery of the application service components and uncover their relationships to produce an accurate and complete map. Working together and using good input translates to a rapidly discovered service map - in most cases taking a few hours to produce.
The London release of Service Mapping incorporates some features that help with identifying service mapping candidates and improving the collaboration between the Service Mapping Administrator and the Service Owner.
Let's look at how Service Mapping can identify Application Service candidates. Service Mapping can automatically create potential application services referred to as candidates by extracting entries directly from one or more load balancers. The load balancer entries are converted into potential entry points. Service Mapping can also identify potential entry points using discovered traffic-based connections. The end result is a list of candidate Application Services for mapping. Telepaths and mind readers, your services are no longer required!
The Service Mapping Administrator can collaboratively work with the Service Owner to review the candidates and confirm which ones to use. To learn more about this feature check out Map multiple application services suggested by Service Mapping in the London Product Documentation.
Now that the Service Mapping Administrator has Application Service candidates, they can be mapped but how do you know when the map is complete? Service Mapping may run out of CIs to discover, or what if the CIs discovered aren't correct? OK, bring back the telepaths - we need to read the Service Owner's minds... or do we?
What if you could provide a simple way of allowing the Service Mapping Administrator and Service Owner to review and approve the application service maps? I'm glad I asked, because that's exactly what's been added to Service Mapping in the London release. Service Mapping now includes a Review and Approval facility - let's take a quick look at how it's used.
The Service Mapping Administrator is responsible for mapping, fixing, and maintaining Application Services and begins by clicking on the Send for Review button to create a review task assigned to the Service Owner:
The Service Mapping Administrator can include a message in the approval request:
The Service Owner is notified they've been assigned a task and can check the service map to ensure it has the correct CIs and relationships. If changes are needed the map can be rejected:
The Service Mapping Administrator receives the rejection message (hey nothing personal, it's not like they're dating...):
The Service Mapping Administrator fixes the map and resends it for approval:
The Service Owner finally approves the map (and asks for the Service Mapping Administrator's phone number):
A very neat collaboration capability and an example of ServiceNow making work, work better for peopleTM. OK... that was pretty cringe-worthy.
Anyhoo, to learn more check out Review and approval of application service maps in the London Product Documentation.
And would these features have helped with the customer PoC? Absolutely! Notifications sent by the review and approval process would have forced encouraged the customer to collaborate, piecing together information faster with the added bonus of providing a history of how the service was ultimately mapped.
8 Comments
