Now, it´s time to move to the important stuff on our project. Ideally we would have most of our applications imported for now as we used distribution system, which we could expect including most of the applications. However, reality is that there is always applications which are unknown. I have actually never been involved in a project where customer had 100% confidence on knowing the number of apps, name, version, vendor and installation media. Those are the minimum requirements for having any level of application management.

This would be the point for importing rest of the apps, but it is not mandatory, you can actually do it later as you see best. This is important point when considering if AppDNA would be used for on-going application management after the project phase is completed. First of all, you appreciate the option to manage applications individually, instead of being forced to analyze your full stack every time you add an application. Unfortunately, many organizations consider AppDNA being useful for only the immediate pain on delayed migration. Guess what? Migration is not going to end, never. Projects can be considered as completed, but the process and need stays. Completing the project means just switching to a waiting mode – waiting for the next migration.

When the world is changing, you need to change too. What I mean is that users will be demanding new deployment options because they move between different user scenarios. For example, they want to use mobile devices instead of PC´s. Then apps should be touch friendly, which in turn would create demand for more advanced operating systems. Ok, we got little bit sidetracked…

Analysis process in such is very simple for administrator. Just choose the apps, relevant modules and analyse! In this stage, there would be option to create groups, families and suites of the applications. Let´s see that next and concentrate on the analysis.

Analysis can be shortly described with following illustrations. Even though this post is about analysis, it is important to start with showing overview on what we really have in database. In short, data about users, usergroups, organizational units, usage information, applications and operating systems. Operating systems shipped with the product are the vanilla versions, but in reality, every organization has customized their OS build, as minimum they have group policies. While we are not reading group policies from Active Directory, they can also be changes on operating system build and so can be captured. Captured OS is then imported, or multiple builds of specific version, and used on analysis. End result represents realistic deployment environment from technical perspective.