“Designed for operations” sounds like an obvious idea: If corporate developers take operational considerations into account when developing applications, IT shouldn’t have to worry about such things as application performance, security integration, or Help desk issues. But obvious or not, most applications are not yet “operationally aware” and don’t have manageability built in. As part of the Dynamic Systems Initiative’s (DSI’s) promise of end-to-end management, that situation is about to change. A new member of the System Center family, code-named Service Desk, is a step toward an integrated workflow that ties operational needs back to development by taking advantage of capabilities already built into Visual Studio 2005 Team System (VSTS). To find out more about Service Desk and the role of VSTS in DSI, I spoke with Sam Guckenheimer, a group product planner in the VSTS group.
Islands
Forster: What IT problem is Service Desk trying to solve?
Guckenheimer: The problem we saw is that you have, across the IT organization, all these little islands of activity. The thrust of the market for decades has been in optimizing these little islands. So you get very capable tools that focus on a specific role and make assumptions about where the role boundaries are. The CIO or director of application development looks at the result and says, "But if I measure end-to-end how well we align with the business, or I measure end-to-end our capacity and quality (i.e., how much we can deliver), or I look at how effectively we’re keeping our execs out of jail, I don’t get it." That was our view of the state of market.
Forster: Those islands of IT activity correspond to the application development responsibilities of application architects, developers, testers, and project managers, plus IT operations responsibilities. VSTS and Visual Studio 2005 Team Foundation Server are tools for the application development side of the picture, right?
Guckenheimer: We launched VSTS in 2005, and \[in 2006\] the addition of Visual Studio Team Edition for Database Professionals (VSDB Pro) was the first big update of that beyond SP-level stuff. It is our play in the Application Lifecycle Management (ALM) space.
Forster: VSDB Pro is a foray into the administration “island,” because it’s aimed at database administrators. Why did you start with VSDB Pro as the first step in connecting the islands?
Guckenheimer: When we introduced the Database Professional Edition of Team System, we took a huge elephant off the table. The process of doing application development in the past was one in which everyone who was working in the .NET languages, or even the older 3GLs \[third-generation programming languages\], had first-class tools, first-class change management, and they could do great testing and tracking. The database guy was completely second-class—stuck over the wall and typically could not work offline and have confidence that he or she was working with an offline image that matched the production system. All the \[database administration\] stuff is done on the production system. The database person could not work offline and apply it to production confidently, could not be sure that the changes over here in application development were consistently communicated or matched the changes that were being made in the database. Then the operations guys on the other end would catch this stuff from both \[development and the DBA\] and say, "Whom do I trust? Let’s shut everything down and have a staging party for the next 6 weeks."
Forster: So how does VSDB Pro address that situation?
Guckenheimer: The goal of VSDB Pro was to make the database a first-class participant in the same change management cycle \[as application development\], which squeezes a huge amount of that impedance mismatch out of the active-to-operations processes. You can now apply the same change management process to the database assets—the schemas, the stored procs, etc.—the same change management that you apply to the code and the same notion of change sets, the same ability to measure progress and functions as one team. You can have the same idea of a numbered build that applies to both. With database work, during development, you can get a direct view into the production assets for schema and stored procedures and what have you and then directly produce the alter-scripts and the like to make sure the production system gets updated as part of the kit that comes out of the build. We make it more efficient going forward and cut way down the rework coming back. One metric we track is reactivations—how many times something that was moved from active to resolved gets reactivated—as one of the key signs of dysfunction. So we’ve eliminated one of the huge sources of reactivation coming back from operations. That’s a first big step; that’s an indicator of the philosophy.
Forster: So VSDB Pro was the first bridge between development and operations. How do you build bridges to the other IT people who work in operations, and how does DSI come into the picture?
Guckenheimer:We tackled initially in Team System, the center of gravity of the ALM space, which would roughly fall under the Director of Application Development in most organizations. But we only did a little bit initially of tackling the end-to-end from the CIO’s view because now application development is maybe a continent instead of a set of islands. Then there are these big oceans between the other continents—operations and the PMO \[Project Management Organization\]. DSI is about spanning those oceans. We took some little steps in Team System initially with that. One is the integration of Microsoft Project, to connect to the PMO. One is in our Team Architect product: We introduced a capability called "Designed for Operations." The idea is that in design—i.e., at the beginning, before any code is written—you validate that the application as intended will conform to the data center as configured. We do that in Team System off what we call a Logical Datacenter Model, and that was the first time someone’s brought those things together. Now DSI is a shared vision among us in Team System and System Center and our colleagues in Project about addressing the CIO as a whole.
System Center Service Desk
Forster: So what are the next steps in bridging development and operations, and how does System Center, and particularly Service Desk, fit in?
Guckenheimer: What we need to do next, and the Service Desk project in System Center is a big move in this direction, is to start tying the workflows between application development and operations together. You typically have completely separate tracking mechanisms that don’t understand each other and communicate at best by copy and paste. With Team System, we have this notion of process templates, which are containers of workflow and work-item definitions, role definitions, reports and templates, and what have you. Those are the mechanisms by which we let you do \[a certain\] type of process on the project. Those contain workflow definitions.
The equivalent in System Center are the management packs that let you have all these definitions of content. We’ve looked carefully at what needs to happen in terms of initial workflows, and we’ll start to support automation. So for example, you have a set of incidents in operations and you say, "It looks like something here needs to be escalated to development." You roll those incidents up and report a bug to development for investigation. Under the covers, the events flow back and forth, so if someone in development says, "No, I don’t think so," that comes back. Then as that’s closed, you know from the development side what build with what alter-scripts for the database, what binaries for the code, need to move over into the operations world.
Similarly, we have workflows to request and capture diagnostic detail around problem reports from operations into development, back and forth. So workflows are the next layer and should start to materialize as Service Desk moves from being a project into its productization.
Forster: You spoke before about metrics in VSTS. Will System Center also tie into these metrics?
Guckenheimer: In Team System, we have a Metrics Warehouse, and we service a portal that gives you reporting status off it. We show you the flow of work moving through the application development process. Metrics Warehouse becomes reality in the System Center line, as well. We collaborate on schema to allow us to tie these things across common business initiatives. \[For example, you might have\] this thing in operations called the CRM system. It relates to projects in development around customer self-service, and supplier integration, and sales-force enablement, and what have you that have different names but are tied to the same business initiative. You can start to track that as one business initiative of one interest to the CIO and business stakeholders.
The vision is that we take our capabilities on both sides of our respective Metrics Warehouses and the ability to use common schema and roll these up. This is possible through the SQL Server plumbing we’re all using, so much of that can simply go to a customer-facing portal or an internal dashboard. Someone in the sales organization could look at the CRM system as a whole in one place \[and see\] the quality metrics from development and the Key Performance Indicators (KPIs) on availability and performance from operations.
Forster: How will IT and development use these capabilities to work together?
Guckenheimer: Everyone is working on the same problems and looking for the same opportunities. An example of what you can start to do: You can start to expose relationships that in the past were simply unthinkable. Today in Team System, we have a report called Quality Indicators. It shows you on one graph test-pass results (pass, fail, inconclusive) against active bug count, against code churn (that is, new and added lines of code), against code coverage from those tests. So all of a sudden you can start to detect things like the tests are passing and the bugs are low, but code coverage is also really low and code churn is going up. What does that mean? It means your tests are stale. You’re only testing the old code, which is passing—not surprisingly—and the new stuff is getting ignored. So you don’t know where you are, so you need to redirect your testing effort. That kind of relationship is something people are not used to getting objectively.
Well, imagine you could do the same thing connecting to operations. So for this CRM system, you could see pretty clean information in terms of quality metrics in development but these big performance problems in the data center. From that, you might discover that you have a change management issue—they’re not running what you thought they were running because you can suddenly see them together. Then the discussion moves from \[application development and operations each saying\], "You don’t know what you’re talking about. You don’t know how to write software that works." \[Instead, both sides can say\] "There’s a problem of mismatched versions here and we have to get to the bottom of that."
Forster: What is important for IT about VSTS and Service Desk integration?
Guckenheimer: Most IT guys are pretty conscious of the problems. They know, for example, that software health is a big issue. They don’t have a good way of doing health monitoring. They know that the kinds of things they can monitor are very poor indicators of what’s going on in the software. When they try to escalate something to development, they get into this horribly dysfunctional conversation where development says, "You never give us the data we need," and they say, "I’m giving you all the data I’ve got!" I think what’s been missing is the ability to say to the application development team: "Look, I’m not going to make your life any more difficult. I’m in fact going to make it a lot easier." You plug these things together, and all of a sudden you can roll up the incident data with your bug and drill into the trace data associated with it for diagnosis, without having to ask me for more stuff because we can automate that. Look, here’s how you can take advantage of our datacenter model to understand how your application would fit into that datacenter. Look, here’s how you can apply what we call a Software Factory—that is, a standardized pattern—to instrument your application for manageability so that when I’m trying to understand the data, I can understand directly the application health because it’s built in.
Getting Started
Forster: Service Desk is in very early stages now, so how can IT pros start moving down the path you’re creating?
Guckenheimer: If they’ve started to look at VSTS, there’s already a Designed for Operations starter kit that’s available to download http://msdn2.microsoft.com/en-us/teamsystem/aa718768.aspx \]. The Visual Studio 2005 Design for Operations Integration Kit integrates and automates the communication and management of unhandled application errors and performance bottlenecks. You can use this sample code, and application faults and performance bottlenecks will automatically generate trouble tickets in VSTS, giving development and operations teams clear insight into the behavior and health of .NET applications. It takes the operations workflows and ties them back to the development workflows.
That’s freely available off the Web. Pick up this starter kit, install it on your VSTS, and all of a sudden you can have operations projects in there, too. That will be less relevant when Service Desk goes from project to product. We don’t push Team System as the thing for operations, and this is a starter kit intentionally. It’s the Service Desk project that’s going to flesh this out properly for operations, but that as a first step will give people insight into their current situations and the opportunity just through regularization of the process and a little bit of tooling to start to improve it. Look at the model of tying the team together on a collaboration platform and think of yourself as one of the collaborators.
