Today’s Enterprise Application Delivery Framework
Introduction. What is an ‘Enterprise Application Delivery Framework’?
It is a strategic framework which provides various application delivery mechanisms for your corporate application portfolio which could be anywhere from 50 apps to 5000 apps.
Building an application delivery framework is understanding that applications will not all fit into one delivery strategy, it is always going to be a hybrid of technologies that enable application delivery to the enterprise. This is becoming more prominent now that enterprises are switching from XP to Windows 7 without any clear strategy on what to do with applications that are not compatible.
An Enterprise Application Delivery Framework provides:
In my experience many applications on the app portfolio list have been customised using a ‘wrapper’ which automatically checks for configuration changes and updates or attempts to configure the application in the context of the user before the full application launches. This provide many headaches when attempting to stay with the security policies of a standard operating environment. These applications need to be given special consideration in how they are deployed into a Windows 7 standard operating environment.
Let’s take a look at how your enterprise devices may look.
Enterprise Device Layers
Layer 1 – Windows 7 SOE (Standard Operating System Environment)
Layer 1 is the standard operating system environment. This layer includes hardware drivers plus core operating system applications such as Internet Explorer 8 and Windows Media Player.
There are many other applications which are classified as ‘core’ applications. However, they are not delivered as part of the build image which ensures that the image is streamlined and easy to manage. The Windows 7 SOE layer should only be updated when a core component of the operating system is updated and not when an application requires updating. Core applications are categorised as such due to the global footprint across the business, Adobe Acrobat Reader and Microsoft Office 2010 are examples.
The Windows 7 SOE environment is built around speed, security, stability, standardisation and streamlined desktop management. Speed includes quick boot up times, fast logon due to the removal of domain logon scripts and stability ensuring only Windows 7 components are included in the build and change control work flow built around desktop management.
Layer 2 – Traditional Installs
Layer 2 is represented as the traditional layer where applications are ‘locally installed’ into the build in the traditional method as MSI’s using Microsoft System Centre Configuration Manager. (SCCM)
Applications installed into this layer are typically core applications as mentioned above such as Microsoft Office 2010 (although this can be virtualised) Adobe Acrobat Reader, WinZip and SAP. Applications that require a traditional installation usually require deep integration with the Windows Operating System for example, SAP can be heavily integrated into Internet Explorer.
The term ‘traditional’ is used here because applications that are installed aren’t portable and have to be installed and pre-configured before a user has the ability to use them. Once installed, applications become totally integrated within the operating system making future upgrades and regression testing difficult. Application conflicts can also be very common with locally installed applications, usually 2 versions of the same application cannot work side by side which can introduce risk and decrease agility when wanting to test and roll out future versions.
Future application provisioning using traditional installs can also introduce risk due to common component conflicts, you never quite know if a new version of a particular application is going to have an effect on others unless a strict regression testing plan is followed.
Layer 3 – Application Virtualisation and Cloud
Application virtualisation was always considered as the future of application delivery and in many scenarios where cloud services are not an option it still is. Application virtualisation provides an abstract layer where applications are pre-cached and are ready to run without the need for pre-installation or configuration. The abstract layer (where applications are pre -cached) can be flushed at any time leaving the build clean and free of any type of installation. Applications that have been virtualised are agile and will follow the user across the enterprise. Application deployment is accelerated due to the decrease in regression testing required and low risk of deployment.
Cloud is included here also, depending on how you think of cloud enabled apps they are generally cached in HTML5 browsers and are obviously low risk in terms or regression testing and deployment.
Layer 4 – Apps Accessed Remotely.
Layer 4 illustrates how many applications that are not Windows 7 compatible or supported by the vendor would be hosted on Citrix XenApp or a similar platform. It is likely that a very large application portfolio would include many applications hosted on Citrix.
Layer 5 – VDI Desktop
The VDI Desktop layer is illustrated only to detail the delivery of certain applications that will not run on the Windows 7 device or will not run on a Citrix server (due to multi user restrictions). Instead these applications are provisioned on a virtual dedicated XP desktop within the data center.
Now that we have seen how you can split your device into Layers, lets take a look at the primary delivery mechanisms that match these layers.
Application Delivery Types
Note: Any delivery type from 3 to 5 could be a default delivery mechanism depending on your strategic direction.
Type 1 – Microsoft System Center for ‘MSI’ Applications
Microsoft System Center Configuration Manager (SCCM) is the delivery mechanism used to deploy MSI applications. All applications delivered by SCCM are pre-packaged into Windows Installer format (MSI) in preparation for seamless delivery to the desktop.
These applications are to be delivered separately from the core Windows 7 build. This strategy ensures that the build will deploy quickly and will not require constant revision updates when application updates are released. All MSI applications are installed into device layer 2, the ‘traditional installs’ layer.
Type 1 delivery mechanism will only be used when APP V is not supported.
Type 2 – Application Wrappers.
Like it or not these apps will exist in your enterprise and must be dealt with or supported. A wrapper is a bespoke exe file that when launched will check for configuration changes or will pre-configure the desktop environment by mapping drives doing file copies etc before the real application is called and then launched. Integrating these type of applications into a Windows SOE can be painful to say the least. They are delivered into layer 3 because some form of MSI recreation and SCCM integration is required.
Type 3 – APP V or Cloud (Default Delivery Mechanism).
This would be the default application delivery mechanism. Use cloud where possible (but as discussed we know this would be a small % of applications however, they are likely to have a massive footprint across the business).
Microsoft App V is application virtualisation. Applications that have been virtualised are delivered by the APP V / SCCM estate on a per user basis. Application virtualisation provides an abstract layer where applications can be pre-cached and launched without the need for installation. Removing the requirement for installation increases application agility and portability.
Application virtualisation also significantly reduces the risk associated with application upgrades. Historically application conflicts can occur when 2 versions of the same app run side by side, by using the abstract layer provided by virtualisation, this restriction is eliminated. Application updates can be pushed out independently and removed without impacting the current production version of the application, for roll back purposes, switching between new and backup versions is just as easy.
Other benefits include:
If an application stops working, it can be flushed from the abstract layer and re-cached to a working state.
Rapid Application Provisioning
No installation required, once authorised applications are ready to launch.
Type 4 – Citrix XenApp Online Mode
Citrix XenApp is the delivery mechanism used to provide online access to application hosted on Citrix XenApp servers within the data center. From a users perspective the application looks and feels as if it is running locally however all processes are running centrally on Citrix XenApp servers that are clustered within and across sites. Online applications hosted on Citrix XenApp are delivered on a per user basis and are launched from the users start menu.
Provides remote access to Windows applications from any machine or device including Macs, iPhones and iPad’s.
Provides business continuity in the event of a complete site evacuation.
Type 6 – VDI Desktop
Layer 5 is the VDI layer. The VDI layer is provided using a Citrix XenDesktop. Citrix XenDesktop can provide a virtual XP desktop in many different ways to assist with Windows 7 and Citrix XenApp multi user application compatibility issues which can not be resolved.
Now that we have covered how your device layers and application delivery mechanism may look, lets take a look at what an application portfolio may look like.
Depending on the size of you application portfolio, it maybe a spreadsheet or database. Either way, based on the tools and techniques outlined above it may look a like this:
Click to enlarge. Note the column that defines the delivery type.
As discussed above, an Enterprise Application Portfolio includes:
4. Internet Explorer Plugins and Active X Controls – 5 days lead time
Application Integration and Test Process
As discussed early, an example of a application integration and test process which includes the application steering group.
Click to enlarge.
Typically an Enterprise Application Request, Integration, Test and Release process includes the following: