The Merriam-Webster dictionary defines “runaway” as “the act of running away out of control.” The Scaled Agile Framework (SAFe©) defines the architecture “runway” as “the existing code, components, and technical infrastructure needed to implement near-term features with minimal redesign and delay.” Without the architecture “runway,” your architecture projects will “runaway.” In such a scenario, opportunities for the reusability of building blocks and better control of “design debt” and technical debt” increase dramatically, constraining the flow and velocity of solution delivery teams.
By juxtaposing the two terms (runaway and runway), we can compare TOGAF’s and SAFe’s difference in how they approach the requirements topic in their respective frameworks. The potential for“Requirements runaway” is what I associate with TOGAF’s lack of an explicit approach for requirements elicitation and analysis. TOGAF, which we consider as a springboard to then pursue more EA mastery, does not dive into these more granular practices. Instead, it focuses more on the more overarching concept of requirements management. Nonetheless, good requirements documented at an early stage of architecture or solution development are a key contributor to the delivery of any project or product. If we are unaware of constraints or of the lack of potential in our “architecture runway”, we may not detect risks nor produce reasonable level-of-effort estimates for our architecture or solution development initiatives. This shortfall will hamper our ability to provide value to project or product development teams, as well as our ability to best define scope for an initiative.
In addition, TOGAF’s iterative approach in its Architecture Development Method (ADM) approach can benefit from SAFe’s retrospective process. Retrospectives could be applied after each iteration instead of waiting for the end of the cycle’s lessons learned documentation. This not only improves retrospectives, but also enables feedback from development teams back to architects by inverting the agile requirements model hierarchy (story, feature, enabler, capability, epic). Lack of early feedback reduces ROME (return on modeling effort) by increasing EA activities at all levels of enterprise architecture, increases the risk, reduces customer value delivery, and creates misunderstandings between different levels of organization. Lack of feedback also slows the velocity of change by disrupting project cadence.
Overall, valuable new insights about how to approach the requirements life cycle can be generated from the consideration of how different architecture frameworks and modeling standards (to include ArchiMate) address this topic. Below you will find an initial drafting by ChatGPT to align TOGAF’s’s ADM phases, modeling, and requirements development practices with those of SAFe stakeholders, selected ArchiMate viewpoints, and the types of SAFe requirements:
According to ChatGPT: “This table integrates TOGAF’s ADM phases with the respective modeling practices, the purpose of modeling, SAFe stakeholders, ArchiMate viewpoints that can be helpful in developing SAFe requirements, the target SAFe level, and the SAFe’s requirement type. Again, this alignment is more of a general guideline and could be adapted based on an organization’s specific context and needs.”
Authored by Alex Wyka, EA Principals Senior Consultant and Principal