About Me

My photo
Scott Arnett is an Information Technology & Security Professional Executive with over 30 years experience in IT. Scott has worked in various industries such as health care, insurance, manufacturing, broadcast, printing, and consulting and in enterprises ranging in size from $50M to $20B in revenue. Scott’s experience encompasses the following areas of specialization: Leadership, Strategy, Architecture, Business Partnership & Acumen, Process Management, Infrastructure and Security. With his broad understanding of technology and his ability to communicate successfully with both Executives and Technical Specialists, Scott has been consistently recognized as someone who not only can "Connect the Dots", but who can also create a workable solution. Scott is equally comfortable playing technical, project management/leadership and organizational leadership roles through experience gained throughout his career. Scott has previously acted in the role of CIO, CTO, and VP of IT, successfully built 9 data centers across the country, and is expert in understanding ITIL, PCI Compliance, SOX, HIPAA, FERPA, FRCP and COBIT.

Friday, February 25, 2011

New Application? WAIT - We are not ready!

New applications in the enterprise needs to be a structured event.  Remember in years gone by, you would have the business say we want application XYZ and you would go buy it, stick it on a server and let them use it.  IT would just deal with the logistics and support around that application as part of the job.  Does that really work anymore? 

New applications need a little more structure, as you have key issues to address now, and that has to be right up front before implementation.  Key issues such as compliance, data classification, archive strategy, security, DR and interfaces.  Many organizations have gone to a checklist tool that is used as part of the new application project.  It is essential that this information is collected right up front, and entered into the application inventory. 

I had a colleague ask, what is the big deal, just deal with it as needed.  So let's look at that view, and see what some of the impacts are.  Take archive strategy - should be defined right up front.  This key item will assist in storage requirements, application hardware performance, compliance, and DR requirements.  If you have say SAP growing over years, and you don't archive on a regular basis, you can have the following issues: 
  • Storage demands continue to grow year over year.  Adding to data center costs.
  • Application server performance decreases as the data continues to grow.
  • DR RTO/RPO requirements change as the data becomes unmanageable
  • You have data beyond retention policy(s)
I propose to you that part of the application project define process is to address data requirements, technical requirements, user requirements.  You need the complete picture and direction before the application is in production.  It is to difficult to go after some of these issues after the fact.  In addition, as years go by, and staff changes, user staff changes, it becomes difficult to recall the details of the application.  Document it up front and you can move this application through it's lifecycle with ease and efficiency. 

Keep it positive.

Scott Arnett
scott.arnett@charter.net

No comments:

Post a Comment