Jeff Schneider, CEO of MomentumSI, took a stab at defining the relationship between IT silos and Service Oriented Architecture.
I think of a silo as a system or information repository that solves a problem for some portion of the enterprise, while leaving other areas responsible for solving the same or similar problems on their own. Silos causes duplication of systems, business rules and data.
Jeff is certainly not the first one to explore this relationship. Dave Frankel, Leads Standards Architect at SAP Labs defined SOA as:
SOA is about reorganizing IT assets into loosely-coupled components. Composite applications, built with tools that constitute an essential part of a SOA environment, orchestrate multiple components in unique ways, thereby spanning and ultimately breaking down the rigid IT silos that hamper integration. They require multiple levels of integration and cleansing, resulting in increased maintenance and operational expenses. In general, silos are bad.
More recently, Joe McKendrick pointed to a report detailing how the Farm Credit Canada (FCC), a provider of financial services for Canadian agricultural businesses employed SOA methodologies to restructure itself from a silo organization, with each silo supporting applications for a particular business function, to a “service-centered” model, where applications are constructed according to service oriented architecture (SOA) principles. He noted from the report that the transformation was a six-step process.
1) CEO driven: "The CEO initiated a culture change initiative that underpinned his vision of creating a customer-centric organization."
2) Process revolution: "The organization focused on what needed to be done to integrate the corporation’s processes and systems to enable it to provide a great customer experience."
3) IT itself was transformed. "The CIO assessed the current state of the IT organization, and all current IT projects were halted while this was done." Siloed approaches were abandoned in favor of an architecture-centric approach supported by SOA principles.
4) A proof of concept was undertaken "by implementing a carefully chosen business process with SOA."
5) Governance: "The organization undertook a detailed redesign of other processes, and working through the governance issues of managing a process-driven IT organization."
6) The benefits to date of transforming the IT function and its technology were articulated. The CIO identified a range of benefits, from improved communication between the business and IT, to the development of reusable IT assets.
Jeff notes that in general:
Almost every large organization has a number of silos that exist for a variety of reasons including:
- I.T. funding occurred by business area and each area bought/built their own (silo) systems
- Mergers or acquisitions caused duplicate (silo) systems
- Poor visibility or planning across the enterprise led to unintentional silos
... [yet] these companies [do] not perform "Silo Analysis".
His post provides practical steps to perform this analysis:
- What are our silos?
- Is there a good reason for the silos?
- Which silos do we want to end-of-life?
- Which silos can we practically kill (politics, investment, etc. )
- Will SOA lead to "silo services"?
One of the key question in this list is the last one: Will SOA lead to "silo services". Jenny Ang and her colleagues had already identify this as a potential SOA Anti-pattern.
Eric Roch also asked the question earlier this year:
how do you ensure that SOA then does not create a new set of silos across business units?
Eric recommends to
- build a Strategic Services Blueprint (the future Business Services Catalog)
- form a cross-functional SOA Steering Committee composed of the SOA sponsor, a lead architect from each functional-application system and an enterprise architect.
Joe McKendrick sees two interconnected levels to addressing the problem:
- First, on a technology level, is federation. One out of four companies have already moved to a federated infrastructure to support multiple instances of ESBs or intermediaries. Trying to manage a growing SOA through a single ESB would be unsustainable.
- Then, on a business level, there’s governance. Effective governance will make the difference between ending up with a tangle of services
Jeff concludes:
Silo Analysis must be ingrained in the mind of every business analyst, architect, developer and governance professional. Failure to teach our next generation will lead to more silos - they'll just be written in Ruby instead of Java...
Jeff has raised an important set of questions that every SOA governance organization should ask at some point. Did you consider Silos during your SOA implementation? Did you successfully avoid building new Silos because of the services you had implemented? How does your BPM or MDM strategy intersect with Silos?