At about 30 minutes, Mr. Long talks about having control within our own system, but needing to make it easy for different external players by (what I take as) subscribing to their interfaces and building our system to those needs/requirements/specs. I'm having difficulty determining where the reciprocity occurs therein. If they change their interface, or outward facing stuff, we will likely need to change our interface that faces them. Why should they not change for us? Of course we want to be successful and maybe turn that other cheak. But wouldn't a healthy level of Quid Pro Quo be desireable? How do we go about designing systems that, under the worse circumstances, don't force stagnation because of inflexiblity at the interfaces?
In fresh design, interfaces are certainly up for negotiation between subsystems and teams. When re-engineering a system, we must either comply with existing interfaces or make an additional investment to change an interface. In the context of trying to deploy MBSE (which is re-engineering the engineering system as we seek to change the processes and systems in use), the objective is to bound the change. If when deploying a new process, we change the interface to others - either in the content provided or in the format - we include them inside the change boundary. If those impacted see the value of the change and are consulted as part of the change process, they may support the change or at least be neutral. All too often, this isn't the case and we accidentally "inflict" our change on others. If they are not engaged in the change process and don't see the benefit, they resist. Too much resistance will kill any change initiative no matter how good the change is. So when introducing a change - particularly one like MBSE which deals with how we represent, manage, and analyze information - the challenge is to draw the change boundary large enough to contain the change agents and deliver benefits while remaining small enough to avoid triggering too much resistance. The boundary can then be slowly expanded.
At about 30 minutes, Mr. Long talks about having control within our own system, but needing to make it easy for different external players by (what I take as) subscribing to their interfaces and building our system to those needs/requirements/specs. I'm having difficulty determining where the reciprocity occurs therein. If they change their interface, or outward facing stuff, we will likely need to change our interface that faces them. Why should they not change for us? Of course we want to be successful and maybe turn that other cheak. But wouldn't a healthy level of Quid Pro Quo be desireable? How do we go about designing systems that, under the worse circumstances, don't force stagnation because of inflexiblity at the interfaces?
In fresh design, interfaces are certainly up for negotiation between subsystems and teams. When re-engineering a system, we must either comply with existing interfaces or make an additional investment to change an interface. In the context of trying to deploy MBSE (which is re-engineering the engineering system as we seek to change the processes and systems in use), the objective is to bound the change. If when deploying a new process, we change the interface to others - either in the content provided or in the format - we include them inside the change boundary. If those impacted see the value of the change and are consulted as part of the change process, they may support the change or at least be neutral. All too often, this isn't the case and we accidentally "inflict" our change on others. If they are not engaged in the change process and don't see the benefit, they resist. Too much resistance will kill any change initiative no matter how good the change is. So when introducing a change - particularly one like MBSE which deals with how we represent, manage, and analyze information - the challenge is to draw the change boundary large enough to contain the change agents and deliver benefits while remaining small enough to avoid triggering too much resistance. The boundary can then be slowly expanded.
That's very helpful and great to hear, thank you Mr. Long!