Software Deployment

I suppose it depends on the environment your going to deliver the package to.

I would say that 40 hours would be minimum where I work because of the processes in place to deliver quality.

Here is an example of where I am currently contracting:

We have an eight hour window to create the package, another eight hours to perform QA and Support Testing, and then eight hours for the User Testing. Therefore on average about 3 days from receiving the request to being able to release package into the Live environment (if everything goes well that is!).

16 hrs sounds about right. That is fast tracking to.

There is no true answer. In fact several factor will make the packaging process faster or slower.

For us an easy package with no difficulty would take 16 hours. A hard package may take weeks.

40 hrs may be chosen if you are an outsourcing company as the time to deliver of repackaged apps. However some easy packages out there will take less than 10 hours taken into cognizance QA, functionality testing/UAT, conflict checking and deployment.

The very difficult packages may even take close to 100 hours. With this in mind, there is can't be any real time estimate but 40 hours will be the average in order to be able to prepare budgets for packaging projects.

Thank you for your feedback. I have been using the 40 hours average number for budgeting purposes, although with 1000+ applications, 20 - 30 pecent being complex legacy applications, the number of hours per application can grow significantly.

A company called Softricity, which virtualizes applications on the desktop through streaming technology state that they can "sequence" applications on average within 4 hours. Because applications are run within a bubble, no OS system or registry files are changed, they state that regression testing is not required. They also state that on average, regression testing could take 33 of the traditional 40 hours to package an application, which is not required when using their product.

Has any of the members had experience working with the Softricity SoftGrid product, and if so, what has been your experience versus traditional packaging methods?

Regards,
CanNear

I have had packages take me 40 hours, or upwards of, when I was packaging for Shell oil, but in honesty, most of this was to meet Windows Logo compliance requirements for our applications, and component isolation. Depending on the nature of the app, and what your guidelines are for compliance and documentation/technical writing, it can be 40 hours, and it can also be 4, it really depends on so many factors that you can't foresee until you're in the middle of your package/repackage. The true answer is that is is really on a case by case basis. To keep with in the red tape and still stay practical to resource demands and detail, 40 hours sounds well rounded.

For this software company that claims to be able to do this, I have three words for them: Proof of Concept.

Make them setup a lab, with real world apps, not winzip and winamp, and make it work. Personally, if someone can tell me they can make programs like office 2k3. AutoCAD, Visio, and Lotus Notes/Domino, SAP, and Peoplesoft run "in a bubble" and do no registry changes, I'd have trouble taking them seriously until they can prove it. And not by press releases, by seeing it.. For them to say regression testing isn't required is a falsehood because if you want Microsoft to sign off on your package, you ABSOLUTELY have to run through logo compliance, regardless. Unless they've arranged something with Microsoft..

Some very good advise (Proof-of-Concept), thank you!

You have brought up a good point regarding logo compliance. How many companies are actually designing their OS and application strategy around Microsoft's Logo Compliance Program? I have seen comapnies start in this direction, but usually end up making adjustments to the defined criteria because of key business or technical requirements driving the change. A change management nightmare to say the least.

Regards,
CanNear

Hi Cannear,

We quote on average 2 days effort to get a package to testing. So this doesn't include testing (other than our own minimal make sure it looks like its working kind of thing), which is usually performed by the client, but it does cater for rework after UAT etc.

But it depends on the client requirements, if they require full isolation (none have yet so far), or logo compliance (none have so far either), or some other time consuming process, then we would add more.

Rgds

Paul

In an SMS environment, I've had packages take anywhere from 12 hours for an easy package, to 3 weeks on very difficult packages.

In my new evironment we use AD/GPO deployment, so packaging can take longer given the fact that I'm limited to MSI only.

Softgrid can cut down on time to deploy but you also have to factor in that some software will not work with Softgrid. Also Softgrid will cause you to run into building and supporting extra packages when applications have to be suited together. I still have to touch base with some consultants on a rather large implementation of Softgrid to see if they feel that is was truly beneficial or not to use that technology.

It sounds as though this company is only providing a packaged solution for the application and no time for end-user testing, communication, deployment or remediation. If the only requirement is to provide a package that brings up the splash screen for the application then, yeah -- you can crank those out pretty fast -- a couple of hours for simple apps. If you want more testing then you have to add more time. And of course you have to add time for all the apps that aren't straight forward.

A friends company is using Softgrid and they say it has cut down helpdesk calls and package releases. He also said they really do not have many complex packages, which would add on considerable time in his opinion.

I think also that you can whip together just about any package pretty quickly when you are deploying to a small enterprise of say 1000-2000 seats.

But when you get into deploying to 30,000 seats across a country the size of Australia then its a different matter. One mistake and you have major issues to solve and some of them can't happen quickly because of both time and distance.

So the packaging becomes the smallest part and the QA and UAT part become the focus.

