It can be invaluable to identify a set of talking points in advance when rolling out an Architecture Modeling Practice - check out our recommended ones.
A common theme when starting up a modeling practice is the need to get buy-in from stakeholders. It would be nice if all this involved was a presentation to the CEO or executive suite, but in practice there’s a constellation of stakeholders, each with varying degrees of power and skepticism. One way that you can combat fatigue and give a clear message in such circumstances is to boil down your case into a set of talking points.
Summary: When a team is rolling out a modeling initiative, it can be invaluable to identify a set of talking points in advance – why are we doing this, what do we expect to gain. These feed into both formal and informal conversations that will naturally take place. It’s a good idea to have them as small soundbite-style statements, not to quote, but to clarify the minds of the modeling team themselves.
So how can we obtain these talking points? Well, as described above, the talking points are merely there to express the motivations for the modeling activity and act as an anchor for thinking, so to derive them we need to be able to express – ‘why are we doing this?’. Now, I’m a believer in eating one’s own dogfood, so the proposal I make is to use a motivation model. A sample one is below.
We can identify several talking points from this model. For example, the first line traces from the business driver ‘Compliance with internal policies’ through to the goal of ‘Standardized, documented operating processes’ and on to the requirement ‘Map operating processes and provide access via portal’. This provides the following talking point:
“We’ve been worried about compliance with internal policies due to the new regulations coming out next year; by creating standardized, documented operating processes and then providing online access to them, we can make it easy for staff to see what is required of them.”
A second example from the lowest set of elements in the model. The business driver ‘Business service continuity and availability’ traces through to the goal of ‘Understand dependencies between systems’ and on to the requirement ‘Map applications to hardware that supports them’. This gives us the talking point:
“We’ve had concerns about continuity and availability of business services; by understanding dependencies we can identify issues much more easily, so we need to map our applications to the hardware that supports them”
As with all things, there’s an effort-reward tradeoff involved; the time to create this motivation model, and the talking points, naturally has a cost. So in cases where there’s one single stakeholder, or the buy-in is not in question, investing this level of effort is probably not going to be necessary.
But in a situation where you have multiple stakeholders with differing agendas and differing levels of support, being able to clearly articulate your case becomes much more important. In such a situation, having a set of talking points as anchors for your arguments can be an invaluable tool for persuasion.
In particular, having the multiple talking points that you can derive from a motivation model like the one that we have here, enables you to focus your message onto the specific stakeholders that you are engaging with at a particular time.