 |
(image source: JillWellington on pixabay.com)
|
This post is intended as a response to a recent InfoQ article: Software Architecture: It Might Not Be What You Think It Is [and this LinkedIn post]. These four statements from the article will give you some insight into what prompted me to write my response:
- "Software architecture needs to be wrested from committees of people
disconnected from developing, and to put it in the hands of the people
who can actually make it real and executable, the developers."
- "Software architecture is about capturing decisions, not describing structure"
- "Architecting is a skill that agile teams embody, which means that Architect should not be a role"
- "Software architecture has a contentious reputation in the agile
community. In the experiences of many, it is the cause of valueless
meetings and irrelevant documentation that is aptly summarized by the
expression “the map is not the territory.” [underline and red coloring, my emphasis]
The level of formalism that any organization may invest in the practice of architecture - and the types of architect roles - and structure of architecture staffing - will of course vary, depending on several factors, such as: size of the organization, regulatory/compliance complexity, revenue, profitability, whether it is a start-up - or a large corporation. However, to dismiss the formal role of any architect - and apparently, the value of any formal architecture governance and oversight processes (outside of the delivery team) - is what I find particularly disturbing about the author's premise.
A delivery team is necessarily primarily focused on the decisions within the locus of their control, their scope, their budget, their backlog, and their specific concerns.
There is a level of concern above the delivery team - and above the system-specific context - and that is where the broader enterprise-wide considerations exist. At this level, there needs to be the {freedom, latitude, ability} to take a longer and broader view - not driven, or limited - by the constraints of a delivery team's immediate goals, release cycles, or the narrower focus of a given project's budget/scope.
This is where the role of architect is certainly appropriate - to establish patterns, establish consistent and repeatable enterprise-wide governance, security, compliance, information architecture, define {principles, policies, standards, and specifications} - help establish long-term roadmaps, monitor and plan for rationalization, anticipate and plan for End-of-Life - and modernization transitions, and consider the dependencies across many systems (both internal - and external).
If your focus/concern is only about decisions focused on shipping/releasing a particular system - you lose the luxury (and time) to take the broader view - to consider the longer-term implications of decisions.
Quite often, the implications of a design can be anticipated by judicious investment in the creation/elaboration of architecture views - and conducting design reviews - before building, before shipping - which can hep mitigate security risks, compliance concerns, performance issues that can be identified by recognizing the anti-patterns inherent in a design, waste, rework, and identify opportunities for reuse across the enterprise.
When teams are measured/rewarded - according to their system-focused view - there is little incentive to consider the broader implications of design decisions at the enterprise level.
Architecture isn't just about design decisions for a single system - it is also about compliance, governance, communication, roadmaps, alignment, oversight for portfolios of applications - that may cross enterprises, and across organizational silos within an enterprise, and multiple project/delivery teams.
Architecture, as a discipline in IT - is not some ephemeral responsibility that can be randomly distributed. There is a minimum threshold of knowledge, experience, and expertise - required to perform in the role of an architect. Not everyone on a delivery team has that level of experience.
Furthermore, there is a significant ongoing investment of time, effort, and money - that a competent architect invests in learning their craft, and maintaining/expanding the mastery of their craft. Delivery team members just don't have the luxury of time, and latitude of focus - to maintain that level of architecture competence.
Finally, I offer you: Meeks Software Architecture Conjecture #1:
(in response to the author's dismissive disregard for describing the structure of an architecture...)
The source code may (or may not) be a full implementation of the
desired capability needed by the business - but is more likely just an
approximation (constrained by permitted time, allocated budget, and
available skills/talent of the team involved). Therefore it should not
be confused with the actual or desired (or envisioned) design - that may
require multiple years to achieve - of which the current source code
may only reflect a partial (and incomplete, or inaccurate)
representation.
