For several years now we have been banging a drum trying to let as many people as we could learn some important things have changed application management. If you face a large migration or transformation project or just trying to get your arms around the management of application management on a daily basis and wonder how on earth you're going to be able to certify the hundreds or thousands of applications under your responsibility read on.
conventional wisdom says you need to install, run and test applications to understand if they will work on Windows 7 64bit, virtualized or other technologies, and if you have the time, budget and the nerve you can still do it. If you did it that way before you know pain. Oh, and on your web applications, will they work in IE8 / 9/10
Turns out there is a smarter way - his base quickly to the automatic processing of all applications, high volume collecting their DNA. Add to this DNA for applications, a DNA analysis of your current operating system and your new user's operating system and you end up with something approximating an abstract computing environment. This time for the 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, application to application
- you can see all the applications together, as a whole
- you can assess OS builds and their impact on the compatibility
- You can start to understand the relationships between applications and the operating system
But wait, there's more!
Why not add DNA to the operating system and application by users, including groups, devices as they exist in the environment. Now you step outside of the application portfolio and adding the context of "real world" where applications get used
now
-. You can represent applications and compatibility of the operating system by groups of users or devices
- You can deploy segment and phase depending on group fitness
- You can perform simulation scenarios without installing anything
Ok, aside marketing, lets look at what DNA is and what is possible with it. Also, what is not possible
The first thing to understand is how we collect DNA -. Who determines what is accessible to us. Our main objectives are the speed and scale - get as many holistic knowledge we can as quickly as possible on each application. We operate applications represented by their installation packages - the logic is that everything that makes a request is contained in the installer. Although this is not the whole story - Applications generally put files and settings down when they run, interact with the environment and perform various functions not described in the installer - there is a point starting very powerful and is our main goals. The format of choice Installer is the Windows Installer file (MSI), as this is a format "transparent" database that has a well-formed structure and can be queried while providing easy access to all files - binary formats and others - and makes what we call the "static" analysis (the ability to take DNA without running the application). MSI is ideal for abstracting how an application will install without actually doing the installation and use to our advantage.
We now know that all files and components and everything will settle in (files, registry, configuration, etc.) and this is our first "layer" of information from DNA . This is powerful, but not enough. For the next layer we extract all the files in a temporary location and analyze each file "statically", ie we install or launch files, but directly read binary headers that provides a wealth of information on API published and imported as well as file dependencies, 'bitness' (16/32/64 bit) and digital signature. For text files on the basis that we store the data for later analysis, for example the driver configuration files
Knowing this application is a lot about the powerful, knowing this about all the portfolio is huge
Image: .. components of the DNA of the application
key concept: we are deploying agents to collect data, we import application packages directly (eg a software library or source / deployment share files). Again, this allows high volume, rapid collection in depth and meets our primary objectives. We also know about each file and API in the application - running agents to "listen" to the behavior of the application takes time and requires users to fully enjoy the application before a complete picture also . This approach also lacks any information system or for the application and all its components. There are very good reasons to make use of agent-based systems to increase DNA (and we do), but as the main means to represent an application completely they lack detail.
What are the limits?
The good news is that all applications that run on Windows at some point, regardless of the programming language must be compiled in a common format to run on Windows. It is this common format we use for our static analysis approach. A notable exception is Java. Java actually has its own Portable Runtime Environment and Java tends to achieve its own compatibility problems between different versions and, while largely opaque to AppDNA we do a little analysis to expose Java applications, Java components and applications that contain or rely on Java.
Another common case is Microsoft Office. Most questions around Office relate to office data files and wether or not the old files will run on new versions of Office. We do not sweep Office files (Excel Think with macros forming an "application") to do this kind of analysis. What we do, however, is to identify other applications that include desktop plugins to press Office or Office files contain or have dependencies on it. This is very useful when looking for a 'surface' office to evaluate potential migration problems.
Non-MSI formats
Many of you will already have identified that there are loads of installation formats other than MSI and you are right to ask how we treat these latter. Another of our main goals has always been to be able to import any application format. Our approach to facilitate the installation of non-msi files during the import process and building a MSI to represent the application, and then import the application via the MSI. This process is managed via an automation layer that runs a VM and performs tasks required to install and capture the MSI application.
Agents
As mentioned above, we do not make use of agents as a primary mechanism for the collection, but we recognize the value of what can be collected by the intermediate agents. One of the first processes in application management is environmental auditing and agents are a powerful way to achieve this.
A "blind spot" with the static analysis are things that occur during execution and the things that exist in the operating environment. These include late binding dependencies, database connections, dynamic changes to the file system, settings, personalization, data creation and other aspects that define the application in terms of its components. Other key information such as performance, memory consumption, use, usage and other aspects related to access and use of the application are better collected through agents and, in some cases this is the only way to extract information from the environment.
with our latest Version 6 we launched integration with the analyzes based on the Lakeside SysTrack agent. In our first phase, we leverage SysTrack to identify applications are in the environment to perform inventory and portfolio rationalization.
The operating system
It's really important not to forget the operating system when considering applications. It seems logical, but it was never a way to think about how changes to the OS image / build could impact an entire portfolio. Similarly how tweaks to the OS image could solve problems across the entire portfolio. This is a new and important concept - you can actually see the impact of the current operating system and will be provided on the portfolio. You can also store multiple reference images for different building within AppDNA to compare the relative impact.
Wrap everything
Application DNA Collection is where we spent much of our engineering efforts in recent years and its cornerstone our ability to accurately predict the results for the various technologies that we present on. To ensure that the collection is deep and fast makes large portfolios accessible as never before. Added to the founding of the DNA is our unique algorithmic approach to issues surfacing and our flexible reporting framework, which customizable combing an application management platform to eliminate the complexity of migration and day-to-day portfolio. I hope this provides a sense of just why the DNA thing is a big problem for us.
0 Komentar