We believe that IT life-cycle should describe the entire yearly IT life-cycle, not projects life-cycle that’s so common to find all over the web. Good IT life-cycle should describe the main activities IT takes during the year, who is responsible for those tasks, what are the main check points through the processes and what are the required documentations.
IT life-cycle can be a written policy, procedure or even just a known document. It doesn’t matter what medium you choose to publish your IT life-cycle, you need to focus on how easy your IT life-cycle will be understood and followed.
The following IT life-cycle is what we are using at the Friedkin Companies. It’s not a formal policy, procedure or a document, yet it’s a process that all IT departments are following. We spend time and effort to build this life-cycle with all IT leaders across our companies and now we enjoy their support by following this process.
Our IT life-cycle has four main steps : Strategy & Direction, Solution design and delivery, Operation and Decommission. Each step has predefined tasks associated with it. While going through Strategy & Direction we understand what are the goals and objectives of our company and we are adjusting our IT strategy and architecture to reflect them. The outcomes of this step are IT strategy and set of projects that needed to be executed to better support our company.
Solution design and delivery is the classical build process of hardware and software solution, as they were defined in the strategy and direction step. Solution design and delivery includes all the tasks from taking a project idea until deploying the project to production. We are doing this step of IT life-cycle following agile methodology.
Operation is an ongoing effort to enhance and support all solutions, which has been deployed to production and still running on our IT platform.
Decommission is a very important step, which is responsible for removing unused IT assets. This step releases IT assets and resources, so they can be used to rebuild new solutions.
The size of each step depicts the relative efforts and time we are investing to perform it.
The life-cycle also defines when major tasks ( mainly from ITIL) are preformed. These tasks include architecture, release and deploy management, change management, incident management, problem management and event management.
To make IT agile, but controlled on the other hand, we defined just two required checkpoints. Architecture review, which should be done after requirements are gathered and before development or purchasing started. CAB (Change Advisory Board) should happen after development is done and before the solution is going to be deployed to production. RCA (Root Cause Analysis) should take place for every incident that impact business value chain and Health check should take place every two to three years for every solution running in production.
The need for agile IT also reflects our required documentation. BRD (Business Requirement Document) need to capture all customers requirements for a project. Architecture Document need to capture main modules of the proposed solutions, their integration with existing and new solutions, architecture fit to customer requirements, security and non-functional requirements. CAR (Capital Authorization Request) explain the capital needed to perform the project, project main releases and expected ROI. Design document need to be created for each iteration. it’s a living document that should define the entire solution when the last iteration deployed to production. Support document need to capture all needed data to enable our DevOps teams to support new solutions.
the Inner cycle depicts the differences between architecture, project and BAU (Business As Usual) activities.
We believe that this IT lifecycle is easy to follow and find the right balance between the need for agility and control. Want to learn more how this life-cycle is working for us? Follow Friedkin Companies CIO blog.