Home Applications Today’s Enterprise Application Delivery Framework

Today’s Enterprise Application Delivery Framework

0
8
0

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:

  • Multiple Application Delivery Platforms to support the delivery of an application portfolio of 1000 apps + which includes
    • Microsoft SCCM
    • APP V
    • Citrix XenApp
    • Citrix XenDesktop
  • An Enterprise Application Portfolio.
    • Includes the whole enterprise application suite
    • Compatibility with Windows 7 or not
    • Describes the delivery mechanism for each individual application and why.
    • Provides visual status of all applications
      • In progress
      • Completed
      • Decommissioned
      • Replaced with ‘app x’
      • Not required ‘app x’ does the same job
    • Provides service manager details
    • Active Directory Groups required for deployment (great for the helpdesk and desktop support)
    • Sociability of the application with other apps
    • Sociability of the application with other data such as drive mappings, network shares and public folders.
    • Details of other integrated work-flows.
  • A core SLA agreement with the business.  Usually in 3 categories
    • Enterprise apps, potentially 1 month lead time from initial request
    • Advanced apps, potentially 3 weeks lead time from initial request
    • Basic apps, potentially 2 weeks lead time from initial request
  • An ‘Application Steering Group’
    • A technical authority which analyses each request and decides the appropriate delivery mechanism for the app.
    • A queue which is maintained via service desk which can measure the turn around time for app request (from initial request to delivery) including notes on analysis and decision making.
  • An Enterprise Application Packaging Process
    • Core packaging discipline
    • Quality assurance for apps which are:
      • Sequencing using APP V for multiple targets
      • Traditionally packaged when absolutely necessary
    • Packaging process
    • Packaging best practices
    • Documentation procedure
    • SLA’s
    • Roles and responsibilities
    • Escalation
    • Defect Management
  • An Enterprise Application Request, Integration, Test and Release process
    • How asset management track the procurement
    • How the Application Steering Group should handle the request
    • How the customer is notified during the whole process
    • How the application is moved into the packaging team
    • How the application is moved from packaging into UAT
    • How application moves through defect management into change management
    • How application is promoted into production

So, before we go any further with application delivery framework’s, lets discuss ‘cloud’ and where it fits within the enterprise application delivery landscape.  

Cloud Computing.  Where does it fit?

When I think cloud, I think collaboration, off-premise, simplicity, improved productivity and consistent mobility of use regardless of location or device, which are always high on the agenda of any CIO.  I also, like many others think… is it secure?

I am also thinking about delivery, version-less, client-less, HTML5 or similar, browser based feature rich apps which would mean instant availability on all devices. The way I think today is the more apps in the application delivery framework that fit this delivery mechanism the better it is for enterprise technology as well as the workforce.

Enabling cloud within your Enterprise is emotive to say the least, there will always be Evangelists as well as detractors however, it is what happens to your work force once they begin to embrace it which is interesting. Workforces begin to find it much easier to collaborate on documents independent of device and location, see who is online for chat within the same browser interface as your mail, access documents, calendar, corporate directories etc all the core functions your workforce need within the same browser interface.  Documents and data is also saved every few seconds within your browser and there is only ever one version.  Another big step forward for mobility is that Google have announced that Google Apps will shortly be available offline too.  Regardless of your position within business, you cannot argue that the benefits of cloud based computing will help accelerate communication, collaboration and innovation, things which are at the heart of any business.

Social Messaging and Group Collaboration.

Socialwok is easy to integrate into any workforce which adds the missing social layer to Google Apps.  A social layer turns documents, presentations, questions and ideas into social objects within workforce communities again increasing communication within your business in the same way facebook.com does for personal use.

My personal experience of Cloud so far

Application delivery transformation (primarily with Citrix technologies) has been a key part of my professional life now for nearly 12 years.  Historically I have always delivered Microsoft Office through either XenApp or XenDesktop, personally I haven’t used any of these technologies to access documents or corporate data now for over 6 months. Instead Google Chrome has become my core interface to everything I have explained above.  I have become more social in my enterprise, more productive and has improved my collaboration, all because it is so easy to do.

But…. and this is a big but, cloud based services at present account for only 5% of an enterprise application portfolio (although they have a massive footprint).  So how do you deliver the rest?  The answer is traditional tools such as SCCM, APP V, WTS, Citrix XenApp and Citrix XenDesktop and other VDI technologies..  This is likely to be the same with most large corporations but I strongly suggest that for the core set of apps that underpin communication, collaboration and innovation within your business, regardless of the size of your enterprise you embrace and go cloud all the way.  However, do not ignore the ‘traditional’ delivery mechanisms that support application agility in your businesses today.

So that is cloud out of the way, lets get back to our Enterprise Application Delivery Framework.

Providing an Application Delivery Framework for Windows 7 Transformation Projects and BAU.

When embarking on a Windows 7 transformation project one of the key principle tasks is to put together an accurate application portfolio using a process which harvests applications that are used rather than installed.  If you focus on the former then it is likely that the application portfolio will shrink significantly reducing both costs of application integration and time to deliver.

Let us say that after a quality analysis of applications in use, the portfolio contains 2000 applications and the decision has been made to integrate APP V into the desktop as the primary packaging discipline and delivery mechanism.  How are applications delivered that are not Windows 7 compatible or that will work but the vendor will not support them?  This is where an intelligent application delivery framework will drive the build of a number of platforms (such as XenApp and XenDesktop) to enable the delivery of all applications to the transformed Windows 7 desktop, leaving no prisons.

