The purpose of packaging principles is to ensure standards and consistency in how to package software and applications in a way that results in best security, usability, quality and compliance to company code of conduct and other policies. A common scenario is that the software is MSI packaged and deployed via Microsoft SMS/SCCM, but the principles should not be defined for, or dependent on, any specific tool or technology. Consider the principles high-level requirements to packaging technical standards, no matter if the service is in-house or outsourced/offshore (useful if you want to leave the control of detailed packaging standards and tools to the outsourcing/offshoring partner).

The following sample set of principles are based on best practices and experiences from large enterprises, and the principles have – in whole or in part – been adopted by both large and medium sized enterprises as well as a couple of the largest offshore packaging factories. If this is your area of expertise it’s likely you will consider the principles common sense, but even so, it’s useful to have them documented and use as a checklist in the packaging process.

Again, these are just sample principles to get you going. Some of them will not fit your company, some you will customize and you will probably come up with new ones too. Feel free to share your custom principles in the comments field below for others to gain from.

Like the article? Help spreading it by pressing the button below.

 

To design, deploy, manage and govern software in the enterprise is something I have many years of experience in, and from different corporations, so I intend to do a series of articles in this area, starting with this one.

Software is an element that is critical to business and often difficult for IT to get a grip on. To manage software through its lifecycle is a complex process, and the larger the organization and the portfolio of applications get, the greater the challenges.

Challenges include:

• Software is brought into the company without any involvement from IT, who would otherwise ensure it fits the existing IT environment and standards.
• Software is brought into the company without any Enterprise Architecture governance, who would ensure it fits target architecture and business strategy from a non-silo perspective.
• Uncontrolled and unmanaged software becomes business critical long beyond the vendor has withdrawn its support, thus putting business at risk.
• Uncontrolled and unmanaged software is not updated with latest security patches, causing security vulnerabilities for the whole company.
• Different and competing software is used for similar purposes causing diversity in the IS/IT environment and disabling cross-business collaboration.
• Lack of insight and control of what is installed and used causing license incompliance and risking expensive vendor penalties.
• Local purchases at higher cost than necessary due to not utilizing enterprise license agreements, or simply because there are none.
• Client image is deployed containing numerous software products of particular versions, but not maintained up-to-date once deployed – causing massive version diversity.
• Version diversity in client platform causing complexity in global apps deployment and cross-business collaboration.

Some corporations allow their users to download and install software themselves, causing or aggravating the issues above. Other corporations have revoked local administrator rights for users in order to address and control above, but are then facing the challenge that business request more flexibility and faster response-time to change requests – including new software products and versions as these need to be packaged and distributed centrally. This includes any software that is deployed on all clients, updated frequently by vendors and required for business apps to work – and while updating these it’s difficult to assess the impact it will have on other business apps.

These and many other challenges can be addressed though. The following picture illustrates areas I see being involved in getting a grip on software in your enterprise, followed by a summary of suggested approaches for each area to address the issues above. It’s likely this will involve several parts of your organization, which is why it’s key to have a software governance capability that steer all other areas holistically in the same strategic direction. Such governance capability would normally fit in the strategic / planning part of your IS/IT organization (such as an Enterprise Architecture capability) while the other areas may sit in other parts of your IS/IT organization.

The following approaches can start and progress in many of the areas above simultaneously, so does not necessarily have to be in the order listed below. Besides, some areas you could split up or merge, or you can probably find new ones to add. Consider this a skeleton to help you identify, scope and govern relevant areas in your organization.

