Bill St. Arnaud points me to
Blocks of SOA: Building services with common symbols
"The cabinet system we have in Canada is built on the intentional design of silos," says Turner. "Each set of programs is enabled by legislation and statutes, and each organization supports a minister who's accountable to Parliament for that set of programs. Natural silos are designed into the system, so when you try to apply common technology across departments, it goes against the grain. It almost comes down to, do you want efficiency or accountability?"
The tendency to treat SOA as an IT project rather than a strategic architecture is a consequence of these silos, says Kuhbock. At a recent presentation he made to government IT officials, many of them said they had the same central issue: "They can do SOA in their own compartmentalized area, but they can't get it broadly driven; so they're just stuck in their silos again. It's like architecting a town, district by district, without thinking about how the whole town will interact, or mapping out the whole community."
On the other hand, I'm not sure that trying to do a government-wide SOA wouldn't get us tangled in techno-bureaucracy beyond belief. I think the most value comes in getting individual departments and organisations to use the same SOA terminology and similar methodologies, so that we can interface well at our edges. SOA has a lot of value, but I don't think you could successfully use it to create a Grand Unified Theory of Government IT. My organisation sells subscriptions worldwide to scientific journals, and Revenue Canada (or whatever it's called these days) collects taxes from Canadian citizens - there are not exactly huge IT overlaps in these two business activities.
Comments