Organizational silos thwarting IT architecture goals? Put away the sledgehammer.
At a local Oracle user group event, I spotted a familiar face. “What are you working on?” I asked him.
For the next several minutes, I heard about an infrastructure modernization project he and his team were involved in. In general, the project was on track and proceeding with limited aspirin consumption. But there was one headache-inducing issue that posed an obstacle to the project’s overall success: the company this person works for has five separate development teams, and among those teams there isn’t a great deal of cooperation.
So yes, another conversation about silos.
Organizational silos are the bane of effective IT architecture. The goal of that architecture, of course, is to consolidate resources, reduce complexity, and better align IT with the business. Ironically, the last of those three goals may have provided the foundation for some silos.
The tighter alignment of IT with the business can take on the qualities of a badly tailored suit—so tight that it can impede the agility of the overall organization. From within a silo, that constriction may not be apparent, however. In fact, inside the silo, things may be quite comfortable, and the people enjoying that comfort may have little incentive for change.
Inside the silo, things may be quite comfortable, and the people enjoying that comfort may have little incentive for change.
One step toward changing the silo mind-set, then, is understanding what makes silos so appealing. “We need to acknowledge the existence of silo thinking,” says Oracle ACE Director Hajo Normann, a service-oriented architecture (SOA) and business process management expert with Accenture. “I would go even further and say we need to embrace it.”
According to Normann, the silo can be a congenial place, where people may enjoy a sense of freedom and creativity, or at least familiarity. Working outside the perceived protection of the silo can present an imposing alternative that itself is thought to be a restrictive, rule-bound environment. That perception is not entirely without basis.
“On the other hand, a centrally governed software factory relies on standards, shared best practices, and strict conventions for names and design choices,” says Normann. “So we are facing a dilemma. We are doomed if we just demonize the silo.”
Rather than tearing down silos, the better strategy is to focus on building bridges between them.
“One should work across organizational boundaries looking for commonalities and seeking ways to identify win-win opportunities,” advises Oracle Enterprise Architect Eric Stephens. “Don’t let the org chart hinder your collaboration.”
To that end, Oracle ACE Manuel Rosa, business manager for SOA at Link Consulting, suggests approaching the issue from an information perspective. “We need to identify how we can define a common model—the basic functional and business concepts that usually cross different silos,” Rosa advises.
From there, it’s a matter of finding ways to leverage that information so that one silo sees the advantages of connecting to other silos. “Find a way to highlight the benefits of such cooperation between silos,” Rosa says. “Put reward mechanisms in place to promote synergies and the reuse of information and assets, and define structured procedures and processes that can guarantee long-term cooperation without adding disruption.”
Of course, if any of this were easy, you wouldn’t have read this far. The need to evolve beyond silos is clear, but it’s also something that you, as an architect, aren’t likely to accomplish on your own.
“If organizational leaders want to foster more cross-silo collaboration, incentives need to be aligned that encourage folks to work together,” Stephens emphasizes. And that’s going to require the involvement of those who are in a position to enact organizational changes.
“This fight should be backed up by the highest levels of the management hierarchy,” confirms Normann.
Bridging those silos might be a long slog. But somebody’s got to do it.