Enterprise architecture management, a theory of constraints, formal trade-off analysis methods and game theory
This article was submitted by Dmitri Ilkaev. Dmitri has over…
Search Results for: constraint
RBPEA: Constraints and corollaries
Enterprise-architectures should, in principle, apply to any enterprise, at any scale. But what happens when we scale our enterprise-architectures up to the ‘really-big-picture’ (RBPEA) level, with a literally global scope? What non-negotiable constraints would we hit up against? What corollaries would…
Digital Disruption: Lose the Constraints
Digital Disruption Lesson #2: Lose the constraints that restrict your thinking. This is the second in a five part series on Digital Disruption.
Greenfields, whiteboards, and blue skies; these are the ingredients of an architect’s daydreams. The so…
Back to the Future with The Theory of Constraints
In so many situations today I find business people are much more savvy with IT than they used to be only 10 years ago. And while this is a fantastic advance, the result is they are MUCH more likely to dictate the solution right from the outset. I marvel at how very senior business executives are now so conversant with the specifics of application architecture, particular packages they wish to use and Cloud deployment architecture. But of course this level of direction frequently facilitates rapid action, but without full and thorough understanding of the business issues.
We know that business people should be focused on the inherent business architecture, surfacing the opportunities for common concepts and business services, business platforms, product lines and channels; identifying where standardization and differentiation is appropriate, and where partitions are relevant, all in context with the business and market model. Get this level of architecture right and you have the chance of delivering an agile business. Get it wrong and you are in instant legacy territory!
With this interesting problem in mind I browsed my bookshelves and came across Eli Goldratt and the Theory of Constraints (ToC). There was an AH HA moment! I first came across Goldratt nearly 30 years ago; I went to one of his lectures in London and have read many of his books, but I haven’t used the ideas for a good while.
The starting point is to develop a Current Reality Tree, initially a list and then a dependency hierarchy of Undesirable Effects (UDEs) (see redacted example below). This is used to determine the root problem and then to develop a Future Reality Tree with Desired Effects (DEs). And the techniques naturally guide the user to focus on the HOW, and separate out the WHAT. In the process I insert an Ishikawa (Fishbone) diagram between the CRT and the FRT. It’s really useful in separating Domain based issues into (people, process, technology . . . ) clusters and also teasing out the root problem.
I would be interested to hear from others whether they are using ToC, or indeed if there are other techniques that do a similar job.
.
Requirements and constraints
What’s the difference between requirements and constraints? How do we identify and use them in change-projects and in enterprise architectures? This is a query that came up in my web-stats yesterday – and it should (I hope…) be one that I…
Who Owns Enterprise Architecture?
Who owns enterprise architecture? A practical look at why EA ownership matters across architecture work, deliverables, and real decisions.
You Can’t Transform What You Can’t See: Why Your Business Needs a Digital Twin
“You can think of an enterprise as a physical algorithm for creating value.”
The question of how well you understand your own enterprise has always mattered. But it has never mattered more than now. As organizations race to embed AI acro…
Internal Enterprise Architect or Enterprise Architecture Consultant?
How internal enterprise architects and EA consultants create value through different positions, access, continuity, and perspective.
How Much Enterprise Architecture Is Enough?
How much enterprise architecture is enough? Learn how to match EA effort to complexity, risk, dependencies, and decision impact.
Why AI Pilots Fail to Scale
Architectural Constraints Nobody Talks About by Nadzeya Stalbouskaya Despite heavy…
Where Enterprise Architecture Adds the Most Value
Where enterprise architecture creates the most value: strategy execution, major change, coordination, long-term decisions, and complexity.
Product Managers Are the Cool Kids Now
Key takeaways: Something has changed in how serious software organizations operate, and it isn’t getting enough airtime. The decisions that shape what ships, what gets killed, and what gets pushed are moving from project managers to product managers. As Planview’s Chief Product Officer, Louise Allen, put it at Pendomonium recently: “Product managers are the cool…