For the last year or so I’ve been giving talks about trends in software development and particularly ALM.  I’ve described one of the big upcoming trends as the need for better collaboration between development and operations.  The state of that collaboration today is not great even given our current technology stacks.  However, as cloud architectures become more and more common and the need for being “up to date” with short release cycles continue to accelerate, we are going to see ever increasing demand for the development and operations teams to work closely together.  In some orgs we’ll even see some blurring of the line between the two – there’s recently been a lot of talk about a new pedigree called DevOps.

VS ALM has always been about connecting people involved in the software lifecycle.  When we launched VS 2010 and introduced a slew of new testing tools, we talked a great deal about the vacuum between Dev and Test – the lack of consistent tooling, organizational barriers, poor communication, lots of wasted time, energy and frustration.  One of the pillars of our VS 2010 release was to tackle this problem.

In the next VS release, we are tackling the problem of Stakeholder <-> Development team collaboration.  You can read more about the announcements we’ve made around that here: http://blogs.msdn.com/b/jasonz/archive/2011/05/16/announcing-alm-roadmap-in-visual-studio-vnext-at-teched.aspx.  And I’ll be writing more about that in the coming weeks.

I’ve generally been describing the Operations <-> Development team collaboration problem as the next problem to tackle in Visual Studio V.NextNext.  I’ve had a few conversations with the System Center team about what that might look like but it had all been pretty low key because we’ve been so focused on our current deliverables.  Then, to my surprise, a month or so ago, I got invited to a demo by the System Center team where they showed connectivity between System Center and TFS.  I was so excited I was drooling the whole time I think.  Yesterday Jason, announced a CTP of this new technology at TechEd.  What I fear may not have been entirely clear is that this is NOT a VS V.Next feature.  This feature works with TFS 2010 TODAY!  It’s only in CTP form now and we’ve got some work to do finishing it off – but it’s a workable solution TODAY!  I don’t yet know what the ultimate release schedule for this will look like but I’ll let you know more as we figure it out.

Let me expand a bit on how this works (beyond what is in the whitepaper I referenced above):

First, the SCOM-TFS Connector is a set of services that run on your SCOM Root Management Server (RMS) that synchronize data between System Center and Team Foundation Server.  It enables the operations team to work as they always do inside Operations Manager and yet collaborate easily with the development team.  Let’s walk through a scenario…

An operator gets an alert of an operations issue in production and opens Operations Manager to review the alert.

The operations engineer reviews the knowledge base associated with the alert and sees that this particular class of issue can’t be addressed with configuration but needs to be escalated to the development team.

The operator can right click on the alert and set the state  to “Assigned to Engineering” (yes ignore that this is missing from the menu in the screenshot – it will be there if you install the connector.  Sorry for the broken screenshot).

Every alert in System Center is associated with some deployed component.  When you configure the Connector, you map each component to a TFS project.  The connector will notice the state change in System Center and seamlessly and automatically open a new work item in TFS in the associated Team Project.  The new work item will be of type “Operational Issue” (which will need to be added to the process template for every Team Project mapped to a System Center component).  The Operational Issue captures all of the information from the System Center alert and implements a simplified operational workflow.

Now, that new Operational Issue will magically appear in TFS project in your development environment.  You can query for them, assign them, etc the same way you do any other work item in TFS.  Further, you can navigate links in the work item back to information stored in System Center.

Ultimately, the operational issue is likely handled in one of 3 ways:

1. The developer diagnosed the alert and recommends a work around to the operations team.  He/she can do this by simply updating the operations issue in TFS with the appropriate work around steps and the TFS-SCOM connector will automatically pick up those comment and replicate them into the System Center alert for the operator to see and take action on.
2. The developer can file a new bug and link it to the operations issue.  The bug can then be prioritized and scheduled to be addresses as is appropriate within the team’s schedule.
3. The developer can ignore the issue by just closing it – OK, your operations team will be cursing you, but you can do it 🙂

I’m really thrilled to see this incredibly important scenario enabled by the TFS-SCOM connector.  It’s the first step of many in the journey to connect the development and operations teams together to build, deploy and operation first class services for their organizations.

Please try it out if you have the chance and let me know what you think!

Brian