By
Michael Mynott, on September 25th, 2009, Click here for more posts by
Michael MynottAs technologists is very easy to get caught up in the hype and grandeur of delivering “really cool stuff”. I mean it is not hard in today’s environment to quickly and easily stand-up complex solutions based on open source or commercial technologies. You want a VoIP solution – Asterisk can be downloaded and running within hours. SSL VPN – pick a firewall vendor they all perform it at some level.
The problem that we as technologists face is to remember “who is driving who”, the business should be driving the technology, not the other way around. Technology should be used to solve business problems, if it does not address a particular business issue then it is usually just “a really cool thing to do”.
Other considerations that are typically ignored by “really cool projects” are;
Business Requirements
What is trying to be achieved?
What does the solution have to do to be deemed a success in the eyes of the business?
The Bigger Picture
If this is done here what is the impact over there?
Does the solution fit with other vendor equipment in the environment?
Impact on operational resources – is upskilling/training required?
Does it fit with our architecture? (prerequisite question – Do we have an architecture?)
What are the security implications?
Documentation
Design– The solution should be designed and not made up on the fly as we go along
Implementation Planning – Good documentation around how to implement the solution and migrate to it is invaluable. It makes one think through the process and uncovers the catches – hopefully
Handover – The solution will probably live beyond the implementer so clear concise documentation is required in order to be able to maintain the solution
The technology is more important than the business – yeah right!
As technologists is very easy to get caught up in the hype and grandeur of delivering “really cool stuff”. I mean it is not hard in today’s environment to quickly and easily stand-up complex solutions based on open source or commercial technologies. You want a VoIP solution – Asterisk can be downloaded and running within hours. SSL VPN – pick a firewall vendor they all perform it at some level.
The problem that we as technologists face is to remember “who is driving who”, the business should be driving the technology, not the other way around. Technology should be used to solve business problems, if it does not address a particular business issue then it is usually just “a really cool thing to do”.
Other considerations that are typically ignored by “really cool projects” are;
Business Requirements
What is trying to be achieved?
What does the solution have to do to be deemed a success in the eyes of the business?
The Bigger Picture
If this is done here what is the impact over there?
Does the solution fit with other vendor equipment in the environment?
Impact on operational resources – is upskilling/training required?
Does it fit with our architecture? (prerequisite question – Do we have an architecture?)
What are the security implications?
Documentation
Design– The solution should be designed and not made up on the fly as we go along
Implementation Planning – Good documentation around how to implement the solution and migrate to it is invaluable. It makes one think through the process and uncovers the catches – hopefully
Handover – The solution will probably live beyond the implementer so clear concise documentation is required in order to be able to maintain the solution