• Client Image & Layers – rather than deploying a fat desktop client image that is difficult to update with newer software versions once it’s deployed, it can be split up into different layers where you keep the core as thin and static as possible and then keep everything that is updated frequently and required on all clients in a dynamic layer.
• Dynamic and Proactive Updates – this is enabled by the client layers above; the dynamic layer enables you to update components like .NET Framework, Java Runtime, Flash, Shockwave, Adobe Reader, etc individually and dynamically when needed – or preferably even before it’s needed and thus being proactive to business demands.
• Software Standards – a good start is to standardize all the software that is included in the client image, both the core and dynamic layer, and then work your way through the top-used software across your company. Perhaps it’s not feasible to cover 100% of your application portfolio with software standards, so look at where you are and where you want to be; perhaps it’s 20/80 today and you want to achieve 80/20.
• Application Rationalization – it’s by having software standards you enable rationalization of the application portfolio. Rather than using a wide range of software products and applications that do similar things, you standardize on one or a few candidates that meet all or most requirements, and then decommission the other apps. Not only will this cut cost and complexity, it will also improve cross-business collaboration and result in synergies in support and training, amongst many other areas.
• Application Inventory/Repository – you need to know what apps you have in your environment to be able to identify opportunities for rationalization and standardization, and preferably you should also map your applications to business processes and dependences (including required dynamic layer components) to understand their business criticality and impact of change.
• Software Usability Optimization – this is partly about standardizing software based on business usage and capability, rather than focusing on technical features and products, but also about making sure the software is configured for best User Experience.
• Standards Life Cycle Management – once you have standards in place they need to be managed through its life cycles, from evaluation to retirement. Changing the roadmap of a standard needs to take many aspects into account, such as licensing cost, user training, data migration, business impact, strategic fit, target architecture, etc.
• Stakeholder Management – you will never achieve business alignment and gain buy-in to your software standards and roadmaps without proper stakeholder management; make sure decisions are signed off by representatives from each business area who have the proper mandate to do so. Once a standard is signed-off, everything in conflict should be considered an exception, preferably going through proper approval process.
• Standards Review & Refresh Process – business demands change and new software products and versions are released frequently, hence you need to continuously review and update your standards and roadmaps, and also have them deployed accordingly. Again, a success criteria for this is having proper stakeholder management in place. You also need to be able to do some pre-assessment of impacts and benefits of moving from one product or version to another (partly by using Application Inventory data mentioned above).
• Software Catalogue / Provisioning Tool – no point in having standards if users do not know what they are and cannot request what you promote. Make sure your users can easily browse and search amongst your standards to find the piece of software that will meet their particular need at lowest possible cost. Standards should be provisioned in precedence to anything else, but it’s wise to also show pre-packaged not-yet standardized software in the same catalogue so that this will be their second choice and only as a third and last resort they will request something new to be packaged and brought into the environment.
• Software Request Process – once users have found the desired software in the software catalogue or provisioning tool it should be easy for them to simply click request to trigger the purchasing and distribution process. Perhaps you already have existing processes to hook into, and all that is needed is for the request to trigger an email with proper details to the Helpdesk. The request should include user name, computer name, cost center, approving manager, etc – and most of this could be fetched automatically from your existing repositories/directories.
• Software Purchasing Process – if you have provisioned software smartly in the software catalogue, then users will first and foremost choose software of which you have spare licenses in the pool, or that is free of charge or even embedded in the OS / client image already. In the case a new license need to be purchased it should go through proper approval and purchasing process, and according to existing policies and license agreements.
• Enterprise License Agreements – as part of creating software standards and rationalizing the application portfolio you convert licenses that are spread across the local business areas into global license agreements in negotiation with the vendors. Preferably any global software standard should have some sort of enterprise-wide license agreement, no matter if the license is funded locally, centrally or perhaps paid centrally and charged back to the business. You will need to keep track of your license agreements in some sort of repository and make sure they are utilized in the purchasing process and managed as part of software standards life cycle management.
• Software Packaging Process – if the user cannot find adequate software in the catalogue, neither standard nor already packaged non-standard software, the third option is to request a new piece of software to be brought into the environment – and if it’s client-side software then it should normally be packaged and distributed via automated tools. The packaging request form should include all necessary details enabling the request to be properly reviewed and processed, such as business purpose, business owner, technical owner, configuration requirements, and dependencies to other apps (in particular dynamic layer components to enable impact assessment of changing versions in this layer). If the user submits a request that matches existing software then that software can even be suggested automatically to minimize number of faulty/unnecessary packaging requests.
• Software Packaging Gatekeeper – the gatekeeper reviews and approves all software packaging requests to ensure validity of business purpose as well as compliance to business code of conduct, EA/SAM principles, Security policies, IS/IT strategies, etc. The gatekeeper also promotes existing standards that can potentially fulfill and replace the request, and captures opportunities for new standards and roadmap updates. The gatekeeper role can be distributed/delegated to standards owners and/or facilitated by authorized requestors rather than only being operated by full-time employee(s) centrally.
• Software Packaging Principles – these are to set standards and consistency in the way software is packaged for centralized and automated distribution, in order to ensure it results in best security, usability and compliance to company code of conduct and other policies. Packaging principles are high-level requirements to packaging technical standards, no matter if the service is in-house or outsourced/offshore (useful if you want to leave the control of detailed packaging standards and tools to the outsourcing/offshoring partner). The principles would normally supersede any installation/configuration instructions provided by the requestor, unless approved exception.
• Software Asset Management – SAM policies and procedures provides guidance on how to manage software as an asset throughout its lifecycle to maintain software inventory, track asset use/reuse/retirement and ensure license compliance – amongst other things. The ITIL V3 Guide to Software Asset Management contains useful best practices in this area, including content suggestions for creating a SAM business case which in turn could include justifications for other areas above.
• Enterprise Architecture Principles – Enterprise Architecture is the governance body steering IS/IT activities aligned with business strategy and target architecture. You should make sure your EA principles are defined and established in a way that helps you govern all areas above in the same strategic direction. SAM policies, Software Standards, Packaging Principles, etc should all adhere to and further build on the EA principles.

