Developers are exchangeable. Contractors doubly so. On the other hand, an architect is generally solidly inside a project and not as replaceable. So companies prefer to keep them as employees (and/or stock options) to try and keep them where they are. The other thing is that companies tend to promote from within, so contractors tend to get the interesting/hard work, but working up the hierarchy tends to involve employees ...

In my experience, better bullshitting skills. Present company excepted, of course.

As a contract technical architect I can vouch for Alex's comment.

I can also confirm that if the management believed that they would be more comfortable if I was permie then they would be wrong ;)

Matt.

I'm not sure that all country (EU), but the most part I'm sure have the same situation but on wide-network project (national network o corporate network projects). Evaluating team members and project managers, you'll not see a lot of professional needed. Not only architect but also other profiles.

The same "worst" practice are used: the general manager of an IT company consider an architect needed only when are developing "THE software" or "THE network infrastructure".
Sometimes only if the software is the next software (not next release) of the company.

But if you are developing software for customers usually the presence of an architect is only a "cost". Usually the IT manager of the customers think the same: "our project is not so important to need an architect. I know all details and all our architectures".

Another case is with company that resell develop software: will happen that architect are unneeded. Having specific competence on the subjetcs how can you resell officially an architect to a customer when the company present itself like the best in competence on his "sector/market".

In the last years, during my PM role, only 2 nationl project about 10 project have all role needed....

The software will be less expensive, more "reusable" and more efficient when every development team have an Architect.
The developer write poor software without an architect (or a mentor). The same is for projects about networking, security and so on.

To have architects in every development team I suppose we need an evolution: In the future the "cut-cost" will increase ever and ever. At that point the price x project will be measured with specific service level agreement (performance, transaction and so on). No more with developer times, competence and team members.

This will be a new starting point for developing company.
At this point only the company that use all needed professionals (architect, operation, etc etc) will raise again....

Those are interesting figures and the percentage of contract architect roles is higher than I thought. I wonder though, how many of those roles are really "architects" rather than lead developers. I think that's a separate topic. ;-)

It seems natural to me that somewhere between the cleaner and the CEO, most organisations have a comfort level at which they stop using contractors.  Presumably because of factors such as:

• The amount of business knowledge required to be effective.  I'm currently working on a SOA project, where the architects need to take into account (overly) complex dependencies between business processes and (144+) IT systems when making decisions. This knowledge takes time to build, so the permie architect offers the benefit of at least keeping the knowledge in-house.
  
• Accountability for long-term and hard-to-reverse decisions.  Assuming that the role of the architect is to make these decisions, as an organisation it would be preferable to have a degree of assurance the the architect will still be around (i.e. permie) or could potentially be recalled (via a consultancy with a reputation to protect) and not just ride off into the night.
  
• The importance of building effective working relationships with other teams and individuals within the organisation - especially where the architecture has potential implications for those teams.  This can take time to get to know the politics and ways of working of the individuals (as well as the systems) that you need to interface with.

Clearly, it'll depend on the type of architect you're looking for (application, system, enterprise, data, information...) but I don't find it surprising that pluggability is considered lower that that of designers and developers.
 

You quite often find roles for "application architects" as opposed to "technical architects" offered as contracts.

The distinction between the two being that an application architect will be confined to working within the bounds of a project, usually with some additional controls being set by a technical architect.

Contracts for application architects will usually run for the duration of a project, as the customer does typically want to ensure a level of continuity up until the go-live date.

Given that technical architects will be working on numerous projects, and assist in shaping policy, it is unsurprising that these roles are not offered as contracts.

Another role which is rarely offered as a contract is that of solution architect, which tends to blend responsibilities of a technical architect role with those of an application architect in a pre-sales environment. I would hazard a guess that this role s infrequently offered as a contract position due to its commercial sensitivity.

Talking of which... I'm looking for a new contract as an application architect at this very moment. :-)

To a large extent, I think the reason that most of these roles don't go to contractors is one of "trust". When a person is employed as a permie they have made a commitment to the company. They have turned their back on all other opportunities and accepted a role within the organisation. This earns the trust of the company, which in turn allows them to be given high-value, high-impact work - such as architecture roles.

The same can be said of a consultancy. Largely for a consultancy to be considered for high-value, high-impact work, they have to have earned the trust of the customer. This may have been achieved by lots of lower-value, lower-impact work in the past, relationships, or reputation.

It is hard for an individual contractor to gain the sort of trust required in order to be given these roles - some organisations see contracts as "fly-by-night" sorts (the contract market has done itself no favours over the years!) So an answer would seem to be to build a reputation, either via relationships/networks or industry notoriety, or to do a few regular development roles within an organisation in an attempt to gain trust (this of course could backfire, as they may never see you as anything but a developer!)