The bi-modal nature of EA makes the exercise difficult without a predefined motivational model. The shown post it’s can then be adhered to the components of the value proposition proposed by the organizations executives and ensure that any communications for programme or project initiations are assessed as to their ability to meet the customer value proposition.
Strong agree about the need to link to an identified motivation/values-model on one side and to clear value-proposition(s) on the other.
To some extent, though, that isn't what this post is about. The _content_ for the Post-Its in the photo wasn't relevant as such - they could have been about ice-cream or school-curriculum or whatever. The post was more about the _processes_ we use to reach towards consensus - and the need for consensus itself.
Hi Tom, my comment was as you mention about the process where it would appear that consensus was being achieved on the “what” rather than the “why” which in turn would provide guidance to the what, if we cannot agree on the why, then the what becomes irrelevant in the context of consensus moving forward. Hope that clarifies my post.
"if we cannot agree on the why, then the what becomes irrelevant" - yep, definitely. Which kinda makes it interesting that most of the current EA frameworks barely even glance at the 'why' at all, and Business Motivation Model places Mission (literally, a 'sending' - with its implication that the _sender's_ 'why' is imposed as a non-discussable imperative onto others...) as the top of of the motivation-tree. Hmm...
Thanks, Michael. Quick summary for what I would have proposed but was well aware was 'a bridge too far' at the moment: making the architecture approaches fully fractal at every scale and timescale, not just the current business-ish realm with its still very short-timescales, but right down to sub-microsecond and all the way out to centuries and millennia, and down to single person 'organisations' (though there was some acceptance of that) all the way out to the entire planet or even beyond. If the context-neutral parts of the methods we use _are_ fully fractal, they should be able to tackle those kinds of scales - or, conversely, use those extremes of scale and timescale as edge-cases to test just how fractal our methods actually are.
(One aspect of that aligns exactly with a core theme here at Small Changes: that if the methods are fully fractal, we can practice at the smaller or mid-range scales and timescales to build skills and experience to get ready for tackling the larger / more-daunting challenges when they arrive.)
What _didn't_ fall short was that we were properly talking about a literal 'architecture of the enterprise': not just the IT (as is still far too much the case in so much so-calle 'enterpris'-architecture...), but _everything_ in the enterprise context, people, machines and more.
What I felt still fell short was as above: what was proposed still didn't fully match up to what I believe is an absolutely essential requirement, that the overall methods must be able to work in essentially the same way at every scope and scale, with every type of content or context, every stage of the change-lifecycle and entity-lifecycle, and also at every timescale. If we don't have that, we will inevitably cause architecture-fragmentation - otherwise known as Not A Good Idea...
The bi-modal nature of EA makes the exercise difficult without a predefined motivational model. The shown post it’s can then be adhered to the components of the value proposition proposed by the organizations executives and ensure that any communications for programme or project initiations are assessed as to their ability to meet the customer value proposition.
Strong agree about the need to link to an identified motivation/values-model on one side and to clear value-proposition(s) on the other.
To some extent, though, that isn't what this post is about. The _content_ for the Post-Its in the photo wasn't relevant as such - they could have been about ice-cream or school-curriculum or whatever. The post was more about the _processes_ we use to reach towards consensus - and the need for consensus itself.
Hi Tom, my comment was as you mention about the process where it would appear that consensus was being achieved on the “what” rather than the “why” which in turn would provide guidance to the what, if we cannot agree on the why, then the what becomes irrelevant in the context of consensus moving forward. Hope that clarifies my post.
"if we cannot agree on the why, then the what becomes irrelevant" - yep, definitely. Which kinda makes it interesting that most of the current EA frameworks barely even glance at the 'why' at all, and Business Motivation Model places Mission (literally, a 'sending' - with its implication that the _sender's_ 'why' is imposed as a non-discussable imperative onto others...) as the top of of the motivation-tree. Hmm...
I’d love to know what you suggested that was too far Tom and also what was proposed that fell short
Thanks, Michael. Quick summary for what I would have proposed but was well aware was 'a bridge too far' at the moment: making the architecture approaches fully fractal at every scale and timescale, not just the current business-ish realm with its still very short-timescales, but right down to sub-microsecond and all the way out to centuries and millennia, and down to single person 'organisations' (though there was some acceptance of that) all the way out to the entire planet or even beyond. If the context-neutral parts of the methods we use _are_ fully fractal, they should be able to tackle those kinds of scales - or, conversely, use those extremes of scale and timescale as edge-cases to test just how fractal our methods actually are.
(One aspect of that aligns exactly with a core theme here at Small Changes: that if the methods are fully fractal, we can practice at the smaller or mid-range scales and timescales to build skills and experience to get ready for tackling the larger / more-daunting challenges when they arrive.)
What _didn't_ fall short was that we were properly talking about a literal 'architecture of the enterprise': not just the IT (as is still far too much the case in so much so-calle 'enterpris'-architecture...), but _everything_ in the enterprise context, people, machines and more.
What I felt still fell short was as above: what was proposed still didn't fully match up to what I believe is an absolutely essential requirement, that the overall methods must be able to work in essentially the same way at every scope and scale, with every type of content or context, every stage of the change-lifecycle and entity-lifecycle, and also at every timescale. If we don't have that, we will inevitably cause architecture-fragmentation - otherwise known as Not A Good Idea...
I hope that makes sense, anyway?