I’ve been taking about Enterprise Architects (EAs) providing solution options vs just one recommendation all week. When presenting these options and the recommendation they need to be expressed in business not technical terms. There are two main reasons:
We are making a business decision (the technical architecture is just one component for decision making)
No one will challenge your technical choices unless this was a software selection recommendation
When presenting the business case you always have two types of pros and cons. One type is a Tangible pro or con and the other type is an Intangible pro or con. Tangible pros and cons can be expressed in financial terms ($s, ROI, Payback period, …) and intangible pros and cons are ones you haver to express in words because you can’t or your accountant don’t let you turn them into financial terms. E.g. system availability is 99.9% in one scenario and 99% in the other scenario. 99.9% is obviously better but it might be hard to translate what the difference means in terms of $s.
Most people will argue that you should try as hard as you can to come up with a Tangible vs an Intangible. I agree but am a bit torn as you don’t want to quantify something that you really have no idea how to attach a Dollar amount to or you might be way off. As this all happens in the proposal phase we want to be careful how accurate we think we are and thus it might be better to always give a range.
Intangibles can be very important and should be discussed in the decision making. For that purpose highlight the ones that really could sway the decision vs listing a laundry list of intangible comments. Some Intangibles could easily be no debate that eliminate a certain option. I called those Fatal Flaws in my last blog. As Chief Architect, think about which architecture principles you want to align with the CIO and the business that should simply never be broken. For example, dual factor authentication is always required or any data being pushed into the enterprise data lake is raw, untransformed data. Or in the availability example I gave above, you could have a principle that all customer facing applications are always 99.99% available.
I actually love the idea of having a good number of principles that are no debates. This forces high quality and prevents you from building up technical debt that for some reason often is never fixed.