Serving a new Overlord, my trip to the CIO Office

I've recently made a significant career change.

I've spent around 20 years in the IT industry, always on the product side. I've developed customer facing systems and backend software for small startups and big companies.

As a result of that I had a very specific view of how different companies organize themselves internally. There are the different internal departments, depending on the size of the company, and of course I was always in the tech part, first as a developer, then a tech lead and finally as an architect.

Arguably, my vision is that I was part of the most important team of the company, building the systems (or the foundations) that would, at the end of the day, make money to the company, and pay all our salaries.

My reporting line always ended up with the CTO. But, there, next to him/her there was someone else. The CIO.

I had to check what a CIO was! Chief Information Officer. Well, isn't that the same as the CTO? well, maybe, quite close. Do we really need a CIO? That surely made sense for big companies, but for small ones? Is it really that hard to manage the internal systems knowing that it's basically a bunch of SAAS playing together?

Oh boy.

Fast forward in time, I decided to give it a try. Burnout was building up quickly with microservices, framework discussions and a million more code related things. I said to myself: Let's try "the other side". It's going to be tricky for sure, but not that problematic.

Oh boy.

I jumped in, did some interviews and suddenly I was an "Enterprise Architect". Gosh, that sounds important. And well, it's interesting.

You might laugh at reading this, but I discovered a whole new world inside IT.

It's been some time since I did this shift, and now I think I have enough knowledge to write this blog post about my experience

I've divided my explanation into different subsections to make it more understandable. I hope you enjoy reading this.

A big shift in perspective

As an Enterprise Architect (EA from now on) role I need to solve a different set of problems that the ones I was used to. The EA is not in charge anymore of a product that needs to get more features and grow. You are in charge of a house of cards that's built with different vendors, different systems, different patterns and... shadow IT (we'll talk about that later), and those are the gears that keep the company running.

When you're in charge of development teams in product development you need to be able to translate the business needs to a product that works as the stakeholders expect and to provide a system that validates non-functional requirements. These products will evolve, grow, but you're the one building the new features and monitoring how they behave.

In enterprise architecture you're presented with a very complex puzzle of different systems that cannot be fundamentally changed (you usually can only change configuration) and your responsibility is to make sure that they play well together, while keeping the costs down, because every piece of that puzzle costs money. Lots of.

Another important difference are the stakeholders. In product development you typically interact with the development team and the product team, ideally the customers as well. You do your best to understand the product to transform it into running software.

Stakeholders in enterprise architecture are the employees that manage the complex customer contracts, the ones that manage the marketing campaigns with millions of real customers, the HR people with highly sensitive data, ... and your role is to make sure that tools that they use every day to do their tasks and workflows work as expected.

These people are the backbone of any company. They need to work properly and effectively, and it's hard to balance innovation with the enterprise requirements.

There might be a shiny new feature in a system that we are already using, or an amazing new SAAS solution that will replace our old system, but does it fit well inside our particular puzzle?

Key Differences in Technical Approach

This was hard for me.

On the first day I was given a Windows laptop. I hadn't worked with a Windows box since... 20 years ago. XP I think.

One of the first things I installed was IntelliJ Idea with the vim plugin. Ah! the naivety.

The technical approach in the internal enterprise ecosystem is very different from what I was used to. In my experience, it falls down to the famous "Buy vs Build" topic.

I've went from working with a team of developers in order to create a system using open source programming frameworks and systems to reviewing RFP's and SOW from contractors and going through software licenses costs.

From 80% build to 80% buy.

New Skills I Had to Develop

Given that I'm not building the systems myself, or plugging in open source frameworks I had to learn few things.

A new system, or an upgrade, needs time and money. And you need to justify it carefully.

Welcome to the world of budgeting and ROI. While the concept is simple and makes tons of sense it's not easy to nail.

When starting a new project you need to investigate and do the due diligence. I'm talking about a big spreadsheet with the estimated team that you'll need (probably contractors), the tooling and the new software price. Oh, and don't forget that you need to take into account the deprecation period of the old system, training for the users and the whole migration process.

Every project is different and I could probably write tons of pages about how to do this. It's not a really interesting topic per se and there's tons of books and documentation around on how to do this. So, I'll just leave it as it is.

I'd like to focus and write on a surprisingly interesting topic, which is "governance and standardization practices". I'll admit it right here that it doesn't sound interesting at all, but please, do give me some time to explain.

As part of this journey I discovered some tools which I admit I had only heard of.

Some of them:

• PowerBI: This is a tool by Microsoft that let's users build dashboards and visualizations from different data sources.
• Microsoft Power Platform: It's a set of tools by Microsoft that aim to "Empower everyone in your organization to develop solutions with low-code tools."
• (And to some extend...) Microsoft Excel: You probably know about this already.

Ok, so, what about them?

What they have in common is that they are readily usable by anyone, they are very easy to use and they are very powerful.

So, when Jake from Marketing needs an automation, a new feature, or an improvement on how he does daily tasks he can do two things:

• Ask IT for it, which means that somebody will need to investigate vendors, allocate resources for the project, do the ROI for it, prepare the integration architecture, ...
• Or do it himself.

So, Jake opens up his PowerBI, his Excel spreadsheet and after some YouTube videos he has put something together which, kind of, does the trick.

Jake has created a new piece of Shadow IT.

Shadow IT is usually software that has been created (or bought) by non IT departments. While these systems usually work they lack proper integration, documentation and security measures.

It works, until it doesn't. Then the IT department is called in to assist, to discover a full network of Shadow IT systems that plug somehow (manually or via excel connectors) with the central IT systems, without any kind of documentation and done by a myriad of people who have already left the company. Oh, and security? what about it?

Oh boy.

This is why I think that topics like governance and standardization are very interesting. It's critical to have governance and standardization processes when your users have access to these kind of tools.

You need to have them both, but in an appropriate way, if the controls are too loose there's going to be chaos; if there are too tight the people will find ways (very imaginative, trust me) to bypass the controls.

It's a matter of creating guidelines that are good enough to provide liberty to the different users without letting them go wild. Because you'll be the one doing the cleaning up when the party is over.

Governance is an important and delicate topic, I'll probably write more posts about it in the future.

Surprising Benefits

There are some interesting benefits in working in the CIO office.

First one is being able to improve the life of a different set of users: your coworkers.

It's really satisfying to see them happily using the new features you've integrated (not coded) or how they can spend more time in the coffee machine because that tedious work is being done by the AI module you've purchased.

I've also realized that I didn't have a clue about the complex workflows and processes that happen inside a big and complex company. Topics like contract lifecycle management, inventory handling and supply management have become familiar topics now. I didn't know they even existed, but it's what keeps the ball rolling. These topics doesn't seem as interesting as memory allocation or horizontal scalability, but they have their nice parts 😄

Lessons Learned and Advice

I'm really enjoying the journey. It's true that every now and then people need to restrain me while I scream how I could implement that feature for half the budget and half the time in Golang with a tiny virtual machine, but this is how it works.

It's not trivial and it's not an easy move, so use all the help you can use. Luckily I've found a good team of professionals eager to help all newcomers. "The Accidental CIO" book by Scott Millett also helped me a lot. Have a look at it if you're interested in IT, worth every page.

If you know me you'll know that I take documentation very seriously. If you are in charge of a complex IT landscape with different systems from different vendors and different kind of integrations you'll appreciate a good map.