We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

Are Current SOA Efforts Too Focused on Applications, Versus Data Integration Requirements?

Vote 0 Votes
Joe McKendrick:  An SOA Data Integration Architecture Community has just been launched. Are current SOA efforts too focused on applications, versus data integration requirements?  If so, how can these two disciplines be brought together?

6 Replies

| Add a Reply
  • A very interesting and thought provoking question...

    I would contend that applications are the gateway to data and a defense-in-depth mechanism/control to enforce business and security related rules to ensure the appropriate use and manipulation of data. If one accepts that premise then it implies that application integration is data integration and therefore, SOA is focussed at the proper layer (i.e. applications) in the enterprise architecture.

    That does not mean direct data integration never occurs. Data Warehouses are an example of where this does happen since these are created by integrating, combining, and denormalzing data from many different sources.

  • I think they are absolutely too focussed on the applications. The most fundamental building block of any application is the data. If the data model is wrong or inflexible, the applications will be even more wrong and inflexible and will result in the sort of spaghetti diagrams we see today. Get the data right, access it when it is most appropriate; put business logic (i.e. applications) in front when it makes sense. Even where data models already exists, I would make a strong case for building the sort of objects you want in an abstract layer on top of the data. With good governance, over time this data access can become the primary route to access the data. If or when any older application accessing the data directly disappears, it may be possible to rearrange the physical data model to better map to the business objects one wants to see.

  • Just as the Internet has shown itself to be a speed-of-light carrier of rumors, gossip, and misinformation, so can service oriented architecture within an organization.

    If a SOA-based architecture is delivering inaccurate or bad data, it is a very ineffective SOA indeed. Data is often a last considering in SOA planning, but SOA really won't function properly if it's delivering bad data.

    Neal Fishman, in a book "Viral Data in SOA: An Enterprise Pandemic," likens the effect to a mosquito. A mosquito's claim to fame is that it can pick up viruses and bacteria from any type of organism, and deliver the payload to any other type of organism on the planet. A human and a deer and a bird may not have much in common, but they can all share the same diseases.

    Is SOA, then, a mosquito that can deliver payloads of bad data (what Fishman calls "viral data") all across the enterprise -- pandemic style -- before it can be stopped? Misinformation and bad data have been haunting and hobbling organizations -- not to mention entire societies -- since the dawn of time. Nowadays, of course, information travels at the speed of light, and SOA -- enabling interoperability between all types of applications -- becomes the "host" carrier.

    Data governance needs to be front and center in SOA discussions, because SOA governance ensures that the enterprise is behind the effort. Likewise, data governance helps ensure that the correct version of data is being deployed within the architecture.

  • A resounding YES would be my answer. The core of the problem is why data you are working with is inaccurate or bad. More often than not it's because that data is siloed.

    I did a count on the number of data sources for a client not too long ago - we got up to 13 without trying very hard. It's a serious problem and not nearly enough attention has been paid to it. Solutions like data warehouses were an admirable initial effort, but don't go nearly far enough.

  • Well, this may sound obvious to those who have been involved in SOA efforts for some time but the focus is on the architecture .. evolving from silos to services that can be shared, are modular, loosely coupled and all the aspects of the SOA pattern. That said, it should apply to any aspect of IT that should be enabled as a service...including data services, application services, process services and infrastructure services. I believe if the SOA effort is limited only to what we traditionally think of as applications, we miss the opportunity to really build in flexibility and responsiveness into our IT environment.

    all the points raised above about the issues with data in a typical environment need to be considered and adoption of a SOA approach to data can help but first, data cannot be an afterthought.

  • Kelly has a good point. SOA should be about data first and how applications can access that data. Data will outlast most applications - and it is data that we actually want to integrate with - not applications at the end of the day. This means whenever you design a service, you have to think about abstraction and not just what your own applicaiton needs to access that data...

    sure you can build in some rules etc. however, those rules should be about the data integrity, not rules of how an applicaiton works or uses that data...

Add a Reply

Recently Commented On

Monthly Archives