The Luddite’s Dilemma

The business shouldn't be in the tool business. And for IT, when you come to believe that a solution is a tool, or when you buy into a situation where the business has purchased a "solution" in the form of a tool, then it is time to hand in your enterprise architect credentials.

I Am Not a Luddite…

I have a technical background. I was raised in an era of rapid technological change. I’ve worked in IT my entire career. I’ve come to see technology as part of my life and let’s be honest, IT has paid the bills for years.  There has been no period in human history more exciting to be alive, richer in opportunity, dynamic with incredible change than the past 30 years. The pace of change due to technological innovation has been breathtaking. I expect it will continue for decades to come.

The tools at our disposal today, not as rocket scientists or laboratory researchers but as average people, are diverse and powerful. Today’s commonplace tools were science fiction within recent memory. If you step back and think of the power and convenience of the tools at our disposal today, it is astounding.

I’m a technology everyman. I love tools and I eagerly use them and champion them in my work. Anything that can automate a task or a process or make life easier or more streamlined is an absolute godsend and enables our society’s productivity advances. Technical tools are critical to the workings of business in the modern era.

 

...And I Love My Technology…

As an architect, I sometime deal with the abstract. Taking something as nebulous as a business idea or business problem and attempting to realize it or solve it can be difficult. As I’ve indicated before, getting lost in the details is certain death. Taking abstraction to concrete solution is not always easy or possible. But it becomes a whole heck of a lot easier with good tools at your disposal. For instance, resolving a claims workflow issue is naturally easier when you have a BPM suite at your fingertips. Could you imagine solving that problem purely with paper? Well I shouldn’t say that, I’ve been places where they actually did that very thing. But the point remains that our IT tools enable us in previously unthinkable ways. IT Architects really couldn’t solve modern problems without the software in the corporate inventory.

Or could they?

 

…But Sometimes It Makes Me Itch

I have to confess that I sometimes tell those who seek my advice that I really can’t help them. The business unit that purchases a software tool before engaging with an Enterprise Architect is breaking several cardinal rules. But the first one is that they don’t understand the role of technology. How could they? Why should they? They’re the business after all. Frankly they shouldn’t be knowing or caring about technology at all. It is their role to operate their business processes and identify potential problems or areas for improvement. It becomes the architect’s job to help marry their problems with technical services to solve those problems. The business shouldn’t be in the tool business.

But in reality they often are. And when they are, very often they have bought the tool before they understand the problem they have. They have bought the tool before knowing why they need the tool. That is when it behooves the self-preserving Enterprise Architect to gracefully back out of the entire affair. You see, tools are the bane of the EA. When you come to believe that a solution is a tool, or when you buy into a situation where the business has purchased a “solution” in the form of a tool, then it is time to hand in your enterprise architect credentials.

Tools make me itch as if I’m having an allergic reaction. The many vendors I’ve dealt with over the years, over many beers and cigars, will no doubt be upset. Although the ones who know me well already know this. An EA has to be tool agnostic, vendor agnostic, technology agnostic. Because at the end of the day, being an EA isn’t about the tool or the product. It is about helping the business understand their problem and putting together the right way to solve that problem. If you’re so enamored with how you were treated at the last IBM Inner Circle event that you think WebSphere Portal is the solution for all UI/Enterprise App situations everywhere, you might as well go home. If you are so lost in your tool world that you come to see that tool as the answer to every problem, even before you know the problem, then you are no longer an enterprise architect and in fact become part of the problem.

Hang up your hat, bubba, yer done.

 

But Then, I Could Always Be Wrong

Am I being too simplistic? Are there situations where architects (specifically enterprise architects) really need to be deep in with a vendor or tool provider? Does it become dangerous to be too big picture or too high level? What is the appropriate mix in your opinion?