Finally, the MDM team needs to consider how many environments it maintains.  Often, 2 development environments are required.  One is a replica of production, which is used to work on production hot fixes and quick development activities as a result of production findings.  The other is the environment that MDM is doing its ongoing development on. From the development environments, MDM maintains the path-to-production which incorporates all other pre-production environments.

It could come up as to which MDM environment application development environments will use and who will maintain those environments.  If applications are going to use one of the MDM environments, there may be conflict with MDM's development.  If a copy is used, space must be procured and that copy must be managed.

There are also MDM workflows, where we find a ton of confusion in regards to who will update them, since they are very focused on the business.   If the project is providing data to MDM, the data will need to be sourced.  If an ESB is present in the shop, its utilization must be considered. 

Pre-production testing will likely need to involve multiple teams.  Certainly, this is nothing new as many projects have had this need before.  However, it increases the need for coordination of personnel, environments and testing resources.  It is likely that each team will have its own set of tests, as well as the overall integrated test.

And finally, let's not forget good old production support.  MDM normally needs to be on a 24 x 7 x 365 support schedule.  Shops vary in terms of activity that might occur with MDM data overnight.  Regardless, production support carries with it all the usual concerns of utilizing and educating existing first level support personnel and creating the escalation plan.

I spoke with Chuck Berger, CEO of ParAccel, today about the Teradata acquisition of Aster Data.  "ParAccel is the lone remaining stand-alone analytic appliance" said Chuck.

Chuck sees this as validation that companies have more data than they can process and that traditional architectures are not optimized for processing huge data in short amounts of time.  "Companies are feeling the frustration about the value they are unable to realize from their data."

"HP, IBM, EMC and Teradata wouldn't be making high value acquisitions if they weren't seeing demand" said Chuck.  He also talked about the "natural enemies" that these acquisions were making and how ParAccel was staying away from making natural enemies.  As an example, Chuck said "All the BI guys are leary of IBM because of Cognos."  Sales teams will bring in their overlay representatives to deals and this will keep doors open to ParAccel.

ParAccel's strategy is not changing.  It is to "excel with the best product and maintain independence.  Create no natural enemies.  Many still need partners in the analytic space."

Finally, ParAccel will be free to continue to pursue "innovation and not integration" as a result of the merger activity, according to Chuck.

We should have seen it coming, but Teradata announced its investment (11% acquired in September, 2010) in Aster Data is going to the level of acquisition.  Aster Data has an MPP implementation of a columnar data store and integration with MapReduce.  Teradata has been quiet on the columnar and MapReduce fronts and now we know why.  Columnar is undeniably important going forward into the analysis of massive data volumes.  Co-existence with row-oriented databases is already happening. 

We find MapReduce in those fringier cases where companies are going beyond needing to store human-generated structured data and into computer-generated data and unstructured data.  Started by Google and implemented by many who are Google-like in their need to manage data, MapReduce represents a new market.  It's one that is different from an EDW profile market where known queries against static data occur.  It's also one where many companies will find themselves in during  the next few years.  Teradata had already formed a relationship with Cloudera to acquire data from Cloudera's CDH platform.

A Teradata EDW and an Aster Data store could easily co-exist at a client and handle different workloads.  While both would have query workloads, Aster Data could use its advanced real-time data capture capabilities to feed summaries to the EDW.  Before I go too far with this, Teradata did say the code bases would be separate for the known future.  This is not dissimilar to Microsoft with their PDW (formerly the DataAllegro product).

You also need to recognize EMC (Greenplum), HP (Vertica), SAP (Sybase) and IBM (Netezza) mostly have multiple data stores, but all have analytic data stores on their hands!  Teradata already had other appliances, having spent the bulk of the last 2 years rolling out its appliance line.  And Aster Data was not just for Hadoop-level data need.  It's managing several single terabyte and below implementations.  The possibilities just with Teradata, the company, just exploded. 

After previous market activity like this, many a company's sales and marketing teams can get unfocused and even in serious competitive mode.  Teradata is very well run, but let's see if they can manage this challenge.

As Hadoop and its ecosystem matures, the game is changing from an era of not-enough to an era of plenty and a need to sort through the offerings.

Let us finally say Teradata is full stack and sees its immediate future as a full stack specialized player, alongside the better-known big players, offering an unparalled focus on information management.