Your IT department is a monolith. Break it up.
As software developers we often look at systems and how they can be broken up in bounded contexts to loosen coupling and improve our ability to deliver value within them. Yet as software developers in large corporations we are often grouped into one large IT department serving multiple business interests. Maybe it's time to review that.
Many of us will have seen our harrassed-looking CTO (or equivalent) having just emerged from some quarterly or annual meeting with diverse business stakeholders who have been fighting for their cause to get some IT resources. Maybe that CTO will have been part of the fighting, advancing their own technical (or otherwise) agenda. What is all this fighting good for?
The IT department is no doubt there with the best of intentions, probably with a mission along the lines of "facilitating delivery of business value with technical innovation and efficiency". These all sound like good things to get behind. We all know which road is paved with the best of intentions.
The kicker is often the efficiency part, and it's a trap we often fall into when coding - premature abstraction, or premature de-duplication, is a root of much evil. Seeing that two things look pretty much the same and abstracting over them without careful thought leads to pieces of code or even whole services with multiple dependents they must continue to serve making them harder to change.
If some code is seemingly duplicated between two bounded contexts then it isn't really duplicate code at all - and abstracting it places it in a third, shared context. Those former separate contexts are now coupled and there's a third context whose purpose is unclear. It probably got called "util" or "commons".
The IT department is that third context writ large.
A department whose purpose is aggressive deduplication, probably with an explicit mission to "keep costs down". Which it might well achieve in the short-term, in a very specific way. But the long-term cost of that coupling can be enormous and much harder to measure.
One of the reasons we want to break up monoliths is so that the individual contexts that it serves can operate independently to the greatest extent possible - if one breaks it doesn't bring everything else down; if one needs more resources it can be scaled without needlessly scaling the rest; it helps us resist the temptation to share more code than we should; it allows code in those contexts to be written in different languages, languages (hopefully) more suited to context.
But in doing this breaking up we often end up just pushing the monolith abstraction even higher, to the organisational level. Internally we are divided into teams owning our (relatively) independent systems and being able to deploy features as we like. Externally we are The IT Department, whose resources must be fought for and which probably also has its own agenda for it to fight for.
Again, with the best of intentions - cross-team concerns like certain standards to keep to or approved technologies and methodologies to use, efforts to reduce (apparent) duplication with shared service teams, technological innovation for it's own sake, etc. But these are horizontal forces working against the vertical force of the business.
That vertical force is the delivery of value to the business - where the money comes from that keeps everyone employed and shareholders in golf clubs. How much good is that horizontal force bringing? At what point is it too much?
It's possible you work in an IT department that has attempted to "align" itself with the business, with vertical teams assigned (hopefully) to actual business goals. Congratulations, you are in a monolith with a good package structure! And I bet it has a "shared" package or two doesn't it?
Rather than aligning with business units, and hoping that flow happens naturally with them (albeit with that horizontal force still in place) why not embed within those business units? Be closer to the business experts and the customers?
At that point Agile is a word it's hard to avoid. You've probably heard people in your IT department crowing about how un-Agile the rest of the organisation is - your IT department where most of the people are probably well bought in to Agile and have been practising it daily for most of the past decade. Stop preaching to the converted and get out there then! Open some missions! If your Agile team embedded in a business unit and people there look and see those ideas being effective maybe they'll want in on that.
Self-organisation is a key principle of Agile but just how self-organised can a team within a large IT department really be? The burden of sharing so much in this context is easily underestimated. Not only will there be obvious shared concerns like infrastructure or shared services, but less apparent ones like shared recruitment (recruiting people generally and then assigning them to teams rather than recruiting for the needs of a specific team), shared office space (the age-old struggle to book a meeting room; organising your stand-ups around the times other teams have theirs; the noise, oh my god the noise), shared mandated methodologies (You Will Develop Software Like This Regardless of Whether it Fits Your Product or Team).
Shared infrastructure should be a major concern. When you have this then each team's usage of it will affect the others - there are no closed systems. And changes made to that infrastructure will affect all, sometimes to the detriment of others - if team A needs shared system X upgrading to a new major version urgently then team B also has the burden of ensuring their systems work with that upgrade regardless of whether they need it yet, or at all. If the infrastructure suffers a major outage then everything is down for the whole company - no money is being made during this time. A lot of eggs in one basket.
Innovation! That's something we all seem to want. But any innovation within an IT department is most likely to be IT innovation - the creation of novel technical solutions to technical problems. This isn't intrinsically bad; it could boost the technical reputation of the company, making it easier to hire; you may end up contributing to the outside world as open-source software - and now you have something to maintain for even more dependents, funnelling development effort away from the business. Arguably the more important IT innovations are those to do with the business - novel technical solutions to the problems your company is solving, and those are far more likely to come from an embedded development team which has grown to understand the domain.
If you were to break up an IT department in this way are there any things it would make sense to still share?
At a technical level you probably still need a team to manage things like DNS, especially if public-facing products are divided up by sub-domains like *.bigcorp.com. Not so much if they have their own domains. This could easily fall into the territory of sysadmins (though god help you if that has been outsourced).
If you have shared internal infrastructure, i.e. the company has its own datacentres, then clearly those will need to be well-managed and there could be a common deployment platform shared by teams embedded in business units. If the deployment is to the cloud however, there may not be so much benefit - why not let the teams choose their cloud provider and meet the costs from their own budgets according to their usage? Maybe if usage is heavy and plans work significantly better for the company at scale then a distinct owner of that which services all teams would make sense.
How about identity services? There's a good case for centralising that as something shared, though there are drawbacks as well. Big companies with many public faces often have at some point a big drive for SSO, assuming there will be some benefit to one shared account serving many purposes. It is often a questionable assumption - users may often only be interested in one aspect of a company's offerings; people need to remember so many sets of credentials these days that the two or three needed for your company are a drop in the ocean, and will be stored in a password manager anyway; you could end up with an accidentally confusing user experience.
UX would seem to be a clear case for a shared resource. Maybe. But the fine details of UX will be different between, say, a corporate marketing page and a web-shop and may be best handled by embedded UX practitioners building up more specialist knowledge. Perhaps some limited global UX oversight to keep things consistent would be appropriate, much as big companies will have some guidelines and designers to maintain their corporate ID.
Having an IT department together so that those involved in the different roles of software development can communicate and learn from one another sounds kind of convincing - but nothing about distinct embedded teams precludes employees in different professions communicating with one another, forming communities of practice.
Conclusion
I concede this is somewhat polemical and possibly farfetched. I may have missed some important reason why having a big shambling IT department monolith, resented as opaque and uncooperative by the business is a Good Thing. It hardly matters because the idea of such a thing ever being broken up is a pipe dream; entrenched power will always make sure of that. However if a big corporation with many hats is at the preliminary stages of realising some kind of "digital transformation", bringing IT in-house etc., maybe it can avoid building that monolith in the first place.