Sander, 
A Project Start Architecture is a new name for a very old concept called specification. It is a document specifying what the organisation wants and needs from a project. 
 
Based on managed knowledge of information as a corporate resource the project start architecture can be derived from the knowledge you have. For that reason it is neither an architecture, nor is it something of increasing relevance. On the contrary, demandside will manage their own knowledge, where a PSA is nothing more then a temporary spec is changes need to be made in the IT-infrastructure. For that reason the PSA is of limited relevance to the demand organisation, and only important for IT-suppliers because it tells them what needs to be changed.

The discussion I’m trying to start here is where architecture stops and design begins. In my point of view a Project Start Architecture (PSA) can be used to bridge the gab between a prescriptive architecture approach – where by the use of principles and reference models the design freedom is being limited – and a more system design oriented approach (also see ‘Three perspectives on architecture, Erik Proper 13 December’). The main topics addressed in a PSA are: the driving business requirements (not the user requirements), the current situation (the descriptive architecture approach), the relevant principles, the available reference models (context of the project within the reference architecture) and the to-be situation (the solution). Addressing stakeholder concerns and describing the solution from various viewpoints (aligning business-, information-, application- and infrastructure architecture), demand and supply will be brought closer together, creating an agreement on the project objectives and scope. 
 
Yes, the PSA is a temporary document. After realization the (descriptive) as-is architecture has changed. The views created in the PSA can be used to up-date the architecture descriptions to the current status. 
 
The question is still how far we should go in describing the to-be situation. In practice you will see that a PSA will have a lot of content you would normally see in specification- and/or software architecture document. I think this is because the purpose of a PSA is not always clear and thereby often misused. In my opinion the PSA can be used to make some high level design decisions (like the technology to use) based on possible risks to the project, but this will depend on project need. 
 
I do think a PSA is of great relevance (and a lot of organizations do to) to align the demand and supply (business and IT), avoid solutions that are not in line with enterprise architecture strategy and to improve project success.

Sander, 
 
Well, I’m afraid the discussion where architecture ends and designs begins is losing/has lost much of its relevance in practice. The reason for this is that change (and therefore IT-project) is not really a basic issue any more. Let me explain. 
 
In the 80’s and 90’s we have seen a shift in looking at technical IT-infrastructures. We did not want stand-alone machines performing their tasks anymore, we went for technical IT-infrastructures where system software became a layer enabling access to all kinds of hardware (open) and distribution. In fact it was the first move from vertical to horizontal thinking, where IT became an available platform/infrastructure. 
A second shift came about around when we entered the millennium. We did not want to think and work anymore with separate application, stovepipes etc. We created an application landscape by introducing an application infrastructure and a data infrastructure as 2 layers on top of the technical IT-infrastructure. This second shift is usually known as the importance of aligning IT with the business, but in fact it is a shift, again, from vertical to horizontal thinking. 
A third shift is still in an embryonic stage. It is a shift outside IT, where knowledge of information is managed as a corporate resource. A third shift from vertical to horizontal, where the work of the information analyst becomes the work of an (enterprise) information architect. The knowledge of information, when it is mature enough, really eliminates the work of the information analyst in projects. Because we know what we want because we know about our information the analysis stage of project can be reduced from an average 30% to a maximum of say 5%. It really becomes a step to understand, learn and maybe evaluate what we already know as a preliminary step in a development. 
 
IT-vendors do not want to recognise the third shift. They want their specification phase, their project start architecture if you want. It is a large part of their bread and butter because the phase allows them to work with their customers quite intimately and they do not want to lose this opportunity. While in fact they ought to work like contractors and do what their customer asks them to do.  
 
Now this is the problem of what is called demand side or, by IT-vendors, retained organisation. In fact it is quite simple. If an organisation knows very well what they want, they can tell this to their IT-people (internal or, if outsourced, from IT-contractors/IT-vendors). That is why this knowledge is always prescriptive for IT-vendors. If they understand what they need to do, this is knowledge transfer and I did estimate this to be a max of 5% of the total project, they are able to propose a solution to do it. So the first real step in a IT-project becomes a (functional) design.  
 
This is the reason why the importance of what you call a Project Start Architecture, a term taken from DYA from IT-vendor Capgemini/Sogeti, will diminish in time. The emphasis will be on the knowledge of information of the “customer”, the organisation itself. With this knowledge they can really manage IT without really getting into IT themselves. That is why the real PSA is derived from their knowledge and will have to be a document made by the organisation itself. If I look at what it contains the term PSA is wrong because it is a mere limited view on what we already know to enable IT to create an IT-solution. 
 
This has massive consequences for IT-vendors. They not only lose their analysis phase, they also lose their services in the knowledge of information itself. Simply because it is a very bad idea to let a contractor write down a specification of what they are going to do. This is a big no-no when you want a separation of functions. And this is also what is emerging in practice: when you know very well what you want, nobody is going to sell you more then that. I have seen projectbudgets cut to a fifth or even a tenth of its original size because of this. And, much more important, I have seen really significant improvements in the exploitation of these IT-solutions because they are within specified bounds. 
 
One of the reason IT-vendors can no longer put a lid on this way of working is outsourcing, and really when you are doing offshore outsourcing. Everybody involved in outsourcing at demand side knows that if you ask a question to a person in for instance India you get a perfect answer to that question. But if you do not ask the right question, or if the question is not formulated well you will not get what you want. The term GIGO as become very well-known: garbage-in is garbage-out. And the people you ask are really not to blame because you have formulated an ambiguous request. This is why outsourcing will become a boomerang in the near future. 
 
In this light, do you understand why PSA is becoming less and less important now? It is not the question of its content not being important, it is the way of looking at IT. The IT-vendor point of view is becoming less and less important, they will become solution people soon, contractors. As it should have been from the start. A Project Start Architecture as-is today is a typical IT-vendor issue, and has in fact very little to do with architecture. 
 
Steven van ‘t Veld