In the example above we are using SCCM + APP V integrated into Windows 7 as the principle application delivery mechanism, this means that the framework already supports traditional MSI deployments as well as APP V from the outset.  Applications recorded in the portfolio will be assessed for APP V first.  Important points to consider here:

  • Applications that are sequenced for APP V would be done with multiple targets in mind such as:
    • XenDesktop (maybe even XP)
    • XenApp (Windows Server 2003 or server 2008 or both)
  • Applications which cannot be sequenced via APP V may need to go out via MSI, important to note that the SCCM infrastructure would faciliate this.  
  • Applications that are not compatible with Windows 7 at all would be sequenced using APP V (server 2003 target) and delivered via Citrix XenApp hosted and integrated into the desktop as seamless start menu shortcuts
  • Applications that are not compatible with Windows 7 and are not Citrix XenApp multi user compatible would be sequenced via APP V (windows XP target) and hosted on VDI, XenDesktop or something similar.
  • Applications that are required for remote access or business continuity will be available on Citrix XenApp and XenDesktop or similar technologies.

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:

Streamlined support
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.

Application Portfolio

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:

    • The whole enterprise application suite
    • Compatibility with Windows 7 or not
    • Describes the delivery mechanism for each individual application and why.
    • Provides visual status of all applications
      • In progress
      • Completed
      • Decommissioned
      • Replaced with ‘app x’
      • Not required ‘app x’ does the same job
    • Provides service manager details
    • Active Directory Groups required for deployment (great for the helpdesk and desktop support)
    • Sociability of the application with other apps
    • Sociability of the application with other data such as drive mappings, network shares and public folders.
    • Details of other integrated work flows.

Core SLA Agreements

SLA agreements are drafted at initial project stage but typically take effect once the project is ended as part of BAU.  New application requests from the business are tagged with an SLA depending on the complexity, here is an example that I have used in the past.

1. Enterprise Application Request – 1 Month Lead Time

  • Installation across all devices (a core application)
  • Upgrading or removal of an existing version
  • Advanced operating system integration
  • Advanced Internet explorer integration
  • Multiple application dependancies
  • E-mail integration
  • Multiple work flows
  • Special folder permissions
  • Advanced pre-execution scripts
  • Peripherals to be attached and tested

2. Advanced Application Requests – 3 weeks lead time

Application requires:

  • Installation to a single business unit
  • No upgrade or removal of existing versions
  • No local operating system integration
  • Basic application dependancies
  • No e-mail integration
  • No work flows
  • Basic pre-execution scripts
  • No peripherals required
  • No special folder permissions

3. Basic Application Requests – 2 weeks lead time,

Application requires:

  • Installation to a single user
  • Basic single file installation
  • No local operating system integration
  • No application dependancies
  • No e-mail integration
  • No work flows
  • No pre-execution scripts
  • No peripherals required
  • No special folder permissions

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:

    • How asset management track the procurement
    • How the Application Steering Group should handle the request
    • How the customer is notified during the whole process
    • How the application is moved into the packaging team
    • How the application is moved from packaging into UAT
    • How application moves through defect management into change management
    • How application is promoted into production

So that’s it, I hope that you find this information useful.  Although I have focused on how an enterprise application delivery framework can be critical in supporting a large Windows 7 roll out it also provides an excellent BAU tool when managing your application delivery environment going forward.

Hopefully if I get the time over the next 3 months I will put together the project teams, track leads and work streams required to build the whole thing from scratch and share that out too.

I also intend to publish a very similar article based on a ‘Desktop Delivery Framework’ rather soon.

Thanks for reading
Lee Wynne.

 

Join the 'Delivering the Digital Workspace with VMware' Virtual Conference NOW!

More Resources:

Categories:
DABCC DABCC.com, the world leader in sharing the finest Virtualization & Cloud news and support resources. #Citrix, #VMware, #Microsoft, #Mobility and much more! Brought to you by @douglasabrown & team!
| LATEST RESOURCES

White Papers

    The Top 5 Benefits of HIPAA Compliant Messaging that Improve Your Organization

    Healthcare organizations process enormous amounts of sensitive data, including protected health information (PHI), every day. They are required by law through HIPAA (Health Insurance Portability and Accountability Act) to take every precaution to protect this data. As more of this communication goes mobile, it is critical that healthcare providers maintain the levels of privacy that […]

    Downloads

      Load & Performance Testing for Citrix – Download AppLoader!

      Load testing for Citrix XenApp, XenDesktop, PeopleSoft, Java, .NET, Adobe, client-server, Oracle, Siebel, SAP, web, custom apps and more Download NRG Global’s load and performance testing solution for all applications from the end user’s perspective. This easy-to-use, script-free load and performance testing solution stresses your application with real-life traffic to accurately assess end to end […]

      On-Demand Webinars

        Managing the End User Experience with GPU Powered Insights On-Demand Webinar

        Citrix Ready Technical Webinar with eG Innovations GPU technology improves the user experience in Citrix virtual desktops and applications, but to truly deliver an immersive user experience that scales, organisations need to manage the complete GPU deployment lifecycle – from designing the infrastructure, to managing and optimising a production environment, to responding to user issues […]

        Latest Videos

          Microsoft Video: Updates to the SharePoint app, team sites and publishing experience

          Adam Harmetz, (Group Manager, SharePoint Experiences) gives a rundown of SharePoint’s updated team collaboration experience across SharePoint and OneDrive and what’s coming in the future. He will show you what the mobile and web experience is like working with and sharing team files. You will see the recently launched improvements to the SharePoint team site […]


          Close