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

Incident Management

Incidents.. hmmm.... Although we use this term vastly in an IT Infra environment, do we really reallise the sense of it? Is the "Incident" and "Problem" all the very same?? We often make this common mistake of perceiving both these terms alike.

In ITIL, both of these has got an altogether different sense and has got its own place in the process-hierarchy. Incidents are the ones which relates to the issues that needs to be restored as quickly as possible as per the agreed SLA's (Service Level Agreements). It focuses on minimizing the impact on the business operations.

But where as, "Problem" is something which is an escalated part of it. When we have a lot many common incidents coming up again and again with an unknown error, it becomes a problem... "Problem Management" makes sure that we minimize the operational impact of incidents and problems which are caused by errors within the IT Infrastructure. It focuses on preventing repeated incidents from happening again and again, after finding out the root cause of the same.

ITSM: IT Service Management

How is ITSM related with ITIL???? Well I would say Wikipedia has come up with the best explanation of what it is... following is a gyst of it...

IT Service Management (ITSM) is a discipline for managing information technology (IT) systems, philosophically centered on the customer's perspective of IT's contribution to the business. ITSM stands in deliberate contrast to technology-centered approaches to IT management and business interaction. ITSM is process-focused and in this sense has ties and common interests with process improvement movement (e.g., TQM, Six Sigma, Business Process Management, CMMI) frameworks and methodologies. The discipline is not concerned with the details of how to use a particular vendor's product, or necessarily with the technical details of the systems under management. Instead, it focuses upon providing a framework to structure IT-related activities and the interactions of IT technical personnel with business customers and users.

IT Service Management is often equated with the Information Technology Infrastructure Library, (ITIL), an official publication of the Office of Government Commerce in the United Kingdom. However, while a version of ITSM is a component of ITIL, ITIL also covers a number of related but distinct disciplines and the two are not synonymous.

ITSM is generally concerned with the "back office" or operational concerns of information technology management (sometimes known as operations architecture), and not with technology development. More info can be obtained from the following link

http://en.wikipedia.org/wiki/IT_Service_Management
..