CIO Article: What is Architecture?
First, let me say - I find much that I agree with - in the views expressed by the author.
However,
I find the author's statements to be a bit incongruent in one
respect - in that he acknowledges the value of creating architecture views/artifacts for particular
users; to answer specific questions; the relevance of specific
stakeholders; fit-for-purpose depictions, etc...
...to
only then leap to a conclusion, which - as phrased - is not really supported
by the preceding statements:
..."there are only two reasons to create any architecture artifact: to explain an engineering design to a non-engineer, or to mitigate technical risk."
Taken
at face value - this article, if embraced by non-IT executives - does a
great disservice to minimize the value of enterprise architecture
efforts.
I
would submit that there may be other valid scenarios worthy of your consideration - for justifying the creation of architecture artifacts - that would otherwise be excluded by such a
simple test.
These are just a few examples that quickly come to mind:
- To provide a mechanism for evolving (and aligning) the thinking of a proposed architecture - that can be communicated with technical and non-technical staff (e.g. for communication; for managing expectations, for iterative agile architecture evolution; for architecture ideation; for soliciting input - not necessarily to address a technical risk) - which requires both precise technical depictions, and often must necessarily include higher-level abstractions for consumption by non-technical / business stakeholders.
- To communicate and coordinate architecture details with integration partners (whether internally, for communication with distributed teams across a corporation - or, with external third-party partners).
- To support RFP processes - to provide sufficient detail for fixed-price quotes to be negotiated
- To support recurring periodic analysis for Application Portfolio Management (APM) Rationalization opportunities
- To support Value Chain Analysis - and opportunities for rationalization and optimization.
- To support Lean Process Improvement optimization.
- To support roadmap planning.
- To document an Architecture Decision Record (ADR), re: Agile Architecture
- To document the trade-off analysis when there are competing alternatives. This creates a point-in-time perspective - but also is an invaluable tool in teaching business stakeholders, engineers - and in developing junior architects - by serving as an educating mechanism for the concerns that should be considered - how they are weighed - and how to balance competing concerns in making a final decision. This also serves as a "glue" function for improving communication & collaboration with the various stakeholder groups - and supports vetting that architecture has correctly heard (and understood) the key business priorities - and is not basing architecture decisions purely on the merit of technical considerations.
- To support communication and transition planning between AS-IS and TO-BE
- To support Dependency Impact Analysis - to accelerate the ability of the organization to quickly & accurately determine where the modification or replacement of a given system (or component) may have upstream or downstream impact. [Ardoq is one example of an architecture tool that can be of significant help in such an endeavor.]
- To provide a meaningful way to organize and capture "tribal knowledge" that might otherwise walk out the door, as staff turnover inevitably occurs.
- To clearly articulate the boundaries of responsibility between systems; and between automated vs. manual processes;
- To support reviews by Security, Audit, and Compliance/Governance processes - that are mandated by regulatory (or practical) considerations
Where I fundamentally find myself in disagreement with the author, may best be surmised as follows:
- Architecture isn't just about technical risk mitigation, or just explaining the engineering design to a non-engineer.
- Architecture is a holistic exercise that must include not only the engineering and technical aspects of design - but must also consider and reflect the business goals and objectives - and an understanding of the technical/non-technical forces and constraints that may inform, constrain, and guide any solution design considered.
- The architect's role in documenting a system must include an understanding (and representation) - of how value is created for the business - and by documenting the AS-IS, and via transition plan - move the conversation to focus on the TO-BE, driven by a business-valued focus on reducing costs, increasing FLOW - to reduce time-to-market for new products and services, and increasing operational efficiency.
- Architecture is also about telling a story: To answer the important question of "Why?"- as well as "Who", "What', "How", and "Where" (and sometimes, we may need to weigh in on "When" - such as in the sequencing of dependencies, to mitigate technical risks).
- At the heart of the matter, architecture is about value-creation and value-protection for the business. Thus, an architect may rightly justify expending effort in creating and maintaining artifacts for a variety of valid reasons.
No comments:
Post a Comment