Platforms, Cloud, Kubernetes... Oh My!

If you were a technology leader or CIO today what would you say is the mission or goal of your organization? What is the mission or goal for you as a CIO or IT leader to enable the great mission? How do you go about delivering on that goal?

If your goal as a CIO or technology leader is not to enable, innovate, and deliver quality software products for your organization’s greater mission – I implore you to think deeply about technology and how you might deliver on the goals of your organization.

Now the technology industry is extremely broad and is nearly impossible to keep up with. Between artificial intelligence (AI) and machine learning, quantum computing, robotic process automation (RPA), virtual reality and the metaverse, web3, cryptocurrency, latest cloud innovations, and many more – it impossible to understand the landscape and how these areas might affect the approach you need (or want) to take in delivery on the mission. These thoughts are specifically targeted at the specific mission “…to enable, innovate, and deliver quality software products for your organization’s greater mission.”

Where do we start in our process to enable product development teams in delivering software? Simple answer that is prevalent across the industry is that you need to “develop a poly-cloud (or multi-cloud) strategy” or “develop a Kubernetes strategy” – do not limit yourself to ideas that have become the daily pitch from your friendly car salesman. Since the public cloud movement in the mid-2000s, the software industry has made unbelievable strides in bringing computing, networking, and storage primitives approachable for enterprises and all the way to “Mom and Pop” users around the globe. From the aspects and abstractions that grew out of cloud came software like OpenStack that led into container abstractions such as Docker and eventually the container orchestration project, Kubernetes.

Now this is not a history lesson about where innovation has impacted technology, but merely a reminder to refocus on the mission. While, at the end of the day, real winners are those that get it done day-in-day-out, but without a clear strategy that is mission focused and properly designed you are only limiting the growth and innovation for your organization. As we continue to move up the abstraction layers in technology, where can we start to design our mission’s core areas?

Start with day one, because without that day two is not possible… Conceptually breakdown the mission area groups outside of your teams / CIO groups. Here is an example use case we can approach –

You are a bank that operates as a typical product focused hierarchy. You have many product teams or focus areas – retail banking, commercial / business banking, forensics, wealth and portfolio management, identity, internal facing products, and maybe even more. Your group must ensure dependability and delivery of software systems across these product areas. The mission of the greater organization here, the bank, is to provide the best banking and wealth management services and experiences to individuals and businesses.

For this scenario we are going to assume that our costs are not our main focus (obviously we cannot ignore the cost to support these systems). Strategically where you should start is to understand that data is king. Access to storing, retrieving, processing, and analyzing data is going to be a vital area to each of these product areas. Secondly, the ability to run applications for those individual and business end users is also vital to product delivery. Lastly, enablement – how can we enable the product teams with storage and computation resources?

Logical Breakdown

Below is a conceptual breakdown that should help visually that depicts how the product development teams are split up between the CIO group / platform teams that support the underlying technology primitives: storage and compute.

Enablement

Not only is developing the right abstraction over storage and compute critical, but the way to scale support for the missions of your product teams is to enable them through self-service and purpose based offerings that deliver on the technical goals these teams have. Understand there are aspects of technologies that are going to enable different goals and features of different products. This is where everything gets interesting. For example, you might think that a new shiny cloud service offering is going to completely transform how your auditing and forensics teams process transactions. That might be the case, but let’s say this new service could be an open source offering like Apache Drill, and the applicable use cases are to analyze all events the product team collects. These events are stored across the different areas their mission is focused on. This is a perfect use case, but the product team only wants to use the cloud provider’s service BigQuery.

Instead of honing into technologies, conceptually step back and define the use case and align this to the mission’s goals. Remember the product team needs to analyze data from places easily and efficiently. This consists of data storage, computation resources to fetch the data, underlying networking and typically other overhead software like identity (authn / authz) tools, observability, security agents, etc. As a Boring CIO Group, develop the “standardized component” that defines these components to abstract exactly what the product team needs. They want BigQuery? If this is deemed practical, develop a way to reuse and configure your catalogs for teams to request and self-service the necessary components to utilize BigQuery. If not, develop your catalogs to provide a way to deploy and configure necessary components to support a tool like Apache Drill. Yes, this is not a perfect 1:1 swap for BigQuery, but the mission goal is to analyze data from many different sources. You have determined Apache Drill is a good fit to deliver this across your organization.

Enablers should be your bread and butter. Enablers can sometimes be specially for your internal teams, but they should never limit you to specific technologies. Remember the goals of your organization are not technology specific. They are focused solely on the individual and business banking consumers. Enablers should also focus on automation. Automation can be defined as workflow, or standardized processes to complete tasks or workloads in a regular cadence. If someone requests an Apache Drill setup that is configured to communicate with 3 different data sources, automate it through provisioning and configuration standards that can be reused. The product team does not care how it gets created, but the value add is their go to market timelines should not be blocked by your teams. Enable to enable.

These enablers should wrap around all technology and IT business processes to assure your business is driving efficiency in mission delivery. You will see below the new layer wrapping around all things your Boring CIO Platform teams offer.