I graduated few years back and now work for a consulting company. Frequently i have to contact other consulting companies as the client has code that was written by other consultants.
The consultants have a maintenance contract but sometimes my company is brought in to implement something new and we are asked to reuse the existing code base.
What level of involvement should I expect from the consultants when asking for help in understanding the existing architecture and code base?
a good professional consultant will become as involved as you need him to be, as long as he is being paid
don't expect anything for free; sometimes you might get some help for free, and if you do be sure to express appreciation for it, but don't expect it
What level of involvement should I expect from the consultants when asking for help in understanding the existing architecture and code base?
There are two answers to this question. The first is "whatever the contract specifies," assuming one exists. The other answer is "none at all."
If another consulting firm has nothing to gain by helping you, then they won't. If they're legally obligated to help you due to a contract with the customer, then you can expect whatever's outlined in the contract.
As an addendum to what @Out Into Space wrote:
"whatever the contract specifies,"
Keep in mind they will do the cheapest and quickest way to fulfill the contract, this often means bringing in somebody very green and junior to complete the task. (I've been the green and junior before, and I have been on the receiving end of this too)...
I work in the consultancy business as well and know where you are coming from. Since your own self is working in a consulting company, it should not be that difficult to picture the situation if your positions are reversed with the other vendor serving the same customer.
All of you are carrying out work for the customer's sake. It would be rare for you to be sitting there idling (if you are, let me know if your company is hiring), and you would have projects to commit to, deadlines to beat, crucial defects to investigate and fix. Imagine how you would feel if individuals from the other vendor come knocking on your door while you are trying hard to deliver on all those tasks. There is zero incentive to divert your time and attention to deal with those issues, and all the oppobrium awaits from your bosses and customer should you feel like stalling your own project progress to be a good samaritan.
Now, am I advising to be absolute mercenary and heartless? "If it is not on paper, I'm not doing it." Nope. If you have breathing room, and can afford to, I recommend you put your foot out to assist those in need. Why? Because when it is time for you to need help, you have some friends at the other side. I state this because, having met people from both ends of the scale in my work, parties who have helped me in the past were more likely to earn my respect, trust, and favour. It is reciprocal. Be nice and friendly to others, they are likely to be nice and friendly to you.
But of course there needs to be a balance between this two conflicting points. You have to clearly specify your help is out of goodwill and not always for free. This is to prevent others from taking it for granted. When you have other commitments which your salary is based on, you have no choice. You also have to be sure there is no conflict of business interest between your companies; consult your manager if it is unclear.
So, if there are avenues for you to socialise with the other company, do it. With sincerity. You may get to meet some nice people, some great people, and unfortunately, some cold and nonchalant ones, and even some repulsive folks too. Just don't deliberately build a fence around yourself. Try all means to map out the unofficial, practical hierarchies in the customer's and other vendors' organisations. I tell you, those who are nice will help you in ways impossible from the official (read: beaureucratic) channels. That is key to getting a lot of things done fast and efficient, legally.
Having babbled so much, let's come back to the point of getting the other vendor to conduct hand-over sessions for the code base. As others have mentioned, it may not be in their business interest to teach you anything about their code; they might just lose that maintenance contract. I know my company has lost some before. So the best candidate to motion the other vendor into helping your team is going to be the customer.
Get them involved in every detail and discussion you have with the other vendor. They need to be convinced the other vendor's assistance is necessary in contributing to your progress.
You will have to list out explicitly to the customer the items and issues you wish the other vendor provide or assist you with. That is going to be the checklist and understanding between all three parties - the contract - that the necessary hand-over has been conducted with sufficient detail; so that you can carry out your work. As most hand-overs are done half-heartedly, in very short time, and covering only high-level details, make sure your list is comprehensive enough so that you avoid as much of the low-level nitty-gritty surprises that usually happen.
"Oh, we were never told the uploaded files can only be saved in that particular directory."
"Why must it specifically use UDP port 4486? Now we need raise request for the seven firewalls to allow that port."
EDIT: I remembered an anecdote and think it is good to tell it to emphasize my point.
I had a colleague who, like many others, was unfortunately the run-of-the-mill developer who would take tasks and did "just enough" to get the feature working or defect fixed. He was therefore not the outstanding individual who delved deep into technical topics and pondered on optimizations and code elegance. Sound like yet another person you don't want on your team?
Wrong. Having him in my team is one of the best things ever.
Sure he was not technically superior. But everybody liked him. He was always smiling, always laughing. Even in tough stressful times he can cheer you up. He was sincere, friendly, outgoing; he never spoke ill of anybody and always looked for things (in life) that may interest everybody. He would arrange gatherings, activities, recommend good restaurants. Everything about his personality was amiable. Even the client and customer staff felt so.
Before you even knew it, he was friends with the network administrators, the users, the system administrators, the manager.... the counterpart folks you'd be expected to work with, you name it, he already had buddies.
So when it was time to deploy the new application version, when there was investigation to be done to isolate the cause of the reported errors and we needed access to the server log files, a quick chat with other parties and he was in. Account password expired or locked out? He could get you Express Admin Service to minimise your down time.
His relationship and social skills are top notch. And in the world of business, that is, unfortunately, a very crucial trait to have.