There’s a wide range of tools that can help manage and achieve above, and in some cases it may make sense to develop in-house solutions for some parts. I will not make any recommendations on tools in this article since what tool is right for your organization depends on what your existing environment, requirements and circumstances look like. Also, your strategy and/or progress in outsourcing or moving into the cloud (if any) will also have an impact on what is the proper tool for your organization as well as how and in what direction to govern and manage above.

I will drill down into a few of the areas above in coming articles, and when available, the headings above will be linked to each of its relevant article. All of the approaches above have been successfully implemented in one or more enterprises, so it’s based on real-world experience rather than theory only.  If you aim to step-up in software governance in your organization and would like help doing so, feel free to contact us. 

There are a lot of articles and marketing material out there reflecting these benefits of BPOS and what cost benefits it will bring, and there’s also a lot of information on back-end migration processes, but the actual end user experience I’ve found very little on.

Having worked in a Microsoft Office environment in the large-scale corporate world for many years I found it interesting to evaluate BPOS from a User Experience point of view; what will be different for users if the IT department decides to move from on-premise SharePoint, Exchange, Live Meeting and Office Communications Server to BPOS? So, here goes…

Top-5 issues that are likely to annoy your users:

1.   Client auto-configuration failures

Perhaps you will do thorough analysis, testing, configuring, packaging and deploying of the client components as part of the overall migration processes to BPOS, and if so, this problem will not apply as much to you and your users.

However, presumably many corporations will align the strategy to move into the cloud with a strategy to move to BYOC (Bring Your Own Computer). You would therefore expect client-side components required for the cloud services, such as the Microsoft Online Services Sign In client, to be easy to install and configure so that users potentially can do it themselves.

Not likely.

The client software itself is a simple download followed by a next-next-next-wizard, but when it starts to auto-configure your locally installed software (such as Internet Explorer, Outlook, Office Communicator and Live Meeting) that’s when problems start to arise.

The problems may not be noticed at once, but once they do occur you may have difficulties tracking the source of them – at least we did. Here’s one problem we got in our pilot whenever we tried to open a document from within SharePoint Online:

We also got the following error whenever we tried to save a document from within Word (or PowerPoint or Excel for that matter) onto SharePoint Online:

The Microsoft Office Upload Center did not help much with its taciturn error messages, but after time-consuming trouble-shooting and searching the net this issue seems to be pretty common amongst BPOS users, and one workaround (which at least worked in our scenario) was to disable “Automatically detect settings” in Internet Explorer:

No idea why the Sign In client enabled this setting (no, it wasn’t enabled before) and disabling it will not work for all businesses since this setting may need to be enabled depending on your infrastructure setup. The point is; there’s a risk the Sign In client will make changes causing problems for your users. Do not leave it to them to install it themselves.

Another issue that may cause problems is that the Sign In client will create a new Outlook profile for BPOS/Exchange Online, meaning if users already were using Outlook with a default profile they will have to logoff and logon Outlook whenever they want to switch between mailbox accounts. That’s just not acceptable in the BYOC world. Do not expect novice users to be able to add BPOS as an additional mailbox to their current profile themselves (unless given very clear and specific instructions), the Outlook profile settings for BPOS are quite advanced.

If users do end up with multiple Outlook profiles because of client auto-configuration, then the side effect may be that synchronization with mobile phones and other hand-held devices will not work as supposed to. In our tests, we had all sorts of problems with getting iTunes and iPhones to sync the correct mailbox and data once BPOS had done its auto-configuration.

2.   Not possible to add users outside own organization

In a world where businesses outsource, offshore, acquisition, merge, partner and externalize as everyday business it’s really critical to be able to communicate and collaborate with users outside your own company and organization. Sadly, this is not possible with BPOS/Office Communications Online. Here’s Microsoft’s response when I asked them about this issue:

