By Brian Dayton on April 8, 2010 9:27 PM
"Standards save money."
"Standards accelerate projects."
"Standards make better solutions."
What do these statements mean to you? You buy technology solutions like Oracle Applications but you're a business person--trying to close the quarter, get performance reviews processed, negotiate a new sourcing contract, etc.
When "standards" come up in presentations and discussions do you:
- Nod your head politely
- Tune out and check your smart phone
- Turn to your IT counterpart and say "Bob's all over this standards thing, right Bob?"
Here's why standards matter. My wife wants new external doors downstairs, ones that would get more light into the rooms. Am I OK with that? "Uhh, sure...it's a little dark in the kitchen."
- 24 hours ago - wife calls to tell me that she's going to the hardware store and may look at doors
- 20 hours ago - wife pulls into driveway, informs me that two doors are in the back of her station wagon, ready for me to carry
- 19 hours ago - I re-discovered the fact that it's not fun to carry a solid wood door by myself
- 5 hours ago - Local handyman, who was at our house anyway, tells me that the doors we bought will likely cost 2-3x the material cost in installation time and labor...the doors are standard but our doorways aren't
We could have done more research. I could be more handy. Sure. But the fact is, my 1951 house wasn't built with me in mind. They built what worked and called it a day.
The same holds true with a lot of business applications. They were designed and architected for one-time use with one use-case in mind. Today's business climate is different. If you're going to use your processes and technology to differentiate your business you should have at least a working knowledge of:
- How standards can benefit your business
- Your IT organization's philosophy around standards
- Your vendor's track-record around standards...and watch for those who pay lip-service to standards but don't follow through
The rallying cry in most IT organizations today is "learn more about the business, drop the acronyms." I'm not advocating that you go out and learn how to code in Java. But I do believe it will help your business and your decision-making process if you meet IT ½...even ¼ of the way there.
Epilogue: The door project has been put on hold and yours truly has to return the doors to the hardware store tomorrow.
