Transitioning from CIO to CEO has been an interesting move for me. This is not my first time as a CEO, but my role as CEO of Vigilant was short, and Vigilant was an IT services company, so it was still chief of IT services. However, as much as I dog on ITIL, CObIT and other industry frameworks for being too esoteric and vague, I always have appreciated and applauded the principles and intents. As SMAK has launched from thought to design to code to hardware, my experiences and training in lifecycly management has served me well. Our Strategy phase quickly incorporated what our resources and capabilities could be, would be, and should be. Since I have the unique opportunity to start this IT operations from scratch, I wanted to get our LifeCycle management clear and correct from the start.Just because we are a lean startup doesn't mean we need to run in chaos. I certainly am not going to cast all hard lessons learned in the trash. I know that if a disparate development team is not given a solid and stable platform for code migration, our IT ops will be a mess. My ITIL students and past clients have heard this expression a million times from me. If you want to cleanse the pond, you must clean the streams that feed it. In other words, if you want a clean IT operations platform, you must have solids standards and architectures in place for all involved to work from. Breaking down the DEV/QA/UAT/Prod barriers is a challenge. Typically it is based on rights and security. Access control can be a nightmare and causes much of this angst. By setting up boundaries and protocols up-front, the streams will stay clean and the pond will be a source of value.
So here is my strategy straight out of SMAKs operation guide on how I plan to allow autonomy and control co-exist.
User Setup and Configuration:
To secure the environment we will utilize a strategy of layered access to systems. Each environment will utilize the same set of layers with a name denoting their environment.
To gain physical access to systems (keyboard, SSH, Remote windows) there will be a user created.Once physical access is gained you will need to change user or run-as a user with rights to access either system settings / application data (php, xml files / database settings / database information.
Access controls are organized in to functional groups based on assetts. Asset types fall into 5 categories:
Production – Production environment with real users and customers. Needs to exhibit high service warranty.
Demo – Production+ build version of our site with fake data that we will use for demonstration at events, webinars, and other marketing events. (Production+ means at least production vesion with potentially new features to demonstrate functionality)
UAT – User Acceptance Testing Environment– QA Build version signed off on by production release team for Security; Availability; Performance testing. Now awaiting user interaction; regression; usability and design; product marketing sign off.
QA – Quality Assurance Environment – Build version that has been signed off by development team and gone through integration testing. Testing in this environment will focus on Functionality; Security; Performance; Availability; Installation; Recovery. Training to production release team will happen at this build stage. Sign off by Product Management.
Dev – Development Environment – Dynamic build versions be created in this environment with 2 core focus areas
- InnoDev - New product development focused on publishing new feature sets and requirements from Product Marketing team.
- ProbDev – Problem Management environment focused on production snapshots for replicating issues found in production.
The following table lists the usernames: {obviously cleansed and changed for security purposes} Key here is to create naming conventions that make it ease for each lifcycle to be identified and controlled. This will make it a lot easier with building RACI models in your CMS map.
| User Type | Production User Name | Demo User Name | UAT User Name | QA User Name | Dev User Name |
| Group Name | |||||
| Enterprise Cloud Administration | |||||
| Access User | |||||
| System Admin | |||||
| Application Administration | |||||
| Database Administration | |||||
| Data Access User (can see datapoint for customer information) | |||||
| Customer Service Access (access to configuration and registration info) |