“Unfortunately at this time Office Communications Online (OCO) only works within your company and will not accept users that are not account license holders. A future release of OCO is planned to include what is referred to as “Federation” meaning it will be open to outside users and even other Instant Messaging applications but I do not have a date when that will be available”. Hopefully they will add this when BPOS is upgraded to version 2010…

Also note that person-to-person audio and video communication can occur only between two PCs on the same corporate network where no firewall exist between the computers.

3.   No easy way to initiate ad-hoc meetings

Normally if the LiveMeeting client is installed, the option “Share Information Using Live Meeting” is enabled in Office Communicator allowing you to select one or several users you want to collaborate / web conference with. You simply right-click and choose ‘Share Information Using live Meeting’, that’s all you need to kick off an ad-hoc LiveMeeting.

However, when it comes to BPOS, even when the LiveMeeting client installed on both the calling and receiving client this option is greyed out:

Without this option in Office Communicator users will have to initiate a LiveMeeting via the LiveMeeting web interface, which is anything from intuitive and easy to use. I’ve done usability tests previously in large organizations that prove this – very clearly. It’s easy enough to join an already set up LiveMeeting if you’re provided with a direct link, but to set up a meeting takes too long to even call it ad-hoc.

4.   Office Communicator presence does not sync with Outlook

The note field in Office Communicator is supposed to sync automatically with Outlook when a meeting appears in the calendar at the time, or when Out of Office reply is active. This does not seem to work in BPOS and instead an Exchange Connection Error is shown:

There might be workarounds to this, but we have not been able to get any solution or workaround to this from Microsoft, nor find one ourselves.

5.   Limitations in web-based capabilities

Imagine your business moves into the cloud and heads for BYOC and so on; your users are supposed to be able work from anywhere, any time and any device. It’s an old worn out slogan, but nevertheless it’s the vision for many businesses. Does BPOS support this vision? Not fully.

For one thing, one of our pilot users was not even able to logon to BPOS using the Safari browser on Mac. The browser simply reloaded the page when trying to logon without even giving any errors. Unfortunately this was discovered at the end of our BPOS trial period so we never had the time and opportunity to dig any deeper into the issue.

But even if you’re on a Windows client that is not part of your corporate network, for example if you use a temporary PC in an airport lounge or a coffee shop, then you will notice that BPOS is really designed to be used together with locally installed client components and software products (aka software-plus-services, which is Microsoft’s strategy) rather than through a thin client web-only interface (aka Software as a Service; SaaS).

The picture below gives an overview of what features you will lose if you use BPOS through a web-only interface compared to if you use it together with locally installed client components and software products from Microsoft.

Of course all client-side components that need to be installed to avoid the limitations with the web-only interface will result in resident processes occupying resources on your PC.

This document further describes some of the current features and limitations with BPOS:
http://download.microsoft.com/download/C/9/1/C9168B0C-5FC8-49C6-A1A4-1632C76C193D/OCO_Standard_Service_Description.doc

Additionally…

When comparing Microsoft BPOS to Google Apps there’s a few other disadvantages with BPOS such as you need pay for and have Microsoft Office installed locally, and you cannot real-time co-author any documents. You will have to check-out and check-in documents when editing them and only way to collaborate real-time in authoring/editing documents is using LiveMeeting.

However, these shortages, including some of the issues and limitations listed above, will be addressed once BPOS will be based on SharePoint 2010 instead which will be released 12-May-2010. BPOS is expected to be upgraded to 2010 within 3-6 months after its release. You may want to consider not moving to BPOS until then, if your plan is to move.

We’re currently also evaluating Google Apps in comparison to BPOS so next article will be about the User Experience of Google Apps. As a heads-up, if your users are custom to an on-premise Microsoft environment, then it’s very likely they are better off moving to BPOS than to Google Apps.

Interested in evaluating BPOS on your own? Click here to attain a free 30-day trial version of BPOS from Microsoft through NeoSpot.

But that’s another story and potentially another article. This article is about Adobe AIR and RIA (Rich Internet Applications). According to Adobe’s home page “The Adobe® AIR™ runtime lets developers use proven web technologies to build rich Internet applications that run outside the browser on multiple operating systems”. Fair enough.

However, the problem with Adobe AIR is that not only does the AIR runtime require admin access to install on Windows Vista/7, but all the AIR applications do too. In a locked down client environment this means AIR apps will need to be packaged and deployed like any other fat client-side application. One of the RIA principles and main reasons for enterprises moving to web based apps in the first place is to avoid this costly, complex and old-fashion deployment method.

