It’s an impediment
PSA stands for Project Start Architecture and is part of DYA®. PSA documents are one of the most written documents by architects in Netherlands. The purpose of a PSA document is to connect “architectural thinking” with organizational changes. In less vague words: It makes sure that a project gets fences by stating principles, solution direction, guidelines and some decisions before the project starts. At the same time, it’s not “solution architecture”.
Still confusing? Well, it gets even worse. It describes also any or all of the following:
- It makes sure that complete life cycle is taking care of by stating operational and flexibility requirements
- It makes sure you talk less to people in other teams, because most things are already written down.
- It makes sure you don’t discuss standards, guidelines and standard solutions, because that’s already done before the project starts.
- Even the means to achieve the project goal are taking care of.
- Actually, most of the choice are already made and written down in PSA.
Everything in this way of thinking is based on mindset that an Agile team should be kept on leash because otherwise chaos will emerge and an Agile team strives some other goal different from enterprise goals. I’ll elaborate more on this in the following posts.
But, what do I replace PSA with?
 |
| Source: Alistair Cockburn |
When a Scrum team gets assignment, it will usually start iteration zero. In this iteration, the team talks to stakeholders, architects, domain experts, users and other teams, mostly by means of workshops (e.g. Product Vision Box). First and foremost, to understand functional and technical domain well enough in order to:
- make only the necessary, costly to change architectural decisions, needed to start with first stories. E.g. programming language, user interface technology, dependencies on other systems.
- know there are guidelines, dependencies, strategic goals and so on. The team will feel the responsibility to bring those back later on once they are affected by the user stories.
- encourage discussion about correctness and validity of corporate standards, guidelines and choices.
LeanArch.eu 
So the PSA is useful, but the problems this document is intended to solve should not all be solved before starting the project but during the project when you have more knowledge and the means to experiment?
Machiel,True, but you also just diminished "PSA is useful" part of your sentence. :-)Thanks for your comment.
So a PSA has the wrong format (a document) and the wrong scope (irrelevant information). I agree. But i still would argue in favour of architecture on an organizational level. The thing is that investments on an organization level should often be reused by business projects. To deliver this information to projects in an effective and usable form is what i would like to call Agile (enterprise) architecture. Of course this can be done by the projectteam itself … that depends on the context. But i would prefer that the projectteam can start with a focus on the projectscope and still is able to integrate into existing infrastructure.
You are right. "Architecting" on organizational level is still very much important. Delivering this information to teams is of course crucial. Different teams and people interacting is even more important in order to make sure you don't get infrastructure mess.We do lack or even crave for information flow / feedback from teams who actually deal with real architecture. PSA documents are obstructing this.What we really must change is the way "enterprise architecture" stuff is being done by starting that there is no such thing as (Agile or not) enterprise architecture; defined and guarded by enterprise architects. As far as we can talk about architecture on enterprise level, it is the actual real life complex landscape of IT systems connecting with each other and delivering business value. Any other stuff is just different kind of domain knowledge and long term vision. It has nothing to do with architecture. IT systems landscape is too organic to control it by predefined architecture. Anyone trying that is just obstructing delivery of business value. Also, any enterprise architecture definition is oversimplification of the reality. I'll explain this better in the coming posts.
A quote of mine is: "Creativity flourishes on a solid base of routine." To get routine, we need structure and repeating processes. Isn't EA providing this structure? And yes, this structure is changing and yes … it is just a small part of the (life)story of a teammember, but we need structure. I see it as a battle between the network structure of information and the lineair structure of information of individual people. The first is a mean, the latter is the end.Johan Theunissen
This comment has been removed by a blog administrator.
What complete nonsense. Stating that an agile project does not need any restrictions at all is very strange. That amounts to advocating for an enterprise to execute completely autonomous projects. That is exactly what has led to the fragmented, overly complex and non-agile IT landscapes must organisations suffer from. The agile PSA provides as much autonomy to the project as possible and only limits this where this could hurt higher level interests. This is discussed with stakeholders of the project and stakeholders of the overall IT landscape and the results are agreements on the boundaries. Can be done in a single workshop. The enterprise architect is expert on the potential risks for the overall IT landscape and facilitates discussion among stakeholders, the resulting agreements for the PSA. If there are no risks at all then the PSA is empty. In practise this is never the case. It seems very hard to disagree with as the only alternative is to always have completely autonomous projects which is clearly utter nonsens.
Ah, anonymous, I don't think I'm saying that agile does not need restrictions and certainly not that they operate autonomously . Actually Agile projects have much more restrictions in order to maintain or improve overall quality. These are (re)defined continuously by the teams and teams use the input from experts (which is a much better word than 'enterprise architect' and forces a person to actually be an expert) and collaborate a lot all the time with many stakeholders and not via some very limited and inflexible document.What you call "higher interests" and I guess lower interests is incorrect. Each team has the highest possible interest. The usual reason why a team would have limited interests is because of a document like PSA.I would love to elaborate more on this if you could provide your name.
You have a wonderful post. Actually, Agile projects have much more restrictions in order to maintain or improve overall quality. I observe the efficiency of agile project management with scrum but without power, they have a very limited capability to make sure the execute is done on efforts and with the necessary quality.Here are some good for my mind casts about scrum: http://bit.ly/1TmSUlo
Jeeeezzzz Viktor, very very short sighted, amateurish and blind. If you really think agile/scrum is the ultimate holy paradigm you are beyond saving. Just like any hype it has its good points, but is not a cure-all. It is OK to make a living by following hypes, but please don’t put yourself on a self-build pedestal, that is very irritating!
Anonymous, any concrete example of what I said that supports your judgement? I don’t recognize any of it.
Providing your name would be also nice.
A PSA, or any imposed architecture, should be as small as possible. Such architecture documents limit the creative freedom of others and this should only be done for very, very good reasons.
A PSA is usually created by a few people at the worst possible time: before a project starts. This is a moment where we have not had the chance to learn anything because we have not done anything yet. Architects should recognize that and be humble about it and not make tons of decisions beforehand, especially without consulting the team that will realise the product.
The tone of voice in many PSA’s is interesting. Often, they are full of ‘demands’ and ‘rules’ and ‘laws’. “Thou shalt this and that!” It comes across as rather arrogant and not very helpful at all. Architecture is about solving problems and making trade-offs, it’s not about creating more problems that can only be solved in an Esscher drawing.
Hi Eelco, yes, I recognise that too.
Very old posts but I found it quite interesting. Reading all this leaves me thinking what kind of architecture work have you experienced? From my experience, EA activities does not exist inside the Agile teams but Agile teams requires of EA inputs (as-is architecture viewpoints, business drivers, to-be high level architectures, etc.) in order to be even more efective in their decision making (aka solution architecture). Once those decisions are taken, Agile teams must report those changes, one way or another, to the EA so they can act as a stakeholder responsible of the IT landscape and give thier feedback about the proposed change in the landscape, the PSA may work for this but is not ideal. Again, to me it sounds like you have worked with VERY imposing/diva architects, and that of course is not a good approach. Architects should be facilitators not restrictions, specially in Agile practices.
Hi,
In my experience, EA activities do exist “inside” the agile teams. You might want to read about architectural community (https://less.works/less/technical-excellence/architecture-design.html and search for communities) as one example. There are many more. What might be confusing is lack of distinction between “enterprise” and “other” architecture.
Does it mean that all (also organization-wide) architectural decisions are made by teams? No, not all. In some cases, very experienced people together with strategic and C-level people make impactful decisions.
Are those people “architects”? No, I would not call them architects, but name them by their expertise. E.g., security experts, or even more specific.
Are they stakeholders? No, that would be pretty arrogant since they are not a customer, don’t pay for anything and are not responsible for customer products. Due to what you already mentioned, they are facilitators…and teachers. Hence they cannot be essential stakeholders at the same time. It is another way around. Teams and Product Owner are their customers. They help/enable teams to make decisions through teaching, facilitation, etc.
I do know and realize that for most organizations this seems unthinkable. At the same, I have seen already many where this is already the reality. A lot of effort is needed, and teams must be customer-centric, whole product focussed teams. In other words, “feature teams”.
Yes, I agree that one must properly differentiate between “enterprise” and “solution” architecture to realize that the last one belongs to the Agile team to execute. Still, what EA wants is to influence the solution architecture process to guarantee that complexity in the IT landscape doesn’t go overboard for no reason and began generating technology debts here and there, and a PSA is one of many possible options to do this.
What I don’t agree is that all those “very experienced people with strategic and C-level people that make impactful decisions” are not stakeholders. A stakeholder is everyone that has a specific interest in a project, and managing the complexity of the IT landscape or even the security aspects of all the technology is a very valid interests, specially if you are the first to get blamed when something wrong happens. And yes, some of these guys are indeed architects like the chief security officer who ultimately is the one “architecting” the security framework and the one responsible and to blame for if a system is hacked. Even in Spotify, who are quite famous for they agile practices, have system architects overseeing multiple agile teams to influence their decisions and assure consistence in their ecosystems. Ultimately, the design decisions are responsibility of the agile teams, but they always get “additional direction from someone additional from the product owner”.
I’m not sure where and if there is a disagreement between us.
I didn’t mean to say that all those people are not stakeholders. I meant to refer specifically to enterprise architects who are just that: enterprise architects. Term “stakeholder” is then misused to ensure (read: enforce) their decisions and direction. In my experience, whenever there is someone with this title, they entitle themselves to certain decision making. They all mention they want and they involve teams, but in reality this means almost nothing.
Regarding Spotify, I don’t like any reference to Spotify unless a company is providing a music service. Whenever I talk or read from someone actually involved in Spotify I notice that everyone else doesn’t understand what is really happening there.
And even if it is a correct representation of what is hapenning there, it is not a valid argument for me: “Because Spotify does it, then it must be good”.