We’ve been surprised (pleasantly I might add) at the response we have received to the introduction of Safyr’s capability to reverse engineer metadata from Salesforce systems.
It is rapidly becoming our second most popular ‘package’, SAP of course being number one. Why should this be? All the other environments we support (SAP, JD Edwards, Oracle E-Business Suite etc….) have thousands of tables and tens of thousands of attributes, whilst a standard Salesforce system is around 250 tables. That’s less than 0.3% of the number of tables in a typical SAP system! In addition, Salesforce has its own data modelling capability (called Schema Builder), allowing the developer to choose which tables to show in a diagram. As with most things in Salesforce it’s easy enough to use. Given that a lot of Safyr® customers use Safyr in conjunction with a modelling tool like ERwin, ER/Studio or PowerDesigner, the presence of a data modelling capability in the Salesforce development environment would seem to negate the need for Safyr especially given the relatively low number of tables. And yet we are selling Safyr to Salesforce customers and have a growing level of interest in that version of our product.
So, where is the problem with accessing and understanding Salesforce metadata?
Well, firstly what we’ve learned from customers and partners is that it’s not quite as ‘black and white’ as it first appears and there are a number of factors which come into play.
Numbers of Tables
Yes, it is true that a standard Salesforce complement of tables is around the 250 mark. However as customers look to the product to fulfill more of their business requirements it is becoming normal to extend the standard set of tables by adding their own and/or to buy third party packages (such as Rootstock and Financial Force), which are based on the Force development environment. The impact of this is to dramatically push up the numbers and we’ve seen customers who have systems that are around the 1,000 table mark. Now that’s still small by SAP (or even Siebel) standards, but imagine having a data model of 1,000 tables – that is moving into a world where much more rigorous understanding and control of the data design is essential to the effective delivery of information management projects.
As mentioned earlier, the Salesforce schema builder can be used to model tables in the Salesforce environment. One of its problems is that it doesn’t allow any table to be selected, just a sub set. Things like Opportunity and Contact can be selected and represented in a diagram, but there are a lot of the more minor tables that just don’t appear in the list of available tables. A case in point is an intersection table that links Opportunity and Contact – it’s called ‘Opportunity Contact Role’ and as its name implies links the two tables together with the primary keys of the two ‘parent’ tables being foreign keys on the intersection table (see Figure below).
And whilst the Schema Builder is very easy to use, the diagrams cannot be saved. There is also no concept of grouping tables into areas of interest (a ‘Subject Area’ in Safyr terminology) which would allow you to save different representations of key tables in manageable groups.
Numbers of Salesforce Instances
So far we have more tables than we might have initially thought, a less than ideal modelling environment and on top of that, many customers have multiple Salesforce implementations. We already have customers who are multi-national organisations having a different Salesforce system in each country (or region). Imagine 10 different Salesforce and Force applications, all of around 1,000 tables, all different. This is beginning to look like a significant data management headache.
Salesforce has become a critical enterprise application
Perhaps the most striking feature which results in customers seeking out a solution to the growing data complexity of Salesforce and Force applications is the fact that these systems are now mission critical for many companies, large and small. This means that organisations also need to maximise their investment in them by ensuring that they become a fundamental part of their IT and data ecosystem – by sharing data through integration to streamline processes and reduce cost, by providing data to data warehouses for analytics and business intelligence applications to improve reporting and decision making, or to meet data governance obligations. If this is in fact the case, then having a solution which helps to meet the challenge of understanding the metadata in these applications will be vital. More information about Safyr for Salesforce is available at our website.