Thoughtful Reopening
By: Kyle Gene Brown
Tags: Reopening, It Management, Software Development

Kyle Brown, IBM Fellow, CTO Cloud Architecture, IBM Cloud and Cognitive Software

E. G. Nadhan, Chief Architect and Strategist, North America, Red Hat

Reopening after a long closure is an opportunity (Image: Wikimedia commons)

Thousands of businesses in the US and around the world are starting the process of bringing back their furloughed IT staff and getting back to business. However, the process of reopening creates a unique opportunity for reinvention that many large enterprises rarely get. Especially considering that the current economic models indicate a slow, prolonged recovery (it may be late 2021 or even 2022 before the world returns to pre-COVID levels of economic activity) businesses should take this opportunity to reassess how IT will operate once they reopen. By being thoughtful in how projects are restarted, how teams are reformed, and how priorities are reassessed, at the end you may be able to find yourself in a better position than you were prior to the shutdowns.

Based on our experience in what we have seen with many clients, we are starting to see some common themes involving these areas, and are developing a fairly strong POV, which we believe is relevant to many businesses in different domains. As a result, we’d like to share a few very successful approaches that we’ve observed.

Take time to automate common IT tasks. The COVID-19 situation has left teams in an unusual position — while many enterprises have reduced or delayed new development (unless it was directly related to the crisis) they have had to continue to maintain and operate existing systems to simply “keep the lights on”, although often at a reduced load. That means that teams are expected to do more “standard” development tasks with fewer people. That makes this a wonderful time to invest in automation of common IT tasks. Automation of existing tasks like patching middleware and operating systems, release management, and setting up and tearing down environments will make your teams more productive and reduce stress and human error. Not only does this pay back some of your technical debt by redirecting the workforce to more innovative tasks, but it also facilitates agility since it builds up a reusable library of automated components.

Clean out your IT toolbox — It’s when you are working with a reduced staff that you start to realize the problems inherent in having too many tools in your IT toolbox. While there may have previously been good technical or economic reasons to add many specialized tools into your toolbox when times were good and staff were plentiful, in times of cutbacks and slow rehiring you don’t want to be stuck with issues in that one unique system that was built on something only a few people understand. You need the flexibility to reallocate teams and change team sizes and structures to cope with the increased workload on a smaller staff. That means standardization on a small number of platforms, operating systems, and middleware enabled by a fixed library of tools becomes even more critical. Standardizing on open platforms that are agnostic to on-premise and cloud environments will greatly reduce overall training and maintenance costs.

Take advantage of a common platform — One important way to standardize on a smaller set of tools is to take advantage of tools provided by common open platforms — often platforms you already have. For years, IT teams have wanted to take a “best of breed” approach that often means adding tools that are duplicates or slight improvements over tools already provided by platform vendors. However, by standardizing the tools, runtimes, and approaches that come bundled with the platform, you reduce the total amount of training needed, reduce overall redundant license cost, and create a broader pool of relevant expertise within your organization.

For instance, with Red Hat OpenShift, one way of taking greater advantage of the platform is to accelerate containerization of existing applications as a first step toward modernization. This incremental approach is less costly and difficult than intensive refactoring/rewriting of existing applications. Taking advantage of operational support provided by the platform for even traditional (e.g. not cloud-native) applications allows you to gain better economies of scale, and at the same time reduce the overhead of multiple platforms. Additionally, it positions you for growing into other cloud environments as appropriate in the future.

Adopt techniques from open source — One of the ramifications of a smaller IT team is that more people will need to wear several hats. This may mean, for instance, that specialists in particular technologies or techniques may need to spread themselves across several projects and contribute to multiple teams. The best way that the industry has found to spread that knowledge is through an open-source approach that is predicated upon an open, collaborative mindset — creating self-organizing teams around specific projects with contributions throughout the industry. The internal counterpart of this is sometimes called the “inner-source” method. In that approach, you take the same techniques and mindset from the open-source model and apply them to solving your internal IT issues. So, for instance, if there is a AI or analytics model that needs to be built to solve a common problem unique to your business, that maybe something that is best suited for an inner-source model so it can be understood and reused more widely across your teams. Adapting an open mindset within a collaborative culture that thrives on meritocracy paves the way for greater autonomy for your teams, thus motivating them towards innovation that matters to the enterprise. And assuring a safe, secure, and compliant environment with enterprise-grade, hardened platforms redirects the focus to empowering the business and augmenting the consumer experience.

Where you can go from here

There are many other, more ambitious efforts that organizations could also take on, including moving to more of a product-based model and bringing work to existing teams rather than forming teams around projects. But these are some simple starting points that we believe will be beneficial to most IT teams.