Data is Fundamental to SOA Success

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Richard Manning's Blog | March 21, 2007  12:52 PM | Comments (3)

I've been in this industry for more years than I often care to consider. Through all the industry waves and trends of the last few decades, I have found it interesting, and telling, that one thing has remained constant: data. If knowledge is power, it is only as powerful as the information and the data upon which it is based. SOA is no different (and neither is Web 2.0, or for that matter, any other technology wave). The data challenge has been, and will always be with us. Though with each passing wave, we are better equipped to manage the data challenge.

So, what is this data challenge? The data challenge is, simply stated, getting the right data (what) to the right person/system (who) at the right time (when) in the right way (how) to the right place (where) to meet their needs (why). Understanding what it takes to answer and address the data challenge will significantly improve the overall value of your SOA Reference Architecture and the subsequent solutions that build upon it. Answering the data challenge will also reduce the overall costs and complexity of your SOA efforts. Failure to appreciate and address the data challenge will result in complexity, a more difficult SOA transformation effort, lower returns on your investment, longer timeframes to realize return on your investment value, higher costs, increased TTM, more work and eventual rework to name just a few.

Upon what do I base these statements? Experience, both my own (22+ years), those of colleagues past and present, successful customer engagements, customers who call for assistance in after they run into trouble with their SOA transformations, and finally, what I've read in the industry press.

If your organization is ready to start, or has already started, an SOA transformation and/or adoption process, be sure you take a strategic, holistic approach which includes the Data Services Layer. If SOA is new to your team, you should also consider engaging experienced SOA consultants from your favorite vendor, system integrator or consulting firm. Your consultants should have a proven track record of SOA success. Their experience will help your organization avoid the challenges and minimize the risks of SOA, ensuring a better transition to SOA. Be sure to ask about their approach to data management in SOA as well as expertise in information modeling. If they don’t have a reasonable approach to enabling a Data & Information Access Services Layer or downplay its value, be concerned! BEA Consulting offers a number of SOA / EA consulting services including Data Services, see the BEA Consulting SOA site for more information.

To create your Data Services solution, you should consider using open standards-based, industry leading tools, technologies and products that provide data services layer and canonical data modeling capabilities for SOA such as BEA's AquaLogic Data Services Platform aka ALDSP. Using enterprise-class products, such as ALDSP, will provide you with the necessary tools, technologies and environment to design and deploy your data & information access services layer and canonical data model efficiently and effectively.

(In case you missed it in my bio: Yes, I work for BEA. In fact, it was ALDSP and the value placed on information modeling in SOA that were among the leading factors in my joining BEA two years ago. I’ve seen other technologies and products applied to data services realization, though none match the power and completeness of ALDSP. ALDSP allows you to work smarter not harder; where you focus on delivering business/IT value, logical modeling, richness of design and efficiency not low-level details of what can hardly be considered alternatives. IMHO. Now I don't expect everyone reading this to take my word for it; I recommend you download an eval copy of ALDSP and see for yourself.)

I will go as far as to say, that if you are planning an SOA transformation, your SOA Reference Architecture model must include the definition of a Data Services Layer (which also includes the definition of your canonical data model). The Data Services Layer should be one of the first, if not the first, layer to be designed, developed and deployed. I trust you will find (and be able to provide supporting metrics) that a well-defined, well-designed Data Services Layer will make your subsequent SOA solutions easier, more apparent and increase your reuse, quality and capabilities while reducing costs and TTM. All other layers in your SOA Reference Architecture, (including the presentation, enterprise service bus, business process management, shared services, composite applications and more) will (usually) reuse and benefit from a well-designed Data & Information Access Services Layer more than nearly any other single investment area. A well-designed Data Services Layer provides a reusable, shared model of the information of your enterprise; it is your data and the ability effectively access and manage it (answering: what, where, when, who, how and why) that enables your enterprise to achieve the promised business and IT agility and fully begin to recognize the benefits of SOA.

If you have questions, have experienced the value of addressing the data challenge in SOA / Web 2.0, or you disagree with my position that Data is Fundamental to SOA Success, please comment; I would like to hear about your thoughts and experiences with Data in SOA and/or Web 2.0. Thank you.

Comments

• Richard, we'll certainly read the article. If you are interested in what we are doing in that area I'm more then willing to share that with you. René

  Posted by: renedv on May 4, 2007 at 2:04 AM

• Rene: I agree. There are many model layers, presentation, business process, business activity, data, etc. There are pro's & con's with starting in any one. Knowing how data services will be used by other layers is often helpful as long as it doesn't overly constrain the solution. The beauty of logical data services is that they allows for various customizations independent of the physical sources and for intermediate abstractions, as well as application specializations. I have submitted an article to Arch2Arch that goes into more detail on this topic. I anticipate the article's publication in the next few weeks. Thank you for your comments. Richard

  Posted by: rmanning on May 3, 2007 at 6:18 AM

• Dear Richard, fully agree! As datamodeling veterans we invested heavingly in a product called CWD4ALL (www.cwd4all.com). we are now investigating what we need to do to create value in a SOA environment. Everybody talks about BPM (Business Process Modeling), almost nobody about BDM (Business Data Modeling) and further. I learned personally from Charlie Bachman (Bachman Information Systems, the father of diagramming) that it doesn't matter if you start with data or process models, but finally you need both. We loved to start discussing and working with people that understand the beauty and need for data modeling (call it master Data Mgt, Ontologies, Data Services Layer) and the needed integration/interaction with BPM. Love to hear your opinion Regards, rene

  Posted by: renedv on May 2, 2007 at 9:08 AM