The role of Enterprise Architecture was described as looking at the organization as a whole and making decisions / recommendations for changes to better support the business operating model. It usually gets narrowed into IT recommendations, based on current state analysis and looking at the trends in the market. Unfortunately for EA's, their recommendations look like a mish mash of projects from the perspective of the business sponsors. Too many great ideas - too many to implement all at once, but they need to be done together to get the value. And when they get started implementing, they often get stuck in local implementations or pilots that force them into a local / global conflict that usually resolves on solving easy, local problems.
TOC comes into the picture in the direction of the questions. Where is the constraint inside the organization? What blocks flow in operations? What about the customer? What changes are required to remove limitations for them? What does the customer need? What about the larger ecosystem of suppliers, partners and customers - how does the current system block or slow flow of value? What needs to change to improve the entire ecosystem?
An example. For a company that has grown multiple divisions / acquisitions over time, they might have multiple payment processing systems. Traditional EA projects might suggest simplifying each processing system to speed the internal processing where the benefit appears to be saving time internally. But a customer perspective might suggest simplifying the process for the customer so that they only see one payment system - the benefit is then reflected on teh customer in their time and good will toward the company. Oh, and it will likely improve processing time for payments inside the company as a side effect.
Cooper and Neumeyer suggest that the way EA looks at their work should change. They should be looking at the constraint, creating/promoting metrics that measure throughput, and developing EA roadmaps that embed the idea of focus.
There was a lot of discussion of DevOps and The Phoenix Project (TPP), as this has become a source book for a lot of people in IT development and operations organizations. TPP was written to mimic The Goal in structure, and it has resounded quite nicely in the IT community. One of the speakers even reminded the room of my review from five years ago when I read it. Thanks.