The natural cycle in IT is to move from decentralized to centralized services. When networking first appeared, it was implemented at a department level for printer sharing. It was decentralized—resulting in a hodgepodge of networks and protocols. Eventually IT organizations determined that it was much more efficient to centralize this effort and we saw the adoption of large-scale, TCP/IP networks. Today nearly every IT organization has a centralized networking team that manages and deploys IP-based infrastructure.
When SaaS applications such as Salesforce first appeared, they were adopted by sales organizations. As adoption levels grew, enterprises needed centralized data integration, identity and access management, and other functions that are inefficient to deliver at departmental scale. Today Salesforce is typically managed by a centralized IT organization.
IaaS has gone through a similar transition. Initially, development teams were thrilled to do away with the two-week turnaround times of a ticket-based central IT function. However, as the number of workloads on the public cloud has grown, the decentralized model of every dev team doing their own IT no longer makes sense. Again, it’s much more efficient to centralize.
I recently met with Ian Barraclough, senior director of enterprise architecture at IHS Markit Inc. IHS Markit is a global company that provides information expertise spanning numerous industries, including leading positions in finance, energy, technology, and transportation, and the company is experiencing this decentralized to centralized transition. Over the past few years, the IHS Markit application development teams have realized significant gains in productivity and reduced time to market by utilizing self-service IaaS on the public cloud. But as the number of applications being deployed on the public cloud has grown, the development teams have been burdened with functions that could be better managed by a central IT team. The question IHS Markit faced was how to implement centralized processes and controls without going back to the cumbersome model of tickets and segregated duties.
To solve this challenge—and taking into account this new age of self-service computing infrastructure—Ian and his team have developed the concept of a Minimum Viable Operating Model, or MVOM. Very simply, this model asks: What is the minimum set of controls that need to be in place on top of which a developer can freely operate? The team came up with a list of 50+ items that can be predetermined, allowing the development team to focus on creating applications for the various lines of business at IHS Markit. Typically, legacy processes and tools have to be rethought in order to integrate into a self-service model, so the trick here was to identify tools and processes that can enforce policies centrally without burdening or slowing down the cloud development model. As IHS Markit discovered, other companies that are considering adoption of the MVOM should address the eight major topics listed below, along with a few representative questions in each topic..
To establish a Minimum Viable Operating Model, address these factors:
1. Account Management
- How do we tag resources?
- How do we manage security?
- How do we utilize shared services?
2. Identity and Access Management
- How do we handle federated service access?
- Who has console access?
- How do we audit access?
3. Cost Management
- Who handles Reserved Instance purchasing?
- How do we do LOB cost reporting?
- How do we manage budget governance?
4. Networks and Firewalls
- How do we manage VPN connectivity?
- How is IP CIDR management handled?
- How do we manage DNS?
- How do we implement isolation?
5. Security and Audit
- How do we do SEIM logging?
- What is our logging policy?
- How do we manage SSL?
- How do we do vulnerability scanning?
- How do we implement edge security?
6. Service Management
- How do we do business service monitoring?
- How do we do Infrastructure monitoring integration?
- What is our ops engagement model?
7. Policy Management
- Who manages security policies?
- Who manages data protection?
- Who manages patching and hardening?
8. Infrastructure Applications
- How do we manage email services?
- How do we manage FTP?
- How do we manage remote access?
Every item on this list can be centrally managed. By establishing processes and systems that conform to the MVOM, developers now enjoy the efficiency and speed of the self-service cloud, while lines of business are not burdened with re-creating core IT policies and systems. This transition frees development teams so they can focus on what they are good at—creating business logic.
The Minimum Viable Operating Model offers guidelines to other companies hoping to achieve the same separation of duties and efficiency. But we must be patient; change is hard. The IT vendor landscape is still reacting to this new model, and tools for implementing these types of controls and policies are nascent, though clearly emerging. Central IT organizations are embracing this idea and realizing there is an opportunity to add value in the DevOps world. For long-term success in adopting the MVOM, it’s important that IT organizations do so in a manner that doesn’t restrict the agility and speed of the self-service cloud.