Funny

 

Untitled

Red sun behind

Canon no more...

Fabula

 Orice asemanare cu realitatea nu e neaparat intamplatoare :

 

 

In aceeasi ordine de idei, ginusa i-a  convins pe cativa purcei sa deschida restaurantul.

Treaba mergea bine, erau vanzari si gratarele faceau profit maxim.

Vazand cat de bine merg lucrurile purceii  au pus-o pus pe gainusa sa se implice in CI-ul de la bucatarie –unde se declarase specialista, in paza si protectie (securitate) unde parea competenta, in retetele preparatelor (design si arhitectura) unde a redus cantitatea de oua… 

Pe partea de performanta gainusa a decis ca viteza e invers poportionala cu numarul de bucatarii asa ca a inceput sa gateasca fiecare fel intr-o bucatarie separata.

La un moment dat deoarece se plictisise si cauta “noi incercari”, mai ales dupa ce retetele de clatite (fara oua) au esuat, iar hotii au furat tot ceea ce purceii au agonisit deoarece usile proiectate de gainusa permiteau deschiderea din exterior in orice situatie, gainusa s-a hotarat sa plece.

Asa ca si-a luat tricoul:

Si le-a spus purceilor “Paaaaa!”

Purceii au ramas dezorientati si fara idei. Ce sa faca mai departe?

S-au gandit sa caute niste purcei mai vechi, cu abilitati – dar ei plecasera cand gainusa le-a luat pozitiile, sau chiar devenisera gratar intre timp.

S-au gandit sa promoveze purcei tineri – dar de la cine sa invete, iar sa aduci o alta gainusa de afara s-ar fi ajuns la exact situatia initiala.

Morala: Nu taiati toti purceii. Nu ascultati toate gainusele.

 

 

Architectural Politics

 

I have recently read "Fundamentals of Software Architecture" by Mark Richards and Neal Ford. The book is nicely written, clearly in Neal Ford's style. There are some points that the book rises and I have some comments on

It begins with enumerating the traits of an architect. One of them is called "Understand and navigate politics". The authors discuss how the decisions of an architect are often challenged while the decision of a developer are almost never challenged and express the difference between the stakeholders that these roles work with.

In my opinion the architect has another problem, of a higher magnitude than trying to get its decisions approved. There is a problem of loyalty. To whom should an architect be faithful? Being faithful to the development team will generally help improve the technical aspects of the project. Being faithful to the business will increase the chances of a project that fits the market better. This would be the ideal situation but there is never such of a black-and-white situation. Business might be undecided with features, development team unruly, other parts of the enterprise or other projects start to mingle in. All the decisions taken in these situation will impact the attachment of the stakeholder to the architect as they will be perceived as loyalty oaths to one or other of the stakeholders.

One of the most vivid images that come to my mind is the image of the French diplomat Talleyrand. He has served in successive antagonistic regimes in the same high caliber position. Is that what an architect is supposed to be? Should one change its mind often and accept requests just for career sake? Should one reject everything just to prove its point? Projects are not architecture driven but wrong architecture will influence the project longterm. An architect should be granted a high degree of autonomy and authority in order to keep the balance between acceptance and rejection of requests in the project stable. Still, although autonomous one shall be loyal and steady. In the book these aspects are not covered, the organisations that the authors use as examples are quasi-ideal, streamlined. In reality the most problems are in contorted, ever-changing and reinventing themselves enterprises.

Another aspect that is important, the book doesn't insist on it, is the relation with other projects in the enterprise. There are always parallel projects that have either convergent or divergent stakes and conflicting stakeholders. It would be nice to be able to diplomatically sort things out but it is not possible sometimes. The relation with other architects can be modelled as a "Texas Hold'em Poker". The private cards of a player are connected to the personal goals. It's a good thing to know your peers, to understand their needs and drives and act for a common good.

Collaboration, mutual help and reasonable compromise are beneficial. Those can help several projects advance at once. Steering of several architects is hard and the role of "primus inter pares" should be taken by a respected member of the group, one who has large autonomy and also authority at corporate level. Otherwise hierarchies of architects will just increase tension and brittleness of the organisation.

One should avoid being a secondary architect in a project because this will create two major issues: loss of autonomy for both architects and secondly it will create raptures both inside the team and among stakeholders - parts of development team will favour one or the other and also the stakeholders will prefer one or the other. There will never be consensus and the phenomenon of "pluralistic ignorance" (as the authors name it) will be prevalent thus adding more strain to the project. Help a younger architect if he/she asks for help but never go oversee or accept to be assigned as a shepherd dog because the risk there is to break the younger architect's wings and reduce his/her confidence in the decisions taken. Coaching younger architects is again not covered in the book although coaching developers is pretty well captured.

No technical career path worth dealing too much with politics. In the end inside a corporation we are all small Sisyphus-like beings pushing a rock upwards again and again. Loyalty should be invested in those who deserve it, adherence to principles should be a guiding force for decisions as one cannot have principles and stakes at the same time.

“Hold faithfulness and sincerity as first principles.” (Confucius) - this will compensate any politics failure. If one is right and unbiased, the political failures caused by standing in for principles will probably pay back later. For me, being a Talleyrand, is one of the worst situations an architect can be in.