Back to Application Packaging.

I'd expressed about "MSI packaging" in the post dated back 14th of June 2007 on what I think about the same. I'm back with a bit more understanding. I thought of putting all those in words here.

In my simple sense, it helps you to get an application installed in target machine as I mentioned earlier too. Usually when we say "package", we tend to think something beyond technical frontline. Simply pu up, a package is a collection of files and directories in a defined format. You could say its a application software... delivered in units or an archive or store of files and directories required for the software product or something. This work as per my perception begins after the entire application code is ready. A s/w product is required to be built into one or more packages so that it can be easily transferred to a distribution medium; for eg: AD's Group Policy (I think so but not very sure). Once distributed s/w product can be mass produced and can be installed by administrators.

In its 1st Step, we need to Create pkginfo file. This file is an ASCII file that describes the features of the package and the information which controls the flow of installation. Each entry in the pkginfo file is a line that establishes the value of a parameter in the following form:

PARAM= "value"

Some of the mandatory parameters are: ARCH, VERSION, PKG, CATEGORY and NAME.

ARCH (Specifies Package Architecture) is a set of alphanumeric tokens which indicates the architecture associated with the package. pkgmk produces an installable package to be used as input to the 'pkgadd' command. The package contents are in the directory structure format.


VERSION (Specifies Package Version) parameter in the pkginfo file identifies the version of the package.


PKG (Package Abrreviation) is just the short name or Abbreviation for the package that is defined within the parameters of PKG in pkginfo file. It should be further bound within certain characteristics. I'll discuss that when I'm clear on that part.


CATEGORY (Defines Package Category) parameter in the pkginfo file precisely specifies to which categories a particular package belongs to. A package should belong to atleast either "System" or "Application" category. If a package belongs to more than one category, we need to specify the categories in a comma-separated list.


NAME (Defines the Package Name) is the full name of the package which as rightly assumed, is defined by NAME parameter in the pkginfo file. Specifying complete package names precisely is very important as system administrators often use package names to determine whether a package needs to be installed.


Lets steer a bit further and look ahead,

How to Create a pkginfo File

1. Using your favorite text editor, create a file named "pkginfo". You can create this file anywhere on your system.

2. Edit the file and define the five required parameters. The five required parameters are: ARCH, VERSION, PKG, CATEGORY and NAME.

3. Add any optional parameters to the file.

4. Save your changes and quit the editor.
   

This was not even a gyst. Let me go through, study and I'll be back again on this topic soon with my humble explanation; expecting to get the feedbacks and lessons which would surely share to my knowledge level too.

What does a Consultant DO?

My views are purely the outcome of my experience. Now this is something very interesting. I'm recently into "web-development-consulting''. So to comment upon, I would begin with saying, that consulting is an art where the power of communication, ideas, intellect and know-how of the concerned market are together driven towards the achievement of the ultimate requirement of the client, adding value to our service. Here, understanding the client's requirement is very important. The skills demanded by the position of being a consultant is tremendous but these skills alone wont help. Its like "I have a phone but no one to talk to". Yes I mean it right... 'being client-centric' is essential at every instance being a consultant. The bottom line says, "Being a consultant, is being client-centric".

But then, is that so very easy as we think? I wont comment on that, as it depends on the experience and expertise level of various tycoons of consulting industry, no matter in what. In every aspect of consulting, client plays the most important role. For the purpose of knowing the needs and core requirements of the client, we need to undergo a vast thought-process, we need to have an in-depth insight about the business goals of the client, how does it function, the circle of all the vendors with whom they work with, the vendor policies, outsourcing details, etc. The more clear and precise we have the information with us, the more we have the ideas "ready-to-sell". This comes not with a great liberation but a lot of sacrifice. But its not necessary, all the time that we need to know these since it also depends on the policies of the companies, if they would disclose these critcal information. So we need to be wise enough to understand and act as per the circumstances based on facts. There are 'n' number of factors which influences 'consulting', which gives you 'n' number of options.

When in a meeting for instance, with the client, nothing but a scribbler will do a great help. This helps you to jolt down the critical points and minute details that you may miss out while making some of the most critical decisions. I do very precisely remember a phrase told to us by my high school principal. He'd said, "A faint ink is much better than a sharp memory". So travelling back from the sweet memory lane and re-learning some school days lesson, the punch line here says rather screams with a pinch of salt to convey the message. The points that we write down when in a meeting helps us not to miss out any minute details that is being conveyed to us by the client, helping us to get to the root level of the requirement and thus better decisions. Does the job of a consultant finishes here? I definitely need some further insight into the same.

Service Desk: A process or a function?

Time and again I have come across many questions if 'Service Desk' is a process or a functionality. I completed my ITIL training recently. I was full of questions regarding the same. I filled the classroom with the clouds of confusion over this topic. Many students came up with the same questions and some of them advocated against the fact that "Service Desk' is a functionality. Now before I make this statement, I need to be very sure of what I am trying to advocate. Ofcourse the fact that the it is indeed a functionalilty as described in ITIL documents. But my answers to "Whys" are very clear.

First... what I realised practically from my experience is that a user is completely isolated from the problem of repeated calling and finding the right person for the resolution. 'Help Desk' serves as a single point of contact (SPOC) for all the issues to be reported. From here all the resolutions are provided. It handles all the incoming calls and escalates them to the second or third level of support only if badly needed. Service Desk staff consists of skilled and experienced IT technicians. Service Desk is also responsible for regular updates to the customer about the status of thier request (in other words, 'tickets' and the 'users' as known in corporate companies).

It is an important part of Incident management process of providing an operatinal single point of contacts to manage incidents to resolution. Two main focuses of the Service Desk are Incident control and communication. Again here communication plays a very important role. I have come across situations where the helpdesk co-ordinator in our company picks up the call for some issues and ends up with raising a ticket for some other issue. In this case when this ticket is assigned to the concerned IT technician, it creates the whole confusions leading to a total chaos. This results in customer (user) dissapointment and a prolonged downtime., which adversely affects the business outputs. This is how the very purpose of IT service management looses its complete definition just because of the lack of good communication at the first place.

So now this is very clear that Service Desk is indeed a functionality. Now the question is who plays the most important role in this functionality ?? Read on....