Working within the horizontal silo

It’s about 6:20 in the morning, and I’m presently on a 5 hour bus ride with a bunch of IT staff headed toward some facilities of my employer to learn more about their business. Before I get into the topic for this entry, I certainly want to give kudos to my employer for setting up this opportunity for IT to learn more about the business. With the long bus ride, I’m trying to get caught up on some podcasts. I’m presently listening to a discussion on SOA Management with Jason Bloomberg of ZapThink and Dana Gardner of Interarbor Solutions.

In his intro, Dana Gardner used the oft-mentioned and maligned term, silo. For whatever reason, it suddenly occurred to me that we always work within silos. Organizational structures create silos. Projects create silos. Physical locations can create silos. So, perhaps the right discussion shouldn’t be how to eliminate silos, but rather, how to choose silos correctly, work appropriately within them, and know when to redefine them. I’ve commented a bit on how to organize things, specifically in my post on horizontal and vertical thinking. For this entry, I’d like to discuss the appropriate way to operate within a horizontal silo.

A horizontal silo is one where the services being provided from that silo have broad applicability. A very easy example most organizations should be familiar with is servers. While there are multiple products involved based on the type of processing (e.g. big number crunching versus simple transactional web forms), you’d be hard pressed to justify having every project select its own servers. This area isn’t without change, one only needs to look at the space of VMWare and its competitors to see this.

In many IT organizations, when a centralized group is established, the focus can often be on cost containment or reduction. For many horizontal domains, this makes a lot of sense, but there’s a risk associated with this. When a group focuses on cost reduction, this is frequently done at the expense of the customer. Cost reduction typically means more standardization and less customer choice. To an extreme, the service team can wind up getting too focused on their own internal processes and expenses and completely forget about the customer. This is neither good nor bad, only something that must be decided by the organization. I can do a lot of my household shopping at either Target or Walmart. I’m probably going to have a better experience at Target, however, it will probably cost more than Walmart. What’s most important to you?

Within the enterprise, I’ve seen this dilemma occur in areas where some specialized technical knowledge is needed, but where the services themselves ore not standardized/commoditized. The most frequent example is that of Data Services. Many organizations create a centralized data services group to retain oversight over all SQL written. The problem with this is that while we may have a team that can write great SQL, we may not have a team that really understands what information the business needs from those queries. The team may try to minimize the amount of services available rather than give their customers what they need. What’s the right answer?

When establishing a service team, you need to think about your engagement model. Are you going to provide an outsourcing model, or a consulting model? In an outsourcing model, the service is largely provided without customer input. Customers simply pick from a list of choices and the burden is completely on the service team to provide. Getting a server or a network connection may be much better suited for this category. In a consulting model, there’s a recognition that some amount of input from the customer is still needed to be successful. I can’t create a good data service without knowledge of the customer’s information needs. A consulting model is going to be more expensive than an outsourcing model. If an organization is judging the success of this team based on cost, however, that’s a problem. This is an issue with the success criteria, however. First and foremost, we want to be sure that the right solution gets built. When the services being provided are provided in a cookie-cutter approach, the emphasis can be on cost. When each service requires customization, the focus needs to shift a little bit more toward providing the right solution, with cost as a secondary concern. It may not be about creating reusable services, but usable services that are less likely to cause problems than a custom-built solution by staff without the proper expertise in a given area.

3 Responses to “Working within the horizontal silo”

  • Rob Eamon:

    Interesting thoughts. And interesting segmentation of the servicing models.

    One of the issues I see is that a service team is often judged using both models–their feet are held to the fire for costs but they are also held accountable for “customer” satisfaction.

    You’re right that this is “something that must be decided by the organization.” How often, I wonder, is this decision not explicitly made but rather a default behavior?

    This can be counter-productive when the customer/provider relationship doesn’t really exist–if someone isn’t paying directly (not the silly charge-back notion) for a service then they are not a customer. “The customer is always right” and “give the customer what they need” are good mantras to follow–if you actually have a customer.

    If you have a business unit within the company, chances are they are not a customer in any sense of the word. The interactions between the groups should be as partners–which I think you’ve mentioned in previous posts. Partners work together to address the (sometimes competing) constraints that they each must address in some mutually acceptable manner.

  • Scott Pollino:

    Silos are not inherently bad. It is easy to accept the rhetoric often heard from IT management “Knock down the silos”

    At a recent engagement we worked diligently for over a year to make sure new services that were built were available enterprise-wide. Some of the older apps were rewritten to take advantage of the centralized customer data.

    A side effect noticed during one release was that four business units had to delay their release while they waited for one of the more integrated applications to get all of the bugs out of their code. Suddenly, silos did not seem so bad. While there was duplication of effort, the business know who to beat if things went wrong.

  • […] scope. I think some form of business domain model as I’ve discussed in the past (here and here) that classifies domains of capabilities from the perspective of “share-ability” is a […]

Leave a Reply


This blog represents my own personal views, and not those of my employer or any third party. Any use of the material in articles, whitepapers, blogs, etc. must be attributed to me alone without any reference to my employer. Use of my employers name is NOT authorized.