Balance in Corporate IT

I like to think I have a unique perspective when it comes to the IT world. My roots were firmly planted in small business which is usually a bit off the bleeding edge, but nimble…agile. I spent a year or so as a business owner and got to live the life of a grand decision maker when it was my money on the line. I also have been at both ends of the spectrum in corporate America..medium and huge. I have spent time as a developer, I have spent time as an architect, and I have spent time at a director level.

All things considered I think I have a good idea of the grand perspective and want to drop a few pearls of IT Wisdom that I have learned over the years.

Never Forget Your Customer
This is so easy to do. There are two types of customers when you live in IT. There are the external customers, those buying your company’s products. There are also the business users that you are designing and maintaining internal business critical systems for.

The external customer wants two basic things. A simple transaction at a fair price. If your user experience is poor, your profits will suffer. If your price isn’t a value, your profits will suffer. Simple stuff, right?

The business customer seems so much more complex, but in reality it can be viewed along the same paradigm. If your user experience is poor, they will slowly adopt your solution..if at all. If your tool doesn’t accomplish it’s task in a timely and simple matter, your users will reject or misuse your tool.

We all know IT moves fast. We all want systems with a long lifespan. The only compromise is to build your systems in a way that allow you to keep the expensive infrastructure in tact while allowing you to modify the systems you interface with and the business logic you rely on in a timely fashion.

The real thing to consider is that your user is your real requirements analyst. They may not be the people who document and carry the solution through your chosen project methodology, but they are the true drive to your project. This focus is unfortunately too often lost. That leads me to my next pearl…

Do Not Get Attached to Technology
There are a lot of evangelists for every technology you can bring to mind. I can find a conference full of people that will tell you why one product is better than the other. I am sure I can find another conference full of people for the alternate technology who would be willing to pick up torches and pitch forks to lynch the same people who advocated the alternative. The point is every technology has strengths and weaknesses. Anyone who tells you that there is one solution that is clearly better than the other is selling you a dream.

We all want the one perfect solution, but middleware is never that simple. Being in the midst of a middleware decision waiting game myself, I can only say that I do not fear the choices being made, I only hope they are informed and fairly chosen based on merit, fiscal responsibility and not personal affinity for a particular platform.

It’s amazing to me that a large company could stand at the crossroads of infrastructure choices, ready to write multi-million dollar checks, and not consider all of the options.

I have seen officer level leadership walk into a fortune 500 size corporation and change the entire IT strategy and platform choices because of a personal preference of one solution over the other. I know I am being a little vague here, but disclosure can be a real pain.

I know I am being clear enough that those who need to understand this article, follow me clearly.

Parting Notes
My final pearl is really more advice than anything. When you are tasked to a new project, especially one that has lived previous to your inclusion, take in all of the information that you can, and then erase the whiteboard. Get all of the brilliant minds you can get into the room and ask this simple question: “If this was a new system, in a new enterprise, how would you do it?” Take all of the advice to heart, balance it against your existing infrastructure, enterprise initiatives, and yes, even the preferences of your development team. Find a happy medium that meets your desired conclusion, stays comfortably enough within your corporate guidelines, and accomplishes the task to the best outcome of the final customer.  Do not build your project based on existing biases and bureaucratic shortcomings in existing systems. Find the solution that fits best and let upper management do what they do best…break barriers between poorly communicating teams.

Last and most important, do not be afraid to ask why, and chase that dog until you have an answer. Many projects fail or are poorly architected because someone said something no one questioned.

Submit this post to

• No Related Post