Archive for the ‘Software Development Lifecycle Management’ Category

How to sell to over one million .NET developers with VS 2010 and VSTS 2010

Monday, June 15th, 2009 by Sebastian Holst

Roughly 15% of all Visual Studio developers have used Dotfuscator Community Edition (CE) to prevent reverse engineering (and I think we can all agree that this is a relatively specialized requirement). If you accept the next uncontroversial assumption that more developers would want to know who is using their software, how and why than would be concerned about reverse engineering – then we can also assume that the new Dotfuscator CE that includes application monitoring capabilities will be adopted by perhaps 2X or even 3X more developers – or between 30% to 45% if the 6 million+ Visual Studio users.

This next series of posts will outline specific opportunities for entrepreneurial developers to build solutions targeting the millions of .NET developers likely be using these new capabilities as VS2010 reaches general availability.  For an earlier example of this, see my blog entry how to make $5 from every .NET developer on the planet.

Post 1 – Code coverage!? I got your code coverage right here pal!

If you think development teams would benefit from being able to readily reconcile testing code coverage results with beta usage code coverage to improve quality and reduce development costs – read on…

With VS2010 Dotfuscator CE feature tracking, you can stream back feature usage during a beta release that can provide a complete picture of what methods were called, in what order and on what technology stack. If only there were an easy way to not only visualize this in the context of the application’s code base but also to overlay this information on earlier testing code coverage results to ensure I have tested what is being used and my beta users are using what I think needs to be tested! That might be an opportunity…

We’ve got an “opp” for that! (apologies to the iPhone ad guys). If you have evaluated VS Beta 1, you may have already noticed that VSTS 2010 Architecture is a completely new release which leaves behind the current Distributed System Designer and the underlying System Definition Model (SDM ) and replaces them with the Unified Modeling Language (UML), Domain Specific Languages (DSLs) and other tools that are not related to UML. The specific tool I want to point to here is the Architecture Explorer (AE).  AE visualizes relationships inside code using the Directed Graph Markup Language (DGML). By extending the DGML, one can use the Architecture Explorer to create visual models of assemblies – post-build – combining both the relationships inside the code (this comes with AE out of the box) and testing and usage coverage results by extending the styles already included in AE. In short, The Architect Explorer with its DGML support and the ability to extend/modify styles offers an ideal means to quickly reconcile usage data with testing code coverage (and platform and framework coverage as well).

This screen shot shows a generic rendering inside the VSTS Architecture Explorer. The rendering is entirely driven through XML data and, as such, can be easily extended to provide specialized views that are relevant across the entire lifecycle of an application.

In this case, the color schemes (or fonts or sizes) can be driven by:

The level of testing completed as reflected inside a TFS repository to quickly answer the questions

  • Testing status – how much testing has been completed?
  • Testing the right things – are there components that should be getting more (or less) attention?

The level of usage by beta test users as reported via the instrumentation capabilities included in Visual Studio 2010 Dotfuscator CE to quickly answer the questions

  • Beta adoption sufficient – have enough users actually run the software through its paces?
  • Critical path coverage – are the new components being exercised as expected?
  • Testing coverage map to usage profile – combining both testing data and usage coverage data can identify areas of code that are not being tested sufficiently given the patterns of usage that are being observed? (mash up)
  • Platform/framework coverage – are enough users evaluating on Vista SP1 or .NET 1.1 or …?
  • What exceptions have been detected that have not been reported through other channels?

Notes from the RSA Conference

Wednesday, April 29th, 2009 by Sebastian Holst

I have just returned from the RSA Conference where I stumbled on a business opportunity that I think is out there for anyone addressing log and event management requirements.

On Thursday, April 23, there was a session entitled “Common Event and Log Standards: Leveling IT’s Tower of Babel.”
The abstract stated, in part, that:

“The IT industry suffers from a lack of standards for event, log, and audit information. Regulatory requirements to retain, protect, and destroy log data continue to increase. Organizations also need better situation awareness and cost control across complex IT security event horizons. The good news is that standards efforts are underway,…”

