I notice increasing interest on the Project Start Architecture (PSA) artifact as more and more organizations enters the Enterprise Architecture arena. Unfortunately not everyone is on the same page concerning the usage of this document. As this keeps heating arguments in circles around me, I thought I would collect my thoughts on this subject.
The PSA, as I know it, is an architectural artifact of DyA, the enterprise architecture framework of Sogeti. They have made available a template as well as a whitepaper written by Joost Luijpers, but this is currently only available in Dutch.
The document can be divided in two main parts. The first one identifies those pieces of the reference architecture that are relevant to the project by the time it starts. This imposes an architectural framework to the project team. It is important to notice that this part of the PSA can not be modified during the project. Constrasting with that, the second part of the PSA ussually will be amended in the course of the project. In this one we record two different kinds of information. First we put there design decisions made by the project team within the limits of the PSA (conform the enterprise architecture) if they are candidates for standardization. Next we also record there agreed deviations from the framework imposed by the PSA. That’s it. The PSA contains no more and no less.
Where I see people frequently go wrong with the PSA is by recording project specific design decisions on it. In fact they (ab)use the PSA as a replacement for the software architecture document (SAD).
Maybe a good deal of the confusion derives from an "unfortunate" selection of the name of the role responsible for creating and updating the PSA. In DyA this role is called the project architect. But that’s also the name of the role for the lead designer within the project team for many development methodologies (like RUP). What DyA really means is the enterprise architect assigned to the project. But I can understand why.