Decisions, Decisions

The art, science, and politics of technology selection

By Bob Rhubart

September/October 2012

When the time comes for a solution architect to make the final decision about the technologies, standards, and other elements that are to be incorporated into a particular project, what factors weigh most heavily on that decision? It comes as no surprise that among the architects I contacted, business needs top the list.

Philip Wik, a senior consultant at MSS Technologies, stresses the importance of clearly stated and well-understood business goals when addressing technology considerations. “Don’t put the technology cart before the business horse,” he advises.

“It’s cool to talk about Web services, REST, EDA [electronic design automation], clouds, and so on,” says Wik. “But can I suggest a time-out? Let’s table a discussion of implementation technologies until we clearly know what we’re going to implement and why. We need to first know where our business is going and what it needs to meet the demands of the marketplace.”

Oracle ACE Director Basheer Khan, an IT architect who is founder, president, and CEO at Innowave Technology, places a similar importance on meeting business needs. “No matter how great a specific technology is or how well defined a particular standard is, if it does not have the right price-performance ratio for the business, I reject it.”

While price is an important consideration, making technology decisions based solely on price can have dire consequences. “We must weigh the cost in terms of value that can be delivered, rather than selecting a technology that is merely the least expensive,” says Wik. “A less-expensive technology that can’t support an organization’s architectural principles is unlikely to meet its business goals.

Meeting those goals is key, but practical realities within the organization regarding budget and technical resources may pose challenges to meeting specific business requirements. Aki Iskhandar, system architect at Lambda Software, says solution architects must draw on their domain expertise and knowledge of those realities when making technology decisions.

“Solution architects must use their experience to balance resources and constraints in an effort to recommend an architecture that ensures a successful solution for the project at hand,” says Iskhandar, “delivering on as many of the business requirements as possible, while pushing back on the ones that make no sense.”

In some cases, however, technology options may be limited. In others, solution architects may have only limited input in any technology decisions.

“Larger organizations with fairly mature enterprise architecture programs may have rigid vendor lists, which impact the possible selection of tools and software packages,” says Iskhandar. “The business should get what it wants, but it would be nice if they would run it past IT first. That almost never happens.”

But keeping IT out of the technology selection loop may not be such a bad thing, at least according to Wik. “Those who should be making these decisions shouldn’t be the implementers, but rather business and marketing managers who are most involved in profit and loss questions and business growth,” says Wik. “The functional team rather than information technology should drive the technology selection process.”

Welcome to the world of architectural politics.

“A solution architect’s job typically involves blending art and science in connecting the dots across several broad landscapes,” says Oracle ACE Director Ron Batra, director of cloud computing at AT&T. “Things often get fuzzy in trying to please multiple stakeholders.”

Solution roadmaps can help to eliminate some of that fuzziness. “But more often than not, a business process or technology roadmap serves only as a guideline,” Batra says. “Then it’s the job of the solution architect to fill in the gaps within the guidelines.”

Making those gap-filling decisions requires skills beyond the technical. “Solution architects have to sell the solution,” says Batra, “and it is not always possible to keep everyone happy. This is where the soft skills—selling, persuasion, negotiation, communication—show their worth.”

For solution architects, that’s business as usual.

Next Steps

 GET more architect information

 LISTEN to ArchBeat podcasts

 Bob Rhubart's Blog
 Bob Rhubart on Facebook
 Bob Rhubart on Twitter
 Bob Rhubart on LinkedIn