XDAS (for more info visit http://www.opengroup.org/security/das/xdas_int.htm) is one standard being developed/promoted to address these issues and the Common Event Expression (CEE) language, being developed by Mitre is an even broader effort that will, ultimately, subsume the former (for more information visit http://cee.mitre.org/). …but these efforts are, as a direct consequence of their ambition and generality, complex and solutions/implementations live somewhere in our future.

There is, of course, an established market for log and event management solutions that address the current heterogeneous and, often, incompatible log and event data streams and sources – do a search on “log and event management” as a case in point. Many of the vendors that will pop-up were also exhibiting at the RSA Conference – both promoting the value of Security Event Information Management (SEIM) and capitalizing on the confusion that stems from the lack of standards in this important field.

Well check this out…

In 2008, Microsoft announced that Visual Studio 2010 would include an extended version of Dotfuscator CE that would include, for the first time, the ability to inject tamper detection, application expiry behavior, session monitoring, and feature tracking – all post-build, without programming, on virtually every flavor of the .NET framework.

This move essentially enables the 6 million+ Visual Studio programmers to retroactively add streaming logs to virtually every .NET application ever written – and guess what? They will not only stream to any endpoint specified (dealing with distributed and cloud-based components) – they will ALL SHARE THE SAME SCHEMA!

– PROBLEM SOLVED????

Of course not – but here are some obvious implications

Given the historical adoption precedent of obfuscation, it is highly probable that 30%-40% of .NET developers will experiment with and incorporate these new capabilities into their development efforts. That’s millions of developers and many many thousands of software components.

As post-build injection becomes more widely accepted as a standard practice, the Java community’s adoption of similar capabilities is likely to increase as well (we support injecting the very same “streaming logs” into Java).

OPPORTUNITY

SEIM and Control Vendors – build-in support for the SOAP signals that will soon be a de facto standard on the .NET platform – differentiate your solutions by getting ahead of the .NET 4.0 curve and establishing yourself as a leader in application security event information management (aSEIM).

Application and Information Management Service Providers – expand your practices to address both the opportunities that this kind of application monitoring offers as well as any potential for abuse.

When 6 million of your closest developer friends have a technology in their arsenal – will it be too late for you to claim to be an expert?

For a more chatty discussion also inspired by the RSA Conference on why Cloud Conferences will never replace live events (and therefore, why Cloud Computing will never replace installed software) - visit my personal blog - Applications Are People Too

How do you get $5 from every .NET developer on the planet?

Tuesday, April 7th, 2009 by Sebastian Holst

Here is an idea that I have been telling anyone who will listen, but as far as I can tell, no one is doing anything about it.

Back at PDC 08, Microsoft announced that Visual Studio 2010 would include “Application Feature Monitoring, Usage Expiry and Tamper Defense capabilities.” These capabilities will be delivered inside the next generation of Dotfuscator CE (now to be called Dotfuscator Software Services) and will be included in the box with Visual Studio (except the Express SKU) with no registration or any other steps required.

Specifically, the tamper detection functionality referenced here will enable any Visual Studio user to inject tamper detection logic POST-BUILD into any .NET executable (assuming it is not already signed). Once this step is complete, the application will (when tamper is detected) have the ability to:

a) halt execution AND

b) (here is the important bit) send a SOAP signal to an IP endpoint of the developer’s choice.

So, how do you get $5 from every developer on the planet?

Use social networks or any other communication tool you prefer to make the following offer:

  • For $5 per month retainer, you will provide an IP address for developers to use when building their applications. If their application is ever tampered with (and it has access to the Internet) the SOAP signal is delivered to your endpoint.
  • Your service will notify them upon receipt. Why not use Microsoft’s cloud services to host a simple SharePoint application for this? They can then take appropriate action.
  • You can optionally set some sort of per incident fee as well if you like.

Every developer who moves to Visual Studio 2010 will have all of the software you need them to have installed in their environment - so there are NO software distribution requirements.

All you need to do is write a simple hosted endpoint, provide the IP address, and collect the subscription fees.

This functionality is already exposed in the CTP release of Visual Studio 2010 – you can begin this project today without contacting PreEmptive at all (although, we are happy to assist if you want to take advantage of any/all of our commercial extensions).

What do you think? There is a similar service possible with Shelf-life (also included in the new Dotfuscator Software Services community edition).