Application Discovery is a vital part of the application packaging process and with the increasing frequency of application updates, the process has to be streamlined to be able to keep up the pace. Just think about it: You probably have Windows 10 (2 major updates a year), Office 365 (2 major updates a year), SCCM (3 major updates a year), and Bloomberg (monthly updates) — just to name a few!
All these new versions could adversely react with your existing applications. Therefore, you will have to first certify and test all (at a minimum high-risk) apps, and potentially re-package them. In addition, you have to package new applications and add them to the roster. Traditionally, this has been done manually by emailing co-workersas well as compiling word documents and file packages.
Today, I want to have a look at what information must be collected to raise a packaging request, how it has been done manually until now, and how you could use a centrally-managed IT automation tool to cut down the discovery time significantly!
What Information Is Needed To Raise An App Packaging Request?
Usually, the requester or product owner is required to provide product specific information:
- Requestor name (including email address and business unit or division)
- Product owner name (including email address and business unit or division)
- Technical contact name (including email address and business unit or division)
- UAT contact name (including email address and business unit or division)
- Is this a new request, an existing request that needs to be modified, or a new version of existing product?
- Is this a virtual app request (Appv) or physical (MSI) or a request to package both?
- Application source media (source files in either Digital Media or sent through via CD)
- Application install document (usually from the vendor or developer in text and picture format, mainly in MS Word format)
- Special packaging instructions for during and post-install (usually from the vendor or developer in text and picture format, mainly in MS Word format)
- Any further customization that the application packager needs to be aware of — such as:
- Port settings if any
- Firewall rules if any
- Dependencies or prerequisite applications
- Licensing information (product)
- Application entitlements
- Application personalization settings
- Pilot user list
- Regional or business unit configurations
- What locations to deploy the application to — specific regions
- Full user list to add to deployment groups / or move users from old version to new
As you can imagine (or know from experience), collecting and collating this information manually can take days, if not weeks, and can be very frustrating as you have to wait on other team members.
The information that is required is generally the same, whether you are raising a request for Business-as-Usual or for an application migration project. But there are significant differences in how one might approach the discovery phase — mainly from the traditional angle using lots of little manually-managed steps or through a centralized, automated self-service process.
Today, I want to walk you through each approach:
Traditional Application Discovery Approach
Traditionally, when a member of the packaging team receives a request for packaging an application, they will review it with the help of a checklist to confirm that the minimum information has been supplied to support the technical packaging of the product. This often happens by manually entering information in an internally built product for application workflow tracking.
If the request is to package a third-party application, the responsible product owner would either provide the source files and instruction material supplied by the vendor or customize them first to meet any internal configurations. If this is the case, these details will need to be supplied with an installation document and covering email.
If the product has been internally developed, the in-house development team would provide the source files and installation document to the product owner to supply as part of the request.
This approach leads to many potential issues and delays in the request submission process, such as:
- Product owner submits the vendor’s or developer’s documentation without reading it or understanding if the content is satisfactory for consumption.
- Documents may not be well written or easy-to-understand, or they may contain ambiguous information or miss something.
- The installation document may not include configuration details and therefore lead to more communication back and forth to gather more details.
- The source media uploaded may not be the actual source media version used when tested by the requester in their development environment which leads to source control issues.
- Product owner/developer may not have the required infrastructure to install the product and test it in development prior to submission.
- Generally, the packaging team and product owner/requester have disconnected dialogue in respect to install/config docs and source media.
As you can see, there are a myriad of potential pitfalls and bottlenecks that will complicate or significantly stall your discovery process.
Automated Discovery Using Self Service
Thankfully, there is another approach. While the traditional approach relies on the goodwill and effort of the many different teams involved, the automated self-service method allows you to centralize and therefore streamline this process significantly.
Let me walk you through this process using the example of Access Capture.
As the product owner or developer who wants to raise a request for a new product to be packaged or sequenced, you log into Access Capture. There you will be guided through a wizard-driven screen that invites you to initiate a virtual machine on which you install the product and its associated settings. While you do so, Capture runs in “Discovery Mode” in the background and collects all the information needed. That’s it!
Our self-service approach offers the following benefits:
- Faster Discovery Using Virtual Machines. Using Capture’s Automated Documentation Creation feature, he or she can login to the newly created machine as an administrator and with an operating system build of their choice to quickly install all required source media for their product.
- Automatic Documentation Creation. While this happens, Capture captures the installation process as well as all relevant documents, settings, and more.
- Edit & Finalize Documentation. Now, the product owner or developer can comment, annotate or remove unnecessary screen shots to finalize the documentation. The outcome is complete and robust documentation in the form of a Microsoft Word document.
- Central Management. Once the install of the product is completed and all configurations have been entered, the document is saved back to the request in a centralized web portal. The document stays with the request raised so that if the packaging/sequencing cannot be automated, the application packager has all the required information about the product install to create the corporate application package of the product without going back to the product owner for clarifications.
In essence, using Access CAPTURE for your application discovery dramatically reduces the time taken at this stage of the application management process. In addition, this approach minimizes the issues encountered in the ambiguity of communication via e-mail and telephone.
To learn more about Access Capture, head over to our product tour or schedule a demo today!
