For several years now we have been banging a drum trying to let as many folks as we could know that some important things have changed in application management. If you are facing a big migration or transformation project or just trying to get your arms around the day-to-day running of application management and wondering how on earth you are going to be able to certify the hundreds or thousands of applications under your responsibility read on.

Traditional wisdom says you need to install, run and test the applications to understand if they will work on Windows 7, 64bit, virtualized or with other technologies and, if you have the time, budget and nerve you could still do this. If you’ve done it this way before you know the pain. Oh, and what about your web apps, will they work in IE8/9/10?

Turns out there is a smarter way – its based on doing rapid, automated high volume processing of all of your applications by collecting their DNA. Add to this DNA for your applications a DNA scan of your current OS as well as your planned new OS and you end up with something approximating an abstracted computing environment. This for both Windows Client and Windows Server environments

Stop for a moment – its a pretty powerful concept.
– You can now query and model your environment without having to install and run, app by app.
– You can see all applications together, as a whole
– You can assess OS builds and how they impact compatibility
– You can begin to understand relationships between apps and the OS

But wait, there’s more!
Why not add to the OS and application DNA by including users, groups, devices as they exist in the environment. Now you’re stepping outside of the application portfolio and adding the ‘real world’ context where the apps get used.

– You can represent applications and OS compatibility by groups of users or devices
– You can segment and phase rollouts based on group suitability
– You can perform what-if scenarios without installing anything

Ok, marketing aside, lets look at what the DNA is and what’s possible with it. Also, what’s not possible.

The first thing to understand is how we collect the DNA – that determines what is accessible to us. Our primary objectives are speed and breadth – getting as much holistic knowledge as we can as quickly as possible about each application. We operate on applications as represented by their installer packages – the logic is that everything that makes up an application is contained within the installer. While this is not the whole story – apps typically put files and settings down when they run, interact with the environment and perform various functions not described in the installer – it is a very powerful starting point and serves our primary objectives. The installer format of choice is the Windows Installer format (MSI) as this is a ‘transparent’ database format which has a well formed structure and can be queried as well as providing easy access to all of the files – binary and other formats – and facilitates what we call ‘static’ analysis (the ability to derive DNA without running the application). MSI is great for abstracting how an application will install without actually doing the installation and we leverage this to our advantage.

We now know what all of the files and components are and where everything will install to (files, registry, configuration, etc) and this is our first ‘layer’ of DNA information. This is powerful but not enough. For the next layer we extract all of the files to a temporary location and analyse each file ‘statically’ i.e. we don’t install or launch the files but read directly the binary headers which provides a wealth of information about API’s published and imported as well as file dependencies, ‘bitness’ (16/32/64 bit) and digital signing. For text based files we store the data for later analysis e.g. driver configuration files.

Knowing this much about one app is powerful, knowing this about the entire portfolio is huge.

Image: the components of application DNA

Key concept: we don’t deploy agents to collect the data, we import application packages directly (e.g. a software library or file-share/deployment source). Again, this allows for high-volume, rapid collection in depth and meets our primary objectives. We also know about every file and API in the application – running agents to ‘listen’ to application behaviour requires time and also requires that users fully exercise the application before getting a complete picture. This approach also lacks any install information or view of the application and all of its components. There are very good reasons to make use of agent based systems to augment the DNA (and we do) but as a primary means of representing an application completely they lack detail.

What are the boundaries?
The great news is that all apps that run on Windows at some stage, irrespective of programming language, need to be compiled into a common format in order to run on Windows. It is this common format we use for our static analysis approach. A notable exception to this is Java. Java effectively has its own portable runtime environment and Java tends to carry its own compatibility challenges between different versions and, while largely opaque to AppDNA we do quite a bit of analysis to expose Java apps, Java components and apps which contain or rely on Java.

Another common case is Microsoft Office. Most questions around Office relate to office data files and wether or not old files will run on newer versions of Office. We don’t scan Office files (Think Excel with macros forming an ‘app’) in order to do this sort of analysis. What we do do, though, is identify other applications which may be plugins to Office, rely on Office or contain Office files or have dependencies on it. This is pretty useful when looking for an Office ‘surface area’ to assess potential migration issues.

Non-MSI formats
Many of you will already have identified that there are loads of installer formats other than MSI and you’d be right to ask how we handle these. Another of our primary objectives has always been to be able to import any format of application. Our approach to to facilitate the installation of non-msi formats during the import process and building an MSI to represent the application and then importing the application via that MSI. This process is managed via an automation layer which spins up a VM and performs tasks necessary to install and capture the application to MSI.

As mentioned above we do not make use of agents as a primary collection mechanism but equally we recognise the value of what can be collected via agents. One of the first processes in application management is auditing of the environment and agents are a powerful way to achieve this.

A ‘blind spot’ with static analysis are things which occur at runtime and things which exist in the operating environment. These include late binding of dependencies, database connections, dynamic modifications to the filesystem, settings, personalisation, data creation and other aspects which define the application in terms of its components. Other key information such as performance, memory consumption, usage, utilisation and other aspects relating to access and usage of the application are all best collected via agents and, in some cases, this is the only way to extract the information from the environment.

With our latest version 6 release we launched integration with Lakeside’s Systrack agent based analytics. In our first phase we leverage Systrack to identify which applications are out in the environment in order to perform inventory and rationalisation of the portfolio.

The operating system
It’s really important not to forget the operating system when you’re considering the apps. It seems logical but there has never been a way to think about how changes to the OS image/build might impact an entire portfolio. Equally how tweaks to the OS image might resolve issues across the whole portfolio. This is a new and really important concept – you can actually see the impact of the current and planned OS will have on the portfolio. You can also store multiple reference images for different build within AppDNA to compare relative impact.

Wrapping it all up
Collection of application DNA is where we have spent much of our engineering effort over the past few years and its the cornerstone of our ability to predict with accuracy outcomes for the various technologies we report on. Making sure that collection is deep and fast makes large portfolios accessible like never before. Added to the DNA foundation is our unique algorithmic approach to surfacing issues and our flexible, customisable reporting framework which combing into an application management platform capable of removing the complexity of migrations and day-to-day portfolio management. I hope this provides a sense of just why the DNA thing is such a big deal to us.