Original URL: https://www.theregister.co.uk/2007/05/23/beyond_orcas/
Microsoft's Somasegar shares his vision for Visual Studio
Whatever you think of Microsoft, it's clear that it produces excellent developer tools, which are extremely popular with its customers. We're talking about Visual Studio Team System (VSTS) here, and its next two incarnations, codenamed Orcas and Rosario (see Gavin Clarke's article here).
However, Microsoft is sometimes criticised for being too code-centric, at a time when the trend seems to be towards business service delivery and business service management. What this really means is that business users are increasingly expecting to get holistic business services – complete with manual process around the automation, security, reporting, compliance and installation maintenance and retirement process – out of its technologists, instead of just code.
And this implies that portfolio management, and business and operational process analysis and design, are just as important as the conventional code-centric development process. And also, that operations staff (operators, schedulers, help desk, compliance and security people) have equally as important "requirements" as their traditional "end users".
So, when we had a chance to talk with Somasegar (Microsoft's corporate VP, developer division) recently, we asked him how Microsoft intended to respond to this challenge, if it intended to respond at all.
Well, Somasegar explained, the original Microsoft vision was to make the individual developer productive. "Then we thought, instead of making the individual developer productive, let's make the development team as a whole highly productive...but still thinking in terms of applications, code." This is roughly where VSTS is today.
But now Somasegar has a new vision. "How do we make the entire IT organisation productive and agile; and deliver a set of services to meet its SLAs (Service Level Agreements) in the process?"
The vision he described appeared pretty radical, for Microsoft at least. He sees three balanced domains: catering for the developers Microsoft currently supports with VSTS, project managers (MS Project Server), and operations (MOM etc).
Microsoft already has products in these domains, but what is different now is its vision of bringing its Dynamic Services Initiative (DSI) to fruition, with all three domains part of an integrated "business automation" view. Although this is some way out, Somasegar admits that Microsoft is "only starting to make baby steps in DSI".
A common language (called SML – the Service Modelling Language, now submitted to the W3C) will describe configuration, deployment, monitoring, policy, health, capacity planning, target operating range, service level agreements in all thee domains; and each will have equal weight. Behind it will be a central, server-based metadata repository (Team Foundation Server).
But hold on, isn't this more-or-less IBM's AD Cycle vision from the last century – and that didn't work out too well in practice. Is Microsoft suffering from what Fred Brooks called the "second system" trap – having been well-impressed by the power and authority of IBM while it was growing up, Microsoft might now be trying to show off by taking on one of IBM's "failures" and making it work, instead of doing something radically new?
Well, even if it is partly doing this, it doesn't seem to be conscious of it, although AD Cycle does provide an interesting frame of reference. For a start, there wasn't much wrong with the AD Cycle vision. It foundered because (almost certainly) most companies weren't mature enough to implement the process vision and measure compliance, and because (possibly) the technology wasn't up to providing the necessary "user experience". And because, at first, IBM physically tied the logical vision to a central mainframe repository – although Microsoft might ponder that last one, as its tool architecture is irretrievably welded to Team Foundation Server just now.
And, Microsoft might want to think about whether it'll also have to encourage a mature "process improvement" culture in some of its customers, although it shouldn't have (technical) problems with the "user experience" this time.
There's another possible issue. Part of the secret of Microsoft's success with development tools is that it mostly doesn't compete with its partners – it's happy for Borland, say, to provide requirements management for VSTS. However, without announcing anything as definite as product, Somasegar implied that Microsoft would deliver a complete toolset for this new service-based vision – although it's still committed to providing an "open" (as long as you stay in .NET) tools platform, so perhaps it'll only compete with its partners on a level playing field.
Somasegar himself admits that his high-level vision isn't new – so why does he think Microsoft will succeed with it this time? Well, he says, because his tools will be designed as an integrated whole, from the ground up; while his competitors (and Microsoft itself, in the past) rely on buying in established tools; and are then crippled by point-to-point integration issues.
Will this new vision really work, then? It is, of course, too early to say – and Microsoft's culture might be irretrievably code centric (although Microsoft has proved entirely capable of reinventing its culture in the past).
Nevertheless, Somasegar appears to be fully aware of the cultural issues and when asked about the CSF (Critical Success Factor) for this vision, he immediately replied that it was the integration of the developer, management, and operational tool cultures within Microsoft. However, a reasonable success indicator is that all three of these now report into a common manager within the Microsoft organisation. ®