Not that Voddler is something enterprises will deploy, but presumably Adobe Flex is something they will use to develop RIA – especially to achieve browser- and operating systems independency in a world where you outsource, offshore, acquisition, merge, partner and externalize a lot and have no or little control of the target environments in which your apps will run. I have a feeling many foresee the fact that if Flex apps are developed with dependencies to AIR (rather than just Flash) then you may still end up in a scenario where your RIA apps can’t be used due to locked down client environment.

I raised this with Adobe some time ago, and they did admit AIR does not fit the locked-down corporate environments yet, but that they are working on it. So will be interesting to see what they will do in future releases to address this. And yes, title above is exaggerated.

However, the closer you get to the actual users, for example to local IT coordinators, support personnel or the like, the more they want to configure the client for improved usability. I know an horrific example where the Corporate IT department said “usability is out of scope”, “keep it strictly out of the box”, and then the local IT departments went and tweaked the heck out of the client to make the transition to the new client easier for their users. A failure in governance of course. The company ended up with more than 40 different client “designs” globally and needless to say it was a nightmare to manage and maintain up-to-date.

So why and what is it they so desperately want to change from default, you may ask? Well, those who understand the users also understand why you shouldn’t deploy a client that looks like this:

Some time ago I did a usability review of the first beta build of a corporate client based on Vista and Office 2007 which was going to be deployed to 70,000 users, and this was all default and strictly out of the box (apart from the security configurations of course). The first 15 minutes of use I had been prompted about 30 times with questions that normal users don’t understand or simply ignore and just click whatever is default.

Take the lower left prompt in the picture as an example. It asks if the user wants to synchronize RSS Feeds between Outlook, Internet Explorer and whatever else uses something called the Common Feed List. This is Hebrew to most users in large organizations. Most of them don’t even know what an RSS feed is. Hence they will click a random button and not knowing what it means. Some users will have feeds synchronized between Outlook and IE, some won’t. Some will call Helpdesk and ask why behavior is different between their PC and their colleague’s PC next door. And if your Helpdesk is outsourced, it’s likely they will not know the answer because it’s not documented.

Next example – take a look at the lower right prompt in the picture. This is one of the default prompts first time you start a Microsoft Office program. Most users will NOT fill in their name and initials; they will simply hit Enter or click OK. This means all their Microsoft Office documents will be tagged with whatever is default in this field rather than their actual name, which in turn will cause the author META data to be incorrect and result in negative Enterprise Search experience. You have the power, in client design, to ensure all Microsoft Office documents across the enterprise will be tagged with proper user details (and you can even enforce your own model of META data in Microsoft Office “Save dialogue” with SharePoint in the background, see here).

By preconfiguring settings like these (there’s many!) once and for all in the build you’ll avoid confusion and frustration being first impression users get from the new client and you’ll also ensure that the client is configured and behave consistently across the enterprise. In my next article I will describe the approach I normally apply to find out what to configure how for best corporate desktop usability.

.

I sometimes get the question what the difference is between Usability and User Experience (UX). One may think that User Experience doesn’t necessarily imply that something is usable (whether it’s good or bad, it’s still an experience), and hence Usability is superior to User Experience. However, the emerging trend is to refer to User Experience as the wider perspective and Usability as being part of User Experience, as illustrated below.

By this definition Usability is a subset of the overall User Experience. Usability answers the question, “Can the user accomplish their goal?” with effectiveness, efficiency, and satisfaction about the results (as per the ISO 9241-11 definition of usability). User Experience also answers the question, “Did the user have as delightful an experience as possible doing so?”. User Experience takes far more effort to do well, but the results have far better impact.

A commonly used example of great User Experience is the Apple iPhone where Apple has spent efforts in all of the areas above and succeeded in doing so. The early iPhones did not include latest technologies (far from it) but was a success nevertheless due to being a great User Experience as per definition above. As the NeoSpot slogan states; IT’s all about the User Experience, not about the technology itself.

The new version of ISO 13407, the International Standard for Human Centred Design (which will be called ISO 9241-210 to bring it into line with other usability standards), will also use the term “user experience” according to this link.

There’s a lot of debate on this topic out there. Here’s a few links for those interested:

• The Battle Between Usability and User-Experience
• The Difference Between Usability and User Experience
• Usability vs. user experience

NeoSpot AB is now born and registered! Read about us here.

.