You’ve inevitably heard the phrase Ivory Tower which refers to the unrealistic separation from real world activities that we often see in academia. This is a challenging situation where conceptual thinking doesn’t work in the production application because there are different outside factors that affect the real system that aren’t accounted for in the overly clean design from the ivory tower thought process.
Even more challenging than the ivory tower is the concept of IT silos. Silos occur in organizations where different business units or teams are very self-contained and do not share well across the organizational ecosystem.
As more of us explore the idea of DevOps concepts and converging infrastructure, we are seeing the need to break down these barriers and work more tightly as cross-silo teams. Not only are applications becoming horizontally scalable, but so are teams. Changing the way that teams interact is a fundamental part of building agility to deliver IT services in a new way.
Setting the Goal
In the popular book The Goal by Eli Goldratt, we see the story of a manufacturing plant manager who is tasked with changing the outcome by changing the way that the plant operates. We quickly discover that the way to get to this new outcome is to first define it. Setting the goal is required because if you don’t see the target, how can you possibly hit it?
Silos are the traditional legacy model where each area of expertise is tightly held within a team, or department. There will be a network team, a server team, possibly an operating system team, and even that can be split to *nix and Windows servers. The reason for this was the idea that there are subject matter experts (SME) and we build on that within a core group to ensure the best of possible support.
What we have today is the blurring of the lines between these silos as we introduce hyperconverged architectures, software-defined networking running in hypervisors, Infrastructure-as-Code and all of the newly forming DevOps concepts. The idea of the silo is no longer going to work under these new models because there is no way to fully separate the groups, nor should we.
What we find most often is that good systems architects have a broad understanding of technologies, and they often have dabbled in supporting and building these technologies leading up to them taking the role as architects. In fact, we may even see that they rose from the traditional silo-centric organization but were able to move from team to team because they rose above the locked-in concepts of being trapped in each respective silo within the data center.
As we enter a rapidly growing technology ecosystem that is embracing containers, software-defined networking, security within every layer, and much more that tears down the silo barriers, it is the ideal time
How to Get Started
If you’re in the server team, take some time out and talk to the network team. You do more with them than just request physical ports to be turned up, so why not keep the conversation going further as well. This is the time to ask them about what they think of micro-segementation and adding security policies closer to the hypervisor. We may be looking at deploying something like edge firewalls within the hypervisor, so what are the implications? How will the network team work with you to design and support this architecture?
Don’t think that the network team is the one-stop shop either. As you dive into the applications, you will see that security and policy is pushing all the way down to the code in many cases. We don’t have to be able to read the java code, or write database queries, but perhaps we need to fully understand the logical architecture of the applications. How else can we design the most effective architecture in virtualized platforms or in the cloud if we don’t understand what the goal is.
Ah, there it is again. The goal. What is our goal? The goal within IT will most likely center around providing a platform (software, network, compute etc.) to enable the business to deploy and manage applications to run their organization and satisfy customer demand. Regardless of which area of IT you are in, you have a role in providing a supply of resources to satisfy a demand.
It’s time to put away the rulebook of silo IT and embrace the concepts. It is a slow journey, but an inevitable one. While you’re at it, read The Goal, and the technology-inspired Phoenix Project which takes the concepts of Goldratt and applies them to software development. This is an exciting time in technology, and even if you don’t arrive at a full DevOps shop, there are a lot of stages on the path that can help us do better at what we do. One thing that is for sure is that thickening the walls of the silo will certainly not be an enabler for agility in IT, or in business.