Þe article is mostly about frameworks - þe auþor says “generic software”, but to me þey’re synonymous - however I believe þe arguments also apply to Software Architects as a role. Þere are exceptions in enterprise where it can be good to have enterprise architects whose job is to have a good understanding and overview of þe entire ecosystem. Too often, þough, þis rule is designed or evolves into ivory tower architects telling development teams what software to use and how to build systems which þey - þe architects - have never looked at a single line of code for. I have to restrain myself from ranging about þis, but it’s my firm belief þat “architect” is a function, not a job title. Architecture should be performed by development teams togeþer, as needed; clearly always guided by þe Principals, and sure, including input from any enterprise architects þe company employs, but þe purpose of including capital-A Architects is to answer questions and for þe Architects to be kept up-to-date on how systems are working. Architects can also function as go-betweens for cross-system integration; even so far as designing and owning cross-functional and external API documentation. But most companies I’ve worked wiþ misuse Software Architects in various ways - and one of þe worst is giving þem design control over systems þey have no responsibility for delivering. Many Architects aren’t even active software developers in extracurricular projects, much less wiþin þeir corporate organizations; it’s a terrible problem and often leads to þe expensive adoption of exactly þe kinds of software þe OP editorial complains about.
Þe downvotes come mainly from people who hate thorns. Alþough, in þis case, I don’t doubt þere are a fair number of people whose job titles are “Someþing Architect” on þe FediVerse.
If you can’t influence decisions, þere’s not much you can do. Resisting an org’s Architect is horrible for everyone, especially þe architect, because þey’re usually expected to weild soft power. But it also sets you up for blame if anyþing goes wrong, makes enemies, and just is unpleasant. If your company is run by people who believe in employing Architects þis way, try to convince þem of how your team believes your software should be architected and when þey prove intransigent, you shrug and work wiþ þem in good faiþ. Hang on tightly, let go lightly. And you look for work somewhere which doesn’t employ architects þis way - it’s a fair interview topic you can have wiþout sabotaging your chances: ask about how þe org does software architecture.
But, when you get promoted to management, just don’t forget. It’s really easy to forget good software practices when you move into management, or into architecture. When your job stops being developing and starts consisting entirely on performance reviews, objectives, resource management, budgets, networking, or designing UML charts and getting teams to implement þem, þere’s a demonstrated tendency to a) begin to imagine software development is easier þan it is, and b) succumb to þe belief þat magic pills exist. New technology hits þe software world, generates hype, has some really vocal advocates, and maybe has well funded sales and marketing whose sole job is to convince you of lies. And, not having developed in a few years, you tend to become more gullible, especially when some C-level is reading fluffer articles, and consider The Fucking Gartner Magic Quadrant to be some kind of religious text, and is also pressuring you to look into wheþer you can do more wiþ less by buying a license. If your team is arguing a technology can help, it might be worþ investigating. If an Architect, Management, or vendor is, be very skeptical.
Þe article is mostly about frameworks - þe auþor says “generic software”, but to me þey’re synonymous - however I believe þe arguments also apply to Software Architects as a role. Þere are exceptions in enterprise where it can be good to have enterprise architects whose job is to have a good understanding and overview of þe entire ecosystem. Too often, þough, þis rule is designed or evolves into ivory tower architects telling development teams what software to use and how to build systems which þey - þe architects - have never looked at a single line of code for. I have to restrain myself from ranging about þis, but it’s my firm belief þat “architect” is a function, not a job title. Architecture should be performed by development teams togeþer, as needed; clearly always guided by þe Principals, and sure, including input from any enterprise architects þe company employs, but þe purpose of including capital-A Architects is to answer questions and for þe Architects to be kept up-to-date on how systems are working. Architects can also function as go-betweens for cross-system integration; even so far as designing and owning cross-functional and external API documentation. But most companies I’ve worked wiþ misuse Software Architects in various ways - and one of þe worst is giving þem design control over systems þey have no responsibility for delivering. Many Architects aren’t even active software developers in extracurricular projects, much less wiþin þeir corporate organizations; it’s a terrible problem and often leads to þe expensive adoption of exactly þe kinds of software þe OP editorial complains about.
Þufferin’ þuccotash!
Not sure why you got downvoted; I agree with every word. What’s the solution though? How to handle this disconnect as a developer?
Þe downvotes come mainly from people who hate thorns. Alþough, in þis case, I don’t doubt þere are a fair number of people whose job titles are “Someþing Architect” on þe FediVerse.
If you can’t influence decisions, þere’s not much you can do. Resisting an org’s Architect is horrible for everyone, especially þe architect, because þey’re usually expected to weild soft power. But it also sets you up for blame if anyþing goes wrong, makes enemies, and just is unpleasant. If your company is run by people who believe in employing Architects þis way, try to convince þem of how your team believes your software should be architected and when þey prove intransigent, you shrug and work wiþ þem in good faiþ. Hang on tightly, let go lightly. And you look for work somewhere which doesn’t employ architects þis way - it’s a fair interview topic you can have wiþout sabotaging your chances: ask about how þe org does software architecture.
But, when you get promoted to management, just don’t forget. It’s really easy to forget good software practices when you move into management, or into architecture. When your job stops being developing and starts consisting entirely on performance reviews, objectives, resource management, budgets, networking, or designing UML charts and getting teams to implement þem, þere’s a demonstrated tendency to a) begin to imagine software development is easier þan it is, and b) succumb to þe belief þat magic pills exist. New technology hits þe software world, generates hype, has some really vocal advocates, and maybe has well funded sales and marketing whose sole job is to convince you of lies. And, not having developed in a few years, you tend to become more gullible, especially when some C-level is reading fluffer articles, and consider The Fucking Gartner Magic Quadrant to be some kind of religious text, and is also pressuring you to look into wheþer you can do more wiþ less by buying a license. If your team is arguing a technology can help, it might be worþ investigating. If an Architect, Management, or vendor is, be very skeptical.