“Runaway” Requirements or Requirements “Runway”?

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:

Modeling PracticesPurpose of the process in requirements developmentSAFe StakeholdersArchiMate Viewpoints for SAFeSAFe LevelSAFe Requirement Type
PreliminaryStakeholder analysis Vision articulationElicitationEpic Owners Enterprise ArchitectsStakeholder viewpoint Goal Realization viewpointPortfolioEpics
A: Architecture VisionScenario definition High-level solution sketchingElicitationPortfolio Managers Enterprise ArchitectsMotivation viewpoint Strategy viewpointPortfolioEpics
B: Business ArchitectureBusiness process modeling Capability mappingAnalysisBusiness Owners Product ManagementBusiness Process Cooperation viewpoint Product lifecycle viewpointProgram Large SolutionCapabilities
C: Information Systems Arch.Data architecture Application communicationAnalysisSystem Architects Solution ArchitectsApplication Communication viewpoint Information Structure viewpointProgram Large SolutionCapabilities, Features
D: Technology ArchitectureInfrastructure mapping Middleware specificationAnalysisSystem Architects Infrastructure TeamsInfrastructure viewpoint System Use-Case viewpointProgramFeatures
E: Opportunities & SolutionsGap analysis Solution decompositionElicitationRelease Train Engineers Solution ArchitectsGap analysis viewpoint Implementation and deployment viewpointProgram Large SolutionFeatures, Nonfunctional Requirements
F: Migration PlanningRoadmap development Migration strategyAnalysisChange Agents Release Train EngineersMigration roadmap viewpoint Project viewpointLarge Solution PortfolioCapabilities, Epics
G: Implementation GovernanceSolution validation Compliance checkingAnalysisAgile Teams Product OwnersImplementation and deployment viewpoint Requirements realizationTeam ProgramFeatures, Stories
H: Architecture Change Mgmt.Change tracking Impact analysisAnalysisAgile Teams Product ManagementRequirements realization viewpoint Goal Contribution viewpointTeamStories, Nonfunctional 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