Trusted advisers
Architects should be involved in technology decisions
If you take a look at most organisations, it's fairly obvious that technology is there to support the business - it's there to enable new business, make existing business more efficient, reduce costs and so on. With technology taking on this subservient role, it should come as no surprise that "the business" is often lured head-first into new technology because of the "business benefit" that it offers. Sometimes this is coupled with fancy marketing, a visit to the golf course, champagne on a yacht, tickets to an international rugby game or whatever. It's all very appealing, but unfortunately technology purchases aren't that straightforward and you shouldn't always believe the hype.
As technologists, it seems to be a fairly common occurrence to find ourselves stuck with a technology that we didn't choose or don't like. Worse still, we could find ourselves stuck with a technology that simply isn't fit for purpose, despite what it says in the glossy marketing material. Case in point - a city organisation has bought into a technology that will help deliver real-time streaming market data to their clients anywhere on the Internet. Sounds fantastic, until you look under the hood. In this particular instance, the system in question doesn't actually do any streaming (it polls for new data once a second) and the vendor company doesn't know what the performance/scalability limits of the system are. Having briefly looked at the implementation myself, I was able to come up with about a dozen *basic* questions that I couldn't find answers to. I can also think of numerous times where I've seen a project trying to cram some functionality into a product that it simply wasn't designed to do.
I'm more than happy to let the business take the lead and define their technology requirements, but it's *essential* that they involve technologists in any technology decisions they want to make. Early involvement from technologists could really save a massive amount of money and prevent the wrong technology from being purchased. It could also prevent technologists feeling isolated and resenting the organisation in which they work.
The problem many organisations have is that they don't know who to turn to for advice in helping them make these sorts of purchasing decisions. I'd like to offer a solution to this - experienced technical architects are able to fulfil this role because they have a good understanding of the business and a good understanding of what technology needs to do in order to support the business. Also, technical architects are well placed to ask those "tricky" questions, such as "what technologies does this use under the hood?", "how exactly are you doing that?" and "how do you support high availability?".
I've performed this role many times in the past and it's provided valuable insight that has either strengthened or weakened a purchasing decision. It works both ways and is equally applicable regardless of whether you're looking to purchase a single technology, and entire stack or even acquire another organisation. With a broad ranging yet technically deep skill-set, technical architects have the ability to make excellent trusted advisers.
Re: Trusted advisers
This sort of problem also seems to arise from making these decisions at the wrong point in the project lifecycle, ie too early. This will lead to the wrong people being involved (although I wouldn't describe myself as being the "right" person for a trip to the golf course).
Worse still, I've experienced the project sponsors disregard the architect's advice on product selection, siding with the supplier and company providing the implementation. This has proven to be catastrophic, with the architecture team effectively abandoning the application (citing the "I told you so" defence). This has been compounded by the architect's fears about the product selection being realised (product is at end of life, there is no readily-available technical expertise, problems reconciliing multiple sources for the same data, failing to scale with the business ...).
And it's not just shortcomings in the product that the architect needs to pick up. The environment that the product will be used in (skills, infrastructure etc. available) should also sway the product selection. After all, the vendor is not accountable for your company's problems.