From my expereince Average time for packaging an application depends on complexity. As applications falls under complex,medium and simple depending on customization and access to different files and shares.I have packaged JRE,RapidPlayer in 48 hrs while tritech which needs ODBC configuration and access to Sql server I took more than 2 weeks till it passed the preliminary testing before me sending the package for User Acceptance Test.I say depends on case to case basis as said by Toupeiro.Correct me if I'm wrong.

Many Thanks--Satya.

I'd like to revive this if you don't mind.

I'm being questioned at work regarding the time it takes to package an application. This 40 hours that people keep referring to in this post, is that the time it takes just to package, or does that include initial application testing and then testing once the package is complete?

Also, is the packaging process made a priority for your users? What I mean is that in my case, testing can take weeks due to user availability and lack of piority.

I took us 4 weeks to define processes for our new client .Which included :
Setting up Installshield Admin studio
Setting up conflict solver database
Creating workflow guideline templates
Creating packaging Process documents
Creating Test Plan templates
Creating Packaging Change request process documents
Then 4 more weeks to prioritize all the applications to be packaged and schedule their package release and UAT date(UAT scheduling was a difficult bit though and continued throughout packaging process) .

Having set up all this we estimate 30 hrs per package but having said that we have also observed that complex packages may take somewhere around 50 hrs to complete .Hence we never deliver packages on an hourly basis but on a weekly / fortnightly basis .

I think prioritization of applications is a must . wherein you can define various parameters to calculate priority numbers for each application .One of them can be complexity of applications to package (here based on experience you can assign timelines and can set the expectations )

Cheers,
V

Regarding this Softricity solution, I'd be surprised if many companies would be happy for all their applications to be reliant on a single proprietary driver in order to run?!

My guidelines generally look like this: Very Simple App = 16 hours ; Average App = 32-40 hours ; Very Complex App = 60-80+ hours. This is actual time spent (not elapsed time) gathering customer requirements, building the installation package, internal QA, user acceptance testing, documentation and administrative paperwork. Elapsed time can take weeks or months for even the simplest applcation depending on the availability of everyone involved. And no, rarely do users make testing a priority unless they personally are in a rush to see the application finished.

This does NOT include Project Management time (which our PM's tack on top of our estimates, and typically adds at least 10-20% more hours), and it does NOT include the time to deploy an application. If we're deploying globally to 70,000 seats, that requires far more time than a single ~3,000 user site or a small department of users.

I actually worked on my office's attempt at Softricity. We were looking at a Citrix based 'solution' for DR, and possibly as a desktop replacement for those people only using the 'base' applications like word, email, etc. Citrix, if you don't know, is essentially 'Let's put all our software out on servers and have people connect to them using thin client.' Which made me snigger when they explained it, and I made bad cracks about DEC terminals. Anyhoo, one of the nasty issues with Citrix is even though you could have 10 to 30 apps on a server, you had conflicts. Softricity, in that scenario, was supposed to help us out by having each app run independant of each other, and yet still have the ability to chat with each other.

It's a really great concept, both Citrix and Softricity, but neither technology is mature enough, IMO, to be of use for a 24/7 day to day enterprise. It's an okay DR solution, but with memory and hard drives being so cheap, and Ghost being so easy to deploy a standard desktop, the cost effectiveness for a company with 9000+ people starts to get weird. If you were in a smaller company where everyone uses the same apps, maybe. We've got 1500+ different types of software to package and support. The massive amount of Citrix Servers we'd need was going to be cost prohibitive for a total replacement.

My experience actually using Softricity left me with an 'eh' feeling. Citrix is getting better all the time, and we're using it as our desktop replacement strategy for offices we can't get on XP for whatever reason. Softricity we're not using right now.

Interesting observations you have expressed regarding Citrix and Softricity. Yes, I would agree that the Softricity is young, and needs to mature. Think only a few years back, like 1999, when Windows 2000 and the Windows Installer Service was first introduced. Softricity was founded in 1999, with version 3.2 being released in the next few weeks. Enough selling, this is not the forum for this.

Let's say that there is a product that will take an existing SBC infrastructure (assuming you have one to begin with), complete with silo'd servers because the application not will play right with the others, and allow that same problematic application to run with 25 to 30 apps. That has freed up one server. Do the same for all the other silo'd apps, and you have a measureable return on investment. This is called Server Consolidation. The SBC apps do not require packaging, and the requirement for detailed regression testing is significantly reduced.

Now if you don't have that "big" SBC environment, which sounds like you may not have, then that same product can be very successfully used for distributed desktops, which is a possible solution that you may wish to revisit. Again, comprehensive packaging is not required for most applications, and regression testing is minimal with this product. The time savings are significant. Yes, there are still the ancilliary processes that complete the Application Lifecycle, which also add to the time and cost to package an application. Recent emails from other contributing members in this forum have also communicated the importance of processes, and the time required to excute these. Running Ghost sounds simple, although the issues outlined above still exist.

Regards,
CanNear

SoftGrid seems best fit for Citrix environments where the cost of application conflicts is much higher than on a desktop. However, if one can better manage/prevent the conflicts, the value of this product doesn't seem as high. IMO, this is why Softricity appears to be marketing towards the Citrix crowd, rather than marketing towards the packaging crowd.

I'd agree with a previous poster in that migrating from MSI to a SoftGrid solution adds the additional risk of using a prioprietary solution, as this strictly reduces one's future flexibility. One can argue that MSI is Microsoft's proprietary solution, and that no one is in a position to determine future directions of installation technology. Thus, since SoftGrid is relatively new and doesn't have a proven history of designing, marketing, and implementing installation technology, the risk of migration to SoftGrid is too high for my tastes.

Learning how to package (or "sequence") with SoftGrid requires one to learn Softricity's packaging tool, and it requires in depth knowledge of the application(s) to be packaged (in order to do it right). With a larger set of applications to package (ours is over 2000), this requirement gets more difficult (and it's not a very marketable skill...like MSI). So there's definitely a trade off...meaning I disagree with the marketing statements about reducing packaging time. You'll get rid of one headache and add another.

