Data is the core of SOA. Without data, the SOA world does not go around. Why do I say this? If you boil SOA down to its lowest common denominator, we are simply attempting to do something that has been the goal of information systems (if not the goal of mankind and human survival) since the dawn of the computer:
(1) Share and move data amongst systems
(2) Transform data into information so it is usable for decision making
(3) Provide better visibility into information throughout the organization
Nothing fancy here, as an organization’s business objectives are dependent on high quality data and anything less will diminish these objectives. Bad data translates to bad results, and leads to the idiom we hear so often in IT meetings: Garbage in, garbage out.
Organizations always need to ensure their data is of the utmost quality to be successful, and if that is not the case, what’s the value of implementing big SOA components? Could we be looking at more lipstick on the pig? What happens if you architect all these big SOA capabilities from the SOA Ecosystem, only to find out the data that is passing through them is bad to begin with? Will your BAM, ESB, or BPM solution fix bad data? Will your BAM, ESB, and BPM solutions provide visibility on when and where the data went bad? Will they help you to find the source of the problem? Unfortunately, big SOA products do not have these root cause analysis capabilities.
Think about this analogy. You are a company who wants to manufacture a product. You invest heavily in a state-of-the art manufacturing plant with large-scale infrastructure to turn out products. After a lengthy implementation cycle to get your plant ready, your infrastructure and architecture is finally complete and in place. Now your plant is ready to start running and turning raw material into finished goods that will be consumed in the marketplace. After a few weeks of processing and shipping goods into the marketplace, you are noticing consumers no longer desire your product. Demand plummets and customer feedback is that your product is of poor quality. After a long and intensive investigation, you discover that the raw materials used in producing your product, were of poor quality to begin with. Due to the dependency on the material, your product was directly impacted and never stood a chance of being successful. Ultimately, because the input was not up to standard, your product and company failed.
This same analogy can be applied to SOA and why CIO’s are hesitant to invest in large-scale SOA projects-- one of the main reasons large-scale SOA efforts fail—a company will build an industrial strength SOA infrastructure, but the data passing through the SOA layers was never of quality to begin with, and hence the information output from the SOA architecture is of poor quality, leading to consumer abandonment. SOA is dependent on the data it receives in the same sense a manufacturer is dependent on the raw materials it receives. An SOA infrastructure is a large investment, just like a manufacturing plant is a large investment. Just like the manufacturer’s goods took a hit in the marketplace, SOA will take the corporate blame when poor data is passed down the line (when the real culprit was the source systems providing the bad data). And most importantly, an SOA initiative will fail, just like a manufacturer will fail, if careful attention is not paid to preemptively analyzing the input before it is processed.
Another way to look at this, is big SOA is potential channel for an enterprise virus. Think about this: when big SOA capabilities provide or consume the bad data, they are helping to exponentially spread bad information across the enterprise because of the number of systems, processes, and people SOA provides for and touches. The bad information gets exasperated across business units, trading partners, and throughout the corporate landscape, leading to misinformed and incorrect decisions. Ultimately, funds and resources are wasted. This is where the SOA practitioners need to be careful so that the value of SOA re-usability does not actually work against them in a viral fashion.
Part 2 of this topic will cover how to avoid the pitfalls of an SOA Virus and ensure data works toward your SOA benefit.
