The Technology Dream
It’s just a tool, not a Strategy
It’s amazing how often technology gets confused and spun as a marketable feature. It’s not uncommon for companies and governments, for instance, to state that they will “Leverage Technology” as a business strategy. In the same breath, they’re also going to reduce unemployment, clean up the environment and fix the economy. Sure they will.
There’s an exciting appeal to ‘technology’. There’s still a mystery and newness to even the word that elicits a dreamy promise of endless possibility. It’s impressive apps like Google Earth, Halo 3 or the iPhone that people likely think of when talking about technology; apps that look good, sell well, and entice people to get lost and obsessed in them.
Sexy apps, however, are built by clever people with a focused vision around capability, content and a dreamy interface. The fact that they leverage technology is almost incidental. It’s easy to get caught up in the excitment of the dream and forget that business is still business regardless of the tool you use. The truth is, it’s not uncommon for both business people and technical people to miss the point that technology is only a tool. Without a purpose, that tool is just a means to an undefined end.
Without establishing a direction and purpose for a software product that is focused on boring old things like: User, Market and your Business; your technology dream will simply deflate into another expensive mistake rather than a hot app.
The Framework Dilemma
As technology professionals, we get caught up in the dream too. I’ve been guilty many times of approaching business problems with a technical solution without stepping back and wondering if it’s truly the right thing to do. It’s easy to get wrapped-up in the world you know and use that as the solution to all problems. “Have you considered building an Application Integration Framework?” – Those were my words. It seemed like a reasonable thing to suggest. This guy’s media company had multiple products that couldn’t talk to each other and ‘Integration’ was high on his agenda.
“NO! NO FRAMEWORKS!” – Was his response. He even stood up out of his chair and leaned forward towards me pretty aggressively when he said it.
Wo, that guy was jaded. But I understand why now. He quickly calmed himself and explained to me that a consulting company had sold him the same line a couple years ago. They spent those 2 years in, what I call, “a Dark Place”, just building a Framework. They didn’t consult with them about what the products do, or what the user needs, or business drivers, or the data or how this could tie into their overall technical strategy – nothing like that. They just built a framework. It took 2 years of nothing tangible, but these consultants were finally kicked off the property. All there was to show for the $1.2 million spent was a bunch of code that had no business value. I’m sure it was a brilliantly designed framework, but it didn’t do anything. I’m also sure there are thousands of skillfully composed frameworks out there sitting lonely on subversion servers around the world. I’ve personally participated in a framework or two that went nowhere. It’s a common thing for developers to want to do.
I don’t want to dismiss the importance of a proper architecture and framework; all software applications need a solid foundation. But they have to be built to fit the business need, and with a specific user-driven purpose. Frameworks should be small, lightweight and grow with the product. Key to making sure that happens is: every aspect of a framework has to have a consumer. If someone on your team is building a component or framework or utility in anticipation of the potential of it being useful, that effort should be denied.
Technology For Technology Sake
My old boss used to have this tendency to wander into my office and recount stories about his past. He didn’t have all that much material, so his stories got repeated a fair bit – I didn’t have the heart to tell him that of course. Anyway, one of his more riveting stories I got to know well, was about the specifics of a product idea of his that failed. It was essentially like this: a data service architecture that could connect to multiple databases; a domain layer that sat on top of that which reconciled data from these different locations; on top of that was a communication layer based on web services and finally there was a forms builder to create custom interfaces as the top layer of the product. He thought it was such a great idea and would shake his head in bewilderment as to why it never went anywhere. “Well, what did it do?” I asked him one brave day. “It could connect to multiple databases.” Was his answer.
“To do what though?” I asked.
“Well, to do anything.” He said.
“Anything that needs multiple databases…” I said, to be agreeable; but really I just wanted to get out of the conversation.
So, who’s going to buy that? It’s a thing that doesn’t have any real purpose, except to say it serves a purpose behind an unknown purpose. A body without a head. I didn’t have the heart to tell him, of course, because he thought it was so awesome … and it was kind of his baby. But like a lot of people, he chose to build technology for technology sake, and didn’t appear to understand that that isn’t a product or strategy, it’s only a tool.