Okay - own up, infosec engineers - do you train in the business process and understand the relevance of business need for survival?
Most of the engineering I have seen seems to have little relevance to or understanding of ground reality - is this endemic? For example - Risk Management and Information Security will spend days closeted with security vendors and their offered toys - and come up with new designs centered on their toys of choice for the *new and improved* infrastructure security model – with little to scant attention paid to how this will translate to reality. There is little indication for a proper upgrade/replacement path, no attention to forward facing support structures, no explanation for ROI and scant information on what to do with the current setup in place or why it is no longer good enough.
Would this explain the lack of respect for most IT and IS outfits in business circles? Would this be a reason businesses tend to treat IT as an exotic toy that can enable business, but can be dropped like hot potatoes at the first sign of financial distress? Are we responsible for our lack of appreciation of digital information handling as a true business enabler instead of just another tool?
If those are the questions, here are some suggestionsJ!
1) Involve business and production support in the requirements gathering and the design process from the beginning.
2) Understand the business drivers that are funding the current infrastructure, and relate the change and its cost to these drivers. A solution that costs more that the expected return will end up in the gutter every time!
3) Understand at least the basic accounting principles that the firm uses – depreciation, asset classes and expense classification are good starters. Use these to present the offering in language that the bean counters will understand (and do not look down on them – they are the ones that been the business moving forward on the financial path even as marketing and sales do their own wonders – this is the grease that smoothens the path after all – and no money = no job pretty soon!)
4) Understand compliance needs. The latest security gadget might not fit after all if the logging schema requires a full redesign to accommodate compliance and audit requirements.
5) Support – can the new stuff all be supported once in? What is the associated cost there? Do the support teams need training? When will this happen? Can the shifts all have proper representation at training while still manning the fort? What is the escalation process? Who is responsible for design updates after the product is in production? Will engineering offer sufficient support for the teething period in the initial production days? How will this commitment affect other engineering work?
Okay – all questions are answered to everyone’s satisfaction, and the project is ready for rollout. Now for the BIG question – is it still required?
No comments:
Post a Comment