It was not but last week that I discussed the issues around the consolidation in the world of SOA, and now we have another example. This week Red Hat decided to acquire MetaMatrix. "Red Hat, Inc. (NYSE: RHT), the world's leading provider of open source solutions, today rolled out its middleware strategy to drive the next migration to an Open Source Architecture with the announcement of an agreement to acquire Me It was not but last week that I discussed the issues around the consolidation in the world of SOA, and now we have another example. This week Red Hat decided to acquire MetaMatrix. “Red Hat, Inc. (NYSE: RHT), the world’s leading provider of open source solutions, today rolled out its middleware strategy to drive the next migration to an Open Source Architecture with the announcement of an agreement to acquire MetaMatrix and the introduction of new JBoss offerings. Last month’s delivery of Red Hat Enterprise Linux 5 continues the Unix-to-Linux migration that has returned millions of dollars in value to customers over the last five years. Now, Red Hat is presenting the next high value migration opportunity, which Red Hat believes will deliver even greater cost savings to enterprises: moving siloed legacy applications to JBoss Enterprise Middleware.” MetaMatrix is a data services/data abstraction technology company. Clearly, Red Hat is looking to round out their application server offering to compete with the likes of IBM, Oracle, and BEA, that all have data services layers. However, what’s more interesting is that this reduces the world of best-of-breed data services players down to a single company…Composite Software. In the world of data services, data abstraction, federated query, there were a few players including Avaki, now a part of Sybase, Composite, and MetaMatrix. Those deploying SOAs will have two choices when it comes to data services/abstraction: Go with a large stack player where the data service layer is coupled to the core product(s). Or, go with a best-of-breed player allowing you to mix and match the technology to form your own SOA solution, customized to your needs. I have not been shy about telling you that in most cases the best-of-breed approach is typically preferred considering that SOA problem domains are all different, and need unique customized technology solutions. Thus, you’re using governance technology for one vendor, services development technology from another, a security solution from another vendor, and data services technology from still another SOA player. While it may seem easier to just say yes to all components of a large stack player, I’m finding that in many instances they meet all of the requirements in some areas, and few of the requirements in others. Thus, you have to consider the tradeoff of proper and correct for your issues, versus the convenience of purchasing all components from a single large stack player. Data service layers are important to SOA when you consider that they can decouple the core services, composites, and processes, from the underlying physical databases. Thus, you can change the services without forcing changes to the underlying database schemas, and change the database without forcing changes to the services. Therefore, you increase your ability to create an agile architecture, the primary reason we’re doing SOA in the first place. I suspect that Composite will see an up tick in the interest in their technology, now that they are the only major best-of-breed data services player in SOA town.   Software Development