It would be simplistic but incorrect to say the Open Group Architecture Framework (TOGAF) is not applied today in business. I too, almost took that misstep. The application of principles are selectively adopted, based on relevance applying to the use and application at hand. Deming stated this well when he said, “The impression that “our problems are different” is a common disease that afflicts management the world over. They are different, to be sure, but the principles that will help to improve the quality of product and service are universal in nature (Deming, 2000, p. 130).” Although architecture frameworks tilt in their prescription of processes, the underlying principles and framework objectives remain virtually constant. Let’s polish up TOGAF, and illustrate together how this framework stacks up to frameworks more visibly being applied today and growing in adoption. By comparing TOGAF with the Scaled Agile Framework it will be evident that the principles in TOGAF have been significantly reused in the Scaled Agile Framework. The frameworks interplay between team, program and portfolio is effectively illustrated in Figure 1. If your teams are using agile design or development principles, this framework is relevant. 
The Scaled Agile Framework was not the first to solve architecture challenges. As we compare outcomes between the TOGAF and Scaled Agile Framework we notice dramatic similarities: 
Agile or iterative methodologies are gaining popularity. Why? Because they are delivering transformative business outcomes. However, as we look deeper it’s obvious that it’s not all new. With quality improvements, the fad of the 1960’s, Kanban principles were applied in 1953 but not heavily written about until 1993. Iterative and incremental development was a driver out of the 1960’s into the 1980’s. But what actually fueled the iterative approaches was the quality improvement and TQM movement established 20 years earlier. From this iterative concept grew the idea of Evolutionary Delivery (EVO) (Gilb, 1985). While many will suggest Agile didn’t start until 2001. It’s evident that scrum concepts start forming in 1986 (Takeuchi & Nonaka, 1986). Quality requires iteration and flexibility. Agile brings us one step close to quality delivery. Fascinating as it may be to envision the Scaled Agile Framework as an innovative new concept of 2011, its roots go back much further. Agility continues to be a leading ‘in demand’ skill not only for CIOs but also for software and product companies. We don’t have to look far to find the 2015 Gartner Quadrant for Application Development Life Cycle Management, and notice that Atlassian (Jira suite) is in the upper right quartile. This quartile highlights industry leaders in Figure 2. 
Inclusion is required. Peter Weill in a winter 2005 edition of the MITSloan management review states that, “Throughout an organization individuals make decisions daily that influence” (Weill, Ross, 2005, p. 1). Architecture solutions are readily at hand. What is required is the right decision with the right values. In order to do that the right people need to be included. Cross functional inclusion to grow and solidify solutions is mandatory. This broad engagement is often difficult to secure without direct executive sponsorship. Even with executive leadership’s nod, cross functional education and participation is a constant risk to successful outcomes of every architecture framework. What is clear is that no single architecture framework is applied as-is without tailoring that process to fit the culture, people and technology that reside within each organization. Who wants average? Whether you’re talking about a car, population health, or architecture frameworks – vanilla isn’t appealing and is even harder to sell. It’s unlikely that after fully understanding your customers (end users, influencers), collaborators (suppliers, allies, leaders), capabilities (human, operational, financial, technical), competitors (direct, indirect, potential), and environmental conditions (social, demographic, political, regulatory, economic and market) that average will be path forward. Use what works based on the unique requirements of your organization and throw away the rest. References Deming, W. E. (2000). Out of the Crisis. Cambridge, MA: Massachusetts Institute of Technology, Center for Advanced Educational Services. Freedom Benefits. (2015). Largest US Health Insurance Companies. Retrieved from http://www.freedombenefits.net/affordable-health-insurance-articles/Largest-125-US-Health-Insurance-Companies.html Larman C. & Basili V. R. (2003). “Iterative and Incremental Development: A Brief History.” IEEE Computer Society 36(6): 47-56 Leffingwell, D. (2015). Dean Leffingwell on the Value of using the Scaled Agile Framework (SAFe). Retrieved from https://youtu.be/qSYw1RrSDNY Scaled Agile, Inc. (2015). Scaled Agile Framework. Retrieved from http://www.scaledagileframework.com/ Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard Business Review, (January) Weill, Peter, & Ross, Jeanne. (2005). A Matrixed Approach to Designing IT Governance. MITSLOAN Management Review, 46(2), 1–11. Wilson, N., Druggan, J., Murphy, T. E., Sobejana, M., & Herschmann, J. (2015). Gartner Magic Quadrant for Application Development Life Cycle Management. Gartner Inc., 1–25.