This is my first ‘back-to-reality’ blog in a while. With so much talk about Web 2.0, social networking, visibility, accountability and transparency, lately it’s easy to lose sight of some of the practical day-to-day problems we have to constantly address. And if there is one persistent problem that won’t go away (and seems to be getting worse), it’s software “silos.”
In the physical world, silos are nicely contained structures that hold and protect things from the elements. There’s usually only a single way in and single way out. In software silos contain data we need but also make it difficult to get at.
Sadly, too much software ends up becoming a silo. That’s because requirements almost always revolve around solving a specific set of business problems at a specific point-in-time. Later, as the business grows and requirements change, we end up with a bunch of siloed systems that don’t talk to each other and most likely never will. In the end, we’re forced into the Excel-based manual mashup based on multiple systems of record and a copy/paste approach just to get basic-but-important answers from the data deluge.
But it isn’t hopeless. The Smash/Mash/Share approach is a quick way to build on your current architecture and do it in an agile, forward-thinking way.
Let’s start by examining the real nature of problem through a real-world example from one of my customers (who shall remain nameless). Let me know if any of this sound familiar:
I have a ten year old HR system that contains valuable information I use every day. Suddenly I have a new requirement to match my HR data with my sales forecast data (and related production resource needs) to get a picture of my future hiring needs.
I can’t get at the HR data without going through clunky, ten-year-old application client-server UIs. I’m forced to copy and paste the data into Excel. Similarly, my sales data is in our new custom Sales Automation system, which is only Browser based and has no export facility.
And once all my copying/pasting is done, I have copies of data that are already beginning to diverge from the systems-of-record they were copied from. Any real projections I put together are instantly suspect.
And if you think your warehouse/datamart, portal, or middleware systems will solve this problem, think again. In my experience, they have become simply more silos.
You’re going to have to look to newer Web 2.0 technologies that are built around agility and speed and don’t require months and years of required IT development. Even ‘America’s CIO’, Vivek Kundra has started looking to Web 2.0 solutions for answers.
Fortunately, IT has been using Service oriented architecture (SOA) as an architectural technique to expose silos as services. This doesn’t entirely fix the problem, of course, because only a Java/Flex/Visual Studio developer could consume a SOA WSDL. Now you just have silos with nicely standardized doors. But it's a step in the right direction.
That’s were mashups fit in. I like to think of SOA as silo smashers and Mashups as SOA mashers. Deepak Alur wrote a great blog that described “mashables” as services (like the aforementioned SOA WSDLs) that have been made mashup-ready.
Last, it wouldn’t be ‘Web 2.0’ if we didn’t enable easy sharing and collaboration. Lately it seems that everyone has agreed the best way for users to see and share data is via Widgets. (Of course, widgets that sit in front of mashups are better called ‘Mashlets’).
So there you have it: Silos are meant to be smashed. SOA is meant to be mashed. And Mashups are meant to shared. Like this:
The Smash/Mash/Share approach results in an agile platform from which users can solve unforseen problems in a agile, open way. This kind of information ecosystem lets people create and share in a way that can ultimately result in a powerful network effect.
Silos: 0, Smashers/Mashers/Sharers: 1 (and then some).
Read More...
Summary only...