Breaking down digital silos

Let’s not just bemoan digital silos, but instead look at how to break them down. In working with organizations to resolve this, I find there are two primary ways of moving away from silos:

• Right now (and on a general day-to-day basis): don’t create more silos.
  

• During big change: tear silos down. 
  

If you are reading this you probably don’t need much convincing about why silos exposed on websites are generally bad, but it’s probably helpful to start by listing some of the many problems with digital silos: 

• A confusing experience for visitors

• Inability to direct visitors toward the perfect content (for them) that your organization has (but is disconnected so they can’t find it)

• Inability to have well-coordinated funnels on your site

• Brand inconsistency

• Inability to keep your digital presence fresh across the board

• Inefficiency in maintenance and duplication of content / efforts

• Difficulty in moving digital staff between silos

Fundamentally, you wind up with an incoherent presence.

In general my approach with any digital problem is to: 1) dig deep to figure out where the problem is first occurring, and 2) how to break that process in the first place.  So... we don’t want to make the problem worse by creating more silos. 

Right now: don't create more silos

Most organizations can’t help themselves from digging themselves deeper, applauding glitzy one-offs or the plucky initiative of folks figuring out ways of getting around existing constraints. But the more one-offs that are created, the more disjointed your site becomes. 

Since steps toward more fragmentation are often applauded (since the team emphasize the specific new elements rather than clearly understanding or emphasizing the resulting fragmentation), first let’s consider examples of creating more silos:

• Launching a microsite (unless you have a mechanism in place to keep them consistent)

• Creating any functionality for a single site that will not be available to other sites 

• Overriding standard behavior

Broadly speaking, you want to avoid fragmentation, which means:

• Avoid creating custom code (for one specific page or section, especially when it could be applicable to a wide range of pages)

• Avoid creating sites, sections, and pages that are disconnected or inconsistent with the rest of the site.

A quick aside: you may be saying “but we need to innovate and experiment!” That is certainly true, but if you do so then experiment toward high impact, and not just waving the banner of innovation as an excuse to do a narrow one-off that cannot be leveraged again by your organization. 

As a first step, check out this one page checklist when considering a microsite (or watch this one minute video). A checklist like this not only provides some context for the discussion of your next request but also lets everyone know the type of criteria when you might consider a microsite. You may not “win” at first, but at least you start with a clear set of criteria (which may also lead to more productive conversations / feedback about how the criteria should perhaps change).  Also,  over time you may find patterns in the requests, which is relevant especially when considering big change. 

During big change: tear silos down

If you simply delete what was a one-off silo then that can be easy. That said, tearing down a silo is usually more involved than that. This is because we need to do three things: 

1. Convince stakeholders that it makes sense to break down the silos.

2. Architect a target state.

3. Define a path of getting from where you are now to the target state (for instance in splitting / merging). 

We need to deal with one issue head on here: the decision to break down silos and define a general approach should happen before talking with potential implementation teams. This is because:

• Making the decision is complex (and may take time) . 

• There could be wild swings in the effort of potential implementation approaches depending on the decision.

• Different types of implementation partners may be appropriate for different types of silo busting

• There are tons of elements to breaking down silos that are not technical.

Any time you are considering big changes to any part of your digital presence, you should think about broadening the extent of change for even higher impact (see What's your number? The potential extent of web change impact).

Convince stakeholders that it makes sense to break down the silos

Sometimes it is not appropriate to consolidate sites, and of course really the key is to /prioritize/ the effort. In other words, it may be ideal to combine the e-commerce, blog, and corporate site, but the highest bang for the buck would be consolidating the blog and corporate site. Also, although your intent may be to break down silos, the approach is to facilitate the decision. To do this, you need to carefully paint the picture (contact me if you’re interested in one of my executive decision making workshops): 

1. exactly how the silos are currently causing issues, 

2. what breaking down the silos would look like, and 

3. what are the pros/cons of different approaches (including simply stating the ways that stakeholders will lose some control but gain in other areas such as cross-selling). 

Architect a target state

A strong architecture for your new site may look very different than the current one. For instance, if your site is currently structured around silos then the new architecture may be more around key tasks your organization can help clients with. Note that this is not the same question as going to a web development shop and asking them to vision a new site — at the early strategy stage (before talking with potential vendors) you need to broadly define the needs so that you can try out different combinations (what would it look like if we merged these two silos but not the third? what if we made these two tasks similar across all silos but left fairly significant organizational sites for the less crucial tasks?). 

There’s also the backend. You may need to rethink how the systems in the background work. Are there source business systems (document management, association management, CRM, etc) that are currently separately managed that need to be merged? Are there some things that are now static that will be more dynamic later (for instance, hard-coded pages that will be structured and component-driven)? Does there need to be a taxonomy to bind together the different systems in a coherent way for the systems and the target audience? 

At any rate, you need to define a broad architectural framework (and agree to it internally) before discussing specific scopes with vendors. 

To read more, get the report Standards Architecture and the article Flexibility: get focused. 

Define a path of getting from where you are now to the target state

Just because you paint a nice picture of where you want to go to doesn’t mean you can actually get there. You need to plan how you are going to get from where you are now to where you are going. Why? To validate the project is feasible, to reduce surprises, and to maximize quality. There are many standard activities for migration planning that you should do (such as an inventory and looking at the possible steps of handling content during a migration but some are more specific to breaking down silos (such as merging/splitting taxonomy values).

Onward!

Remember these two things: 

1. Stop building more silos. 

2. When you are going to make big changes like a redesign, always stop to think if you could be doing more by breaking down silos (and this is something to decide before contacting potential implementation vendors so that you have a clear idea of what you want first).