Tag Archives: Service Oriented Architecture
Rationalizing Silos: Architecture or Politics?
In my last posting, I got on a bit of a soapbox about how every “solution” to the data silo problem seems to proliferate yet more silos—SOA, MDM, and even data warehousing. Of course, that’s because technology alone can’t solve this kind of problem.
Technologists will often point to the need for a coherent enterprise data architecture in order to rationalize all the bits and pieces of data that can otherwise spring up. But we are all familiar with the danger of architectures becoming no more useful than wallpaper—a pretty piece of design work that never becomes materialized.
My belief is that the root problem can almost always be traced back to organizational politics. (more…)
It is “All About the Data!”
It is “all about the data” is the response to this blog post by Joe McKendrick on ZDNet
I couldn’t have said it more eloquently than as described below:
“The data is a pivotal piece of an SOA (most IT approaches, really), and is often under-served by SOA initiatives and projects. Data is diverse, duplicated, dispersed, dirty, and just generally chaotic. You need to rationalize it into meaningful business information for the rest of the architecture to work well. This is the data abstraction layer that Ash mentions. This is not an ESB, but rather a data services layer that feeds an ESB and other components in the architecture.”
In my previous posts and in the webinar that this post refers to, I have stated that SOA promises to deliver business agility by breaking down barriers between silos of applications, and by reusing business services. However, in speaking to a number of customers and prospects, it is becoming very clear that if the data stuck inside silos is bad, is stale, or is inaccurate, it does not matter if the most elegant architecture or technology is used. Data is at the heart of the modern enterprise and as pointed out in the referenced blog, data integration is the “pivotal” piece that can ensure the availability of accurate, consistent and timely information.
Silos are bad. Silos still proliferate. Don’t we ever learn?
For anyone in the integration business, the notion that data silos are bad is deeply engrained in the psyche. It’s plain common sense that having multiple copies of data in different places makes it a lot harder to run your business in a consistent, coherent manner. But we keep committing the same sins over and over again– often with the very technologies that promise to solve the data fragmentation problem—SOA, data warehousing, MDM, to name a few.
First we moved off mainframes to distributed systems. Of course, no one would doubt that the benefits in terms of access to key business data and application functionality more than outweighed the costs of silo proliferation. At least in the client/server era, the number of silos was still somewhat manageable.
But then the internet came along, and everyone rushed to get the latest internet/web application up and running, while at best paying lip service to a cohesive enterprise architecture. As we later learned, this lead to a huge proliferation of new systems and data silos at most companies. (more…)
Viva la Data Warehouse
Okay, so the band Coldplay will never release a song by that title (and I probably wouldn’t want to hear it if they did.) But it would be timely, because despite certain rumors to the contrary, data warehousing is thriving.
We weren’t supposed to need data warehousing in an era of SOA/data services, data federation and other new-fangled technologies. Data warehousing was old-fashioned and tired and a bit boring. But the need for data warehousing solutions just continues to grow– companies aren’t getting less data, and their environments aren’t getting simpler. The discipline of integrating data from multiple systems and conforming it to a common structure so that is can be analyzed and used for business intelligence and reporting is still invaluable. This is not to say that the new technologies don’t play a role– they can greatly enhance data warehousing by providing more real-time data and new ways of delivering data where it’s needed. (more…)
What Does BPM Want? Or, what Does it Really Need?
In my previous post I made a statement that SOA and BPM overlooked the complexity of integrating fragmented enterprise data. As I looked around me across the vast expanse of the World Wide Web, I ran into someone else who says it exactly like it is – Michael Dortch.
In a recent post titled The Big Mash-Up, Continued: What Does BPM Want? in the BPM in Action Blog, Michael says that there are two things that matter the most. In his own words:
- “Need the First: The ability to base every business action, decision, and process on the most accurate, consistent, secure, and timely information available, without fail.
- Need the Second: The ability to answer the “Journalism 101” questions about that information – who’s using what, when, where, why, and how – accurately and completely, on demand at any time.”
He goes on to say that “Processes developed, enforced or revised based on inaccurate, inconsistent, or just plain wrong information are opportunities to make what we called sardonically in my young analyst days ‘career-limiting decisions.’”
So, as I have been saying, when it comes to leveraging the power of paradigms such as SOA and BPM, it does come down to accuracy, consistency and timeliness after all.
What do you think?
Escaping the SOA Trough of Disillusionment
SOA has nothing to do with technology. It has everything to do with defining and managing the business as a collection of service functions and information exchanges. A business may be viewed as an internal organizational unit within a large company that provides services to other other units and consumes services from yet other groups. Or if you view the business as the company overall at the macro level, then you could define and manage the business as a collection of services consumed from its supply chain and provided to its customers.