A while back I read this post and it got me thinking about how we design solutions - an activity that architecture is a [big] subset of. On the one hand we're after the ideal answer to the business problem but on the other hand we've got to be able to actually deliver it, extend it in the future and support it too.
The guys on codingthearchitecture were talking more about their own personal experiences transitioning from lead developer to formally designated architect but I think the fundamental continuum implied in the discussion - that line with "what we're best at" at one extreme and "what's best for this requirement" at the other - is worthy of some management attention.
If you examine the "what we're best at" extreme you find there are some advantages to designing solutions in that space; you'll typically have higher quality software, the project will be quick and operationally you'll have a lot of nice, peaceful nights sleep running technology you're already tooled and trained to support. The downside here is that if you always limit yourself to the hammer every problem is a nail. You'll end up with a whole lot of products that are done very well but quite plain and indistinguishable (where's the real USP's?) and you're likely to spend far too much on some projects and not quite enough on others - because if everything follows the same basic pattern/technology set then you need to size that for your biggest, baddest problem.
At the "what's best for this requirement" end of the spectrum you'll end up tailoring the most appropriate, specific solutions to every business problem and when your technology is your product that creates the most competitive advantage. It also allows you to really capitalize on the creativity and innovation you have locked away in those engineers and that will in turn keep the team growing, developing and improving - your customers will see benefits from this as your execution of new technology improves. The principal downside here is risk - you'll occasionally be stepping out into complete unknowns that won't always work out. And your project is likely to take a little longer to get done if engineers need to do some on-the-fly learning.
So which one is right?
I think the answer here is balance. Per-project you should find an optimum point along that continuum - sometimes you'll be able to take a little more risk, push the team forward a bit and try something new and other times you'll need to fall back on today's expertise to get something to market quickly or guarantee an SLA.
As management you should enable your engineers to make these decisions and encourage them to lean towards the side that's most beneficial to your organization. Ask yourself whether creativity or commodity is more valuable to you; whether innovation or stability will give you more of a competitive advantage.
Mmmmm, so I'm thinking it'd be nice to track those decisions on balance cos it might give a useful indication of what the trend looks like over time.
You'd have a sense of whether you were erring on the safe or the risk'y and be able to tweak accordingly.
Probably tell you a lot about the overall state of your systems architecture too.
Post a Comment