Ivory Tower Syndrome
As you might agree with me, the traditional role of an architect had a lot to do with objective analysis, clear and standard deliverables, considerations of long-term planning horizons, leaving to other roles within the organization (such as product owners, project managers, developers, etc.) the responsibility to implement and oversee the delivery of the packages identified: this waterfall model is challenged by a continuously evolving technological and business context, that risks to reduce, or even erase, the value of some of the analysis delivered in previous stages.
Because of this observed pattern, commercial organizations (and some public institutions) have embraced the vision of agile methodologies for organizing work and deliveries, focusing on the constant observation of users’ behaviors, continuously learning and iterating products and services.
To ensure quality, consistency and governance, architects have been requested to move further down in the organization chart, becoming an always available figure for shorter-term deliveries, quicker evaluations, smaller packages: descending an ivory tower, losing a fairly good amount of certainty, backed by best practices, standards and models, fighting together with teams and supporting quicker iterations.
Such new collaboration model has brought many architects outside their comfort zone, demanding them to acquire leadership skills and methods, dealing with those colleagues who were in fact not previously included in their routines, and starting to deliver easier and more direct deliverables (application architectures, ERDs, impact analysis, etc.): they are now charged with the expectation to be leaders, mentoring and supporting, rather than delegating or managing their colleagues, especially in the implementation phase of the architecture, to be clear and simple, not cryptic and formal.
Architectural models have evolved as well, introducing more and more atomization and distribution of functions (microservices, mesh, serverless), disrupting the monolithic approach to development, leveraging the appetite of organizations to reduce risks and increase the frequency of the delivery of functions to customers: together with the software, the roles and functions of architects has also been spread, weaking the idea of an Architecture function controlling all the small moving parts of the whole enterprise.
At the same time, to match such atomization, some technical leadership roles previously in place (like Tech Leads, Senior Engineers), given their proximity to the development activities, have been elevated and requested to start owning the architecture of applications, services and systems they developed, beyond their own will and initial ambitions, causing misunderstandings of the duties and deliverables.
Such movements shouldn’t mean that Enterprise Architects would have became irrelevant, rather the contrary (at least in large organizations): in fact, they have been challenged to lose detailed view on the architecture of the enterprise, to rather focus on the leadership of people (system architects, solution architects, tech leads, senior engineers, etc.) who would ultimately provide the accurate view, governance and development of their architecture.