One approach is to use SoftGrid to manage only those applications for which conflicts can't be resolved (which hopefully is a significant minority) and use exisiting techologies to manage the majority. Although there's additional overhead, this reduces the risk of choosing the "wrong" technology for the future, while preparing one for changes to the environment, and retaining the skill set to change direction.

I'm surely no expert... this is only my opinion.

thx,

Curtis Sawin

I think technical experts and users that have implemented Softgrid in their environments
should come onboard and discuss their experiences.

We shouldn't be giving a dog a bad name in order to ......

I would not consider myself an expert yet but I am now on a site that is using Softgrid quite extensively. I think it is essential to state that Softgrid will not virtualize all the applications in your organization. Now that you get that out of the way I can say that about 800 applications or 70% are now within the Softgrid environment being delievered to the desktop directly or via Citrix. There is a plan to revisit the applications that were fat installed to the client once the next major release of Softgrid becomes available.

The application is showing it's youth for sure but there are significant gains with the technology. The big gains would be the ability to take the Citrix farms and consolodate them into more of a grid type computing environment. The other benefit is that your applications do not need to install on the desktop so you avoid having to image and resolve application integration conflicts. There is a third benefit that is more environment specific with being able to run legacy applications on modern operating systems which can be useful for those decrepid in house applications.

I find packaging applications to be easier in some ways but there is some significant shifts in how applications are delivered. You are building mini virtual environments which required a slightly more in depth understanding of how the application works rather than what it installs. The beauty of the product is that you can have a sequence full of garbage and it's impact to your environment is not signifcant at all. Still you do need to understand application repackaging and tweak the "bubble" to make the application work correctly in some cases. Still I find the time to deploy an application is less than MSI just because a complex MSI package can take significant man hours to sort out and clean a MSI database. There is tweaking in Softgrid but so far I do not think it is as painful as working with MSIs.



I did mention the fact that the product lacks maturity so below I'll mention my list of gripes:

No support for services / device drivers. (Services are supposed to be in the next release)

The sequencer and the administration console need more work to ease the creation and migration of sequences on to the Softgrid server. You will use notepad quite often.

The sequencer needs to support MSI patching better as well as the InstallShield Script driver. You have to often re-sequence the entire application to apply a patch rather than being able to open the sequence, patch it and then close it.

More friendly error messages.

Sofricity should make trial versions of SoftGrid available.

kkaminsk: Do you prefer the Softgrid solutions to packaging?

I do like it in respect to the problems associated with making working MSIs (compiler issues, transform issues, poor vendor MSIs). Softgrid is more effortless to make a package but in order to make good sequences you have to understand how the application is used opposed to knowing enough to get it installed.

The lack of maturity with the product makes me cautious to recommend it. You have to be fully aware of what this product will and won't do. As with any product I suggest sitting down with it and evaluating it properly. I am sure you could trial the application somehow but it probably involves the whole dog and pony show which can be a bit overwhelming for someone just wanting to take a peek at it.

If you wish to work with the SoftGrid solution for 30 days, which is the license duration allowed for proof-of-concepts (POC), simply request this on Softricity's website. You will probably be first contacted by a representative from Softricity, with a follow-up call from one of their local Partners. The Partner will provide the software and associated POC license. You can bypass the dog and pony show by indicating your preference to run with the software on your own, although they will traditionally run you through some sort of qualifing process before they relenquish the trail version.

Regards,
CanNear

I use an average of 8 Hours (Packageing, documenting and 1st lvl testing).. Easy packages takes about 2 hours, Ultra Hardcore packages can take up to 48 hours... But the again, i build MSI packages every day, so kinda got the hang of it [:D].