Microsoft System Center and Team Foundation Server

Recently I spent quite some time getting to grips with Microsoft System Center  (SC). I have a client that has a very large IT infrastructure environment and relies quite heavily on SC to monitor and manage it.
SC is one of those products where the question “What does it do” will prompt an answer “What do you want it to do?”. If you have not heard of System Center before, it is basically a suite of products specifically aimed at corporate IT administrators, assisting them in managing Microsoft server and desktop infrastructure.

This means that you can leverage SC (making use of the various aspects or applications ) to do everything from AD account provisioning to virtual machine creation and deployment.

TFS does have a management pack which integrates TFS very nicely with System Center Operations Manager (SCOM).

“The Team Foundation Server 2012 Monitoring Management Pack provides both proactive and reactive monitoring of Microsoft Team Foundation Server 2012. It monitors TFS components such as application tier server instances, team project collections, build servers, and proxy servers. “

So we can monitor TFS and report failures and even go as far as “escalating issues” to TFS in the form of work items.

This post however, centres around System Center Services Manager (SCSM). SCSM with its “out of the box” integration with a number of SC applications, including Orchestrator, makes it a very capable application for managing, automating and adapting your IT services.
It also provides built-in processes for incident and problem resolution, change control, and asset lifecycle management.
Has the penny dropped?
What if I mention that TFS work items provide built-in processes for incident and problem resolution, change control, and application lifecycle management.

The client that I mentioned earlier is using SCSM to manage everything from infrastructure to software requirements and changes.
The development team is using TFS and they wanted to “integrate” SCSM with TFS, reducing the effort involved to manually copy work items and progress from one system to the other. They also wanted to reduce the context switching between the applications, specifically in the development environments.

So where to start…

As I mentioned earlier, SCSM integrates very comfortably (using connectors) with a number of the SC applications. One of which, Orchestrator (previously Opalis), is basically a workflow management system. In SCSM you can invoke and execute Orchestrator workflows through a number of processes and via a number of hooks, and in Orchestrator you can configure “monitors” that poll target systems. Through Orchestrator and custom “Integration Packs” (IP) you can basically have SCSM integrate with any number of 3rd party applications.

The guys over at the Orchestrator Codeplex project had already built some IP’s for various applications and fortunately for me there is even one for TFS.

So, how did we get this going..

Firstly you need to get hold of the Integration Packs and deploy them to the Orchestrator “Runbook” server.
Then we can create the workflows that monitor SCSM for any changes in the Requirements and Manual Activities.
When a requirement is created or changed we push over that change to TFS as a User Story.
Next we find associated Manual Activities and then create or update them in TFS as Tasks that are linked to the User Story.

 

The same approach is followed when a change is made to a work item which is then updated in SCSM.

One problem that I did have was that the TeamFoundationServer IP was built using TFS 2008 and updated to TFS 2010. This means that work item links were not taken into account when the initial activities were created.

Fortunately it is very easy to code these custom activities (think activities in Windows Workflow Foundation) in the IP’s, and being a codeplex project I was able to grab the code and create the additional activities (I did submit a patch with the changes)

This was a very interesting learning experience, delving into yet another one of Microsoft’s application suites. This also takes TFS’s capability and makes it available into areas that you would not necessarily have considered possible, further establishing TFS as a true ALM suite.

If you would like to know more, or would like TFS integrated into SCSM. Give us a shout..

FREE Visual Studio ALM preview! - CAPE TOWN

Visual Studio & Team Foundation Server 2012 is here, and during the months of November and December Team Foundation Consulting will be offering your company a FREE 1 hour ALM session.
These sessions will cover some of the new features available in TFS and VS 2012 and aspects of ALM.

All sessions will be presented at your premises, and availability is limited.
To book or enquire about a session please email info(at)teamfoundation(dot)co(dot)za or contact us via our contact page.

Note: Min 5 attendees required for sessions.

JHB - sessions will be made available in January/February 2013 - email us if you are interested and we will advise you when the sessions become available.

Process and the tool

Microsoft has a very competent ALM story that is being backed up by the Microsoft Visual Studio ALM “suite”. Don’t take my opinion for it though; Microsoft must be doing something right in this space to be one of the leaders in Gartner’s “Magic Quadrant for Application Life Cycle Management, June 2012”.

One thing I can point out in the diagram is that Microsoft is not the only player in the ALM space; there are a fair number of people with varying degrees of success battling it out.

The thing you should be aware of is that the tool itself is not the be all and end all of a “proper” application life cycle. I have come across a number of companies that are looking for a “tool” to solve a process problem.

The company feels pain in the way that they are doing things and then starts looking for a tool that will “solve” the problems. When the tool does not fulfil the need 100% they start looking at the next one (in some cases they have literally been looking for years).

The problem is that in all likelihood they will never be able to find the “right” tool, regardless of how complete a story the tool caters for, or how competent or proven the tool may be.

“Then what should we do?”

Glad you asked.
Firstly, take a deep hard look at your current process, highlighting the problems. It is important to be honest with yourself in this step. You will base your plan of action on the outcome of this step. (You may consider doing an ALM assessment that may give you some clarity on your situation or level of maturity https://www.microsoft.com/assess/almassessment/default.aspx ).

Next, find people that have had similar problems, or look at best practices that are being adopted and how they may solve your problems.

Next you need to make some hard decisions.
How are you going to change to relieve the problems? Something needs to give; some decisions need to be made. You cannot expect to follow the same process and somehow the problems will reduce or disappear (as Albert Einstein once said "The definition of insanity is doing the same thing over and over again and expecting different results"). The best development team can only do so much; the rest is up to the process that governs the day to day and week to week actions.

Finally you can start looking at the toolset that will support the process, taking note of the following (just to name a few) aspects:

• How do the various aspects of ALM integrate with each other?
  Do you have a single up to date and accurate “high level” view into the various aspects without needing to dedicate a person or resources to compile these reports or statistics?
• What value can you derive from the tool?
  Does it provide you a rich functionality with regards to reporting, accessibility, integration and/or usability?
• How well integrated is it in your day to day activities?
  Is it available when and where you need it to be with as little as possible context switching between applications or environments?

In conclusion, it is important to note the following:

• You cannot solve a process problem with a tool
• The tool needs to support and automate your process, bringing together information from every aspect of your project!

 

In need of process, ALM or Team Foundation Server adoption guidance?
Give us a shout!