First, let me say that I greatly admire Martin Fowler - and have told him so, in person, during a QCon in San Francisco some years ago - and that he is a great inspiration to my own personal growth in this field.
But, I do have a few questions - that I think are worth considering as a counter-point to his views expressed in this talk - which I do not think quite adequately consider the matter:
1. While AS-IS may very well be expressed in code (to a great extent) - what of the TO-BE, which may well need to be charted and communicated over a multi-year arc of intent, effort, and funding by the business - in coordination with dozens, hundreds, or thousands of third-party partners?
2. What of communicating an understanding of those aspects of the design, which may need to be shared and communicated with third-parties - such as in the case of major (and complex) integration efforts? Will you just give those (potential competitors) the code?
3. What of communicating an understanding of those aspects of the overall system - some of which may not be implemented in your code - and which may rely upon other systems for which you do not have access to the source code (or which may be hosted by Cloud SaaS providers)?
4. What of communicating an understanding of those aspects of the overall system - some of which may not be implemented in code - and which may be implemented as manual processes - but are still critical elements to understanding the true scope of the overall system?
As Randy Shoup notes in his talk "Moving Fast at Scale" - "Sometimes we solve those problems with code" [emphasis, mine] - which begs the question, Martin: How do you document those things that are not in code, if not with diagrams?
5. What of the oversight and governance functions that should be tended to - as systems must be managed through a life-cycle - which must include a clear understanding of the architectural implications when sun-setting, replacement, or rationalization choices must be considered, researched, choices evaluated, recommendations prepared, etc. - are architects who spend their time coding - and not keeping a weather eye on these concerns - really making the best use of their time for the business they are serving?
6. Whether an architect codes (as their primary activity, or no more) - and whether there is value in an architect who no longer codes - seems to me to be primarily a question of scale. In a multi-billion dollar business - in which an architect may be responsible for the oversight of dozens of applications, within one or more given business lines (of which there may well be dozens) - they are typically required to closely monitor, align, and coordinate the architectural road maps that span multiple business lines - usually involving multiple organizational units, external third-party partners, and impacting potentially hundreds of applications - over multi-year staged delivery planning of capabilities. Is it really feasible (or optimal to the business) to have someone in such an architect role - being buried in the minutiae of coding?
7. Does the architect of a major commercial building, a skyscraper, a new aircraft, a bridge, or a new automobile design spend their time pouring foundations, laying bricks, running wiring through conduit, riveting sheet metal, on the assembly line, etc.? Would any professional architect worth their salt sneer at the very thought of being expected to document the design of such endeavors? Or would they simply say, pop the hood and disassemble the engine if you want to understand how it works? What of the systems that approach (or exceed) 1M+ lines of code - and which may exist in an ecosystem of a multitude of other systems that are of similar size and complexity? Is it feasible to require people to just read the code to understand one of those systems - or the potentially intricate interactions between them? Does your advice of a 'just a few diagrams' still hold?
For these reasons, we should be open to embracing - across a continuum of diversity of possible manifestations - the possible interpretations of the role of Software Architect (or even, Enterprise Architect) - and not be disparaging - and certainly not promote the use of such derisive terms as 'Architecture Astronaut'.
Meeks' Software Architecture Conjecture #1:
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.
No comments:
Post a Comment