In light of The Phoenix Post over at Technet blogs, I figured now would be a good time to start recording things I wanted to see in SM. This is my running list of improvements, advancements and enhancements that I want to see in service manager.
It should be noted that I don’t think any of these are required or essential. Service Manager is extremely flexible and has the ability to compete with the best ticketing systems on the market. Moreover, it’s the only ticket system (to the limits of my knowledge) that is both strongly typed enough to implement ITIL best practices, and flexible enough to allow companies to completely ignore them. That being said, it’s also kinda rough in some places, and these are the places I want to see polished for Service Manager V.Next:
Better console handling of write collisions.
STOP RIGHT THERE! Aaron Croasum has solved this problem wholesale. [–ed, 5/8/2015]
This is a training issue for every single client. YES, it’s a minor issue, YES it’s easily corrected by training or process refinement, but I still have to talk about it to every client.
Consider this alternative dialog suggested by one of my colleges, a process engineer and former programmer:
You can imagine how much easier it would be to understand and correct a write conflict if you could easily compare your update (In-memory edited form type projection minus original form type projection) to the changes in the database (new form type projection from DB minus original form type projection) and pick which pieces you want and which you don’t.
Better handling of many-to-one relationships
This one is, I’ll readily admit, one of my personal irritant that most people will probably never run into. Today, there is no easy way to expose many-to-one relationships; There is no control in the authoring tool.
In a toolbox-style representational object oriented configuration database, this oversight seems significant. most relationships in a CMDB are many to one. a single system can host multiple applications, and applications can run on multiple systems. networking gear connects multiple machines, and machines can have multiple network connections.
Microsoft has always had a strong penchant for providing the minimum required solution, and many to one relationships are confusing and generally the domain of process geeks with unpopular blogs (er… ahem).
The implementation of a generic list-box-and-buttons control with associated generic add, remove, and edit buttons would do wonders for enabling many-to-one relationships. Right now, you either have to use an existing relationship and control, like the impossibly generic “Related Items”, or spend several weeks developing custom forms and methods to expose this to the end user. Customizing Service Manager to support the examples above can be made much simpler.
Unrelated: check out Patrik Sundqvist’s excellent solution on reusing the default related items and history tabs for custom work items and config items. And while you’re at it, I strongly recommend his Web Based Analyst Console, Mobile Analyst Portal, and I hear rumors that his company is about to publish a HTML 5 end user portal, which is already on the must have add-ins list for at least two of my clients.
The depreciation of container activities.
The addition of parallel and sequential activities in the 2012 release of service manager was a massive boon to process modelers. Almost every process includes some form of parallelization, and very few processes fit into the strict linear processes that could be built in the 2010 release.
However, The execution and implementation of container activities is not very clean, and causes some interesting problems for automation. By the time of 2012 R2, most of the bugs have been corrected, but we’re still left with some “interesting” design decisions. Two task that run in parallel requires 3 activities; One client of mine ended up with a code elevation change request that was no less then 28 activities long, and about 1/4th of those were container activities. It makes editing processes harder, because you can’t drag activities into or out of containers. It also means that any person (or process) who has an activity and needs to reference the SR, CR etc, will need to loop through the parent containers until finds the top of the tree, rather then having a direct reference from the activity to the parent.
A lot of these issues could be eliminated with a simple change to the workflows that advance activities. For background: Activities are related to their parent work items by System.WorkItemContainsActivity, and have an integer property SequenceId. The workflows that advance activities looks at the SequenceId of the activity that just completed, finds the next SequenceId related to this work item and starts that one. If there are two with the same SequenceId, then the workflow crashes because the CR/SR/Whatever is in an invalid state.
But let’s Imagine instead that we change that behavior a little. Now the workflow looks at the current Id, checks for any other Activities with the same Id, quits if any other activities are still in-progress, or (if this is the last AC in the SequenceID) it finds the next lowest SequenceID in use on this AC and starts every activity with that SequenceId. This would have two major implications:
First, it would reduce (or outright eliminate) the problem of a service request or change getting into an invalid state because of template issues. This is not a major deal in most implementations, but in light of this post, it seems Microsoft wants to encourage people to apply templates to SRs are part of automation, so duplicates are inevitable. this isn’t a perfect solution, but it is a better solution then letting the SR die in an invalid state.
Second, it would allow for multiple activities with the same SequenceID running at the same time, without PA container activities. this is a much lighter weight implementation, and SHOULD make process design, esp implicitly parallel processes, easier to model; just set all the ACs that should run at once to the same SequenceId.
Now this would largely eliminate all of the problems from above, and it could be done by fiat without changing the way ACs work otherwise. it would also relegate container activities to their rightful place, that is, self-contained processes.
Better documentation of internal constructs.
One of the best things about service manager is how flexible it is. That flexibility comes with significant costs thou. If you feel so inclined, you can rip and rewrite the workflows that displease you. (more on this later, if i ever get around to a pie-in-the-sky project of mine)
but with great power comes great responsibility, and Microsoft hasn’t done a very solid job of documenting the way the existing internal components work, in order to enable integrator or expert installers the flexibility to customize as needed.
As an example, consider all of the published documentation of a function of the console helper classes, bool IsFormInTemplateMode() from Microsoft.EnterpriseManagement.GenericForm.FormUtilities.Instance: Here (two of those are me) or Here (use Bing: 9.9 million results, and not one of them about what I actually asked for).
I don’t mean to imply that Microsoft needs to write out the whole source of every module, but some example code (like Travis attempted to do here in 2010, only on a MUCH larger scale), a comprehensive description of the the boxed processes, and some complete SDK documentation would be nice.
I’ve commented on this in the past, but the tools available for Service manager are a pretty mixed bag. the Authoring tool is super valuable for what it does, but it has more then a few sharp corners. the Visual studio tools are pretty scary, and a LOT of my work involves directly editing the XML or using powershell, or even worse, calling the SDK. The hardest thing I have ever done with service manager was add a single control to a form to support a many-to-one relationship, it took me 8 weeks to reproduce something Microsoft did with the default work item forms.
now there are a lot of third party tools that can help this. the provance DMP makes importing data A LOT easier. Anton’s Advance View Editor is pretty much required for my implementations, because the default view editor is so skeletal. Cireson has made a whole business based on the required stuff Microsoft failed to provide with the product. NONE of these products is terribly hard to produce. the single distinguishing factor for all of them is that the provided solution from MS is either impossible to use or so minimal to be basically useless.