It’s like a DVD stuck on replay. For years we have existed in an environment where the IT landscape is constantly evolving, but somehow the theme stays the same. Every year, sometimes more frequently, new technologies and new demands are added to the already existing overtaxed and crowded IT environments.
With each new addition, IT and business teams around the world are being asked to address emerging technologies. Some of these asks are converged environments, infrastructure services, SaaS solutions, CaaS/PaaS platforms, infrastructure as code, APIs, Office 365, on-prem, off-prem and more. End users are demanding services faster than ever before in the most complex environment to date. Some of the technologies are retired or re-platformed, but not all. Day to day business must continue running.
How can you effectively manage it all?
With a top-down service-based approach to consuming cloud services. There may have been a time when it seemed that the environment was well-managed, easier to provision, and not in a high state of flux. One may well wonder if they can ever get back to that, and the answer is yes, but it will take time, patience, and a well thought out and documented plan. Although we may not remember it, we had to apply thought and change in those times when it seemed more manageable.
If one is to learn from history, they should remember that they started by developing new teams to address areas that were new or had matured to a new level of function.
Those wishing to change could start with a cloud and IT infrastructure operations team. This team would, in collaboration with the business’ development teams, focus on configuring, upgrading, scaling, and operating in the infrastructure. They would design, manage, maintain and support the cloud environment. And they would build or document and expose infrastructure APIs.
But does that mean we can jump right in and start from there?
Certainly not. We will need to make sure that the connection between legacy and the new or future environment is well understood and documented. The move to cloud has been a long journey (over 10 years now). The reason is that in general those who moved or tried to move to the cloud have either made too broad of assumptions or did not fully understand the environments of the workloads being moved. Since they have already decided that configuration will be a part of the new cloud and infrastructure team, they need to make sure they understand the current configuration. This gives them the insight needed to upgrade the current environment or whether its current configuration will be valid in the cloud environment.
Additionally, will the configuration scale to the levels needed? Or is it already too large and need to be adjusted to be more efficient and cost effective?
If it’s a public cloud this is important because cost will be a major consideration. If its private, the teams will want to make sure they are using those resources better than in the previous environment.
Managing the New Environment
The management of the new environment and its capabilities will be governed by whether it is a public or private cloud environment. It will entail much more thought and process creation in the private cloud world for these areas. This is because there is much more control on the clients’ part in a private cloud world. What this does point out is that a good deal of thought needs to be put toward understanding what is needed in the way of insight into public cloud providers and how those contracts are managed.
Once an infrastructure is in place and could start to support the services required, the provisioning aspects and development management processes must be defined. Especially around the APIs the resources will be utilizing. This is often one of the most difficult and time-consuming areas of transformation. The number and different locations/owners of those API’s can become a full-time job if they are not addressed early in the re-engineering process.
New teams for this environment will need to focus on application development for (PaaS/CaaS) platforms. This team would focus on same elements of configuration, upgrades, scaling and operations but for the applications platform. The team would also be responsible for building and exposing APIs that support software development needs as discussed earlier. Like the cloud and IT infrastructure group the same considerations will need to be in place as it relates to understanding and documenting the current environment, to define and document a more efficient and responsive XaaS environment.
For other operations, including service management and automation, they naturally become shared responsibilities that work well together if the infrastructure groups as well as the application development team align early and build a common plan for configuration, management, maintenance, etc. The synergies gained by teaming early will continue to pay off as they mature in their transformation and pursuit of the next generation of technologies and services.