Integration: Have we gone full circle in this cloud app world?

A look at the way SugarCRM has tackled the issue of mutability

Simon Holloway

Written By:
Published: 16th September, 2016
Content Copyright © 2016 Bloor. All Rights Reserved.

There is a proliferation of cloud based apps being used by organisation which have solved business issues and supported the needs for business to work in this mutable world, where employees need to be able to access information on anything, anywhere and at anytime. This looks like the IT world has been responsive to business needs and that is quite correct. However the issue comes when one part of an organisation wants to pull together information from different apps which come from different vendors to produce a new report. This problem is then pushed to the IT manager to solve. Talking to Larry Augustin, CEO of SugarCRM, the other day he explained that the majority of apps in the marketplace although they have public interfaces, they do not give access to all the information that the app uses. For instance, the relationships between data or the ability to look at the log of transactions may not be available in a format that makes integration easy or perhaps even possible. So what we have is a vertical app stack, similar to the islands of data issue we faced in the recent past, where we are locked in.

So what can we do?  Firstly organisations have to realise that this going to happen - past experience tells you so! One approach that an organisation can take is to put together a common data model for its key data. One of my consultancy assignments in the past was to work for the Police Information Technology Office (PITO) in the UK on the National Police Systems. One of the key elements in the design of these systems was that there was a common data model that defined the key data that was likely to be shared between the different systems. This meant that name, definition of what the data item meant, the format and size of the data were all defined. By having this common data model, Police Forces were able to work out how their current systems could be integrated or replaced with a new national system. I know that this happened because the consultancy company I worked for at the time was involved in helping a number of forces do this. The concept of managing data corporately was the core work of the Data Administration Working Party of the British Computer Society. ISO and BSO also developed a set of standards based on SQL technology to hold this common data with its associated rules and processes and security access; call Information Resource Dictionary Systems (IRDS). I was a member of both working groups working on this, which gave me the following insights into the issue:

  • Managing data as a corporate resource is often a matter of subjective opinion, so an organisation thinks it has addressed the issue and then finds it hasn't.
  • Cultural differences can lead to misunderstandings, so one has to use very clear language when defining terms.
  • It will not be possible to relate everything if vendors do not make their definitions clear as well as available. I can remember the first time looking at an SQL table in a well-known ERP package and finding all the terms were in German!
  • The format and size of key data items like 'Product Number' can be infinitely different.

So how else can we solve this issue? Augustin explained that when SugarCRM brought out thir latest version, Sugar 7, they made all their APIs public. Now if all vendors did this then it would make it much easier for IT departments in organisations to solve the business needs of pulling information from different sources together - as long as they know that they are using "apples" with "apples" to make the integration happen and not "apples" with "oranges". This can only happen if you have a place where you can relate for example one customer number in one format to the same customer in another system which has a different format. In the case of calculations, we also have to be aware that a calculated field in one app may be different to the formula used in another and here we need a rule to handle the conversion of one to the other.

The standard world is also helping business as there is a proliferation of industry business models based on XML. These vary from the German based development of Industry 4.0 which facilitates the vision and execution of a "Smart Factory" to the "Business Reference Model" which is one of five reference models of the Federal Enterprise Architecture of the US Federal Government that describes the business operations of the Federal Government as independent of the agencies that perform them. There is an issue that standards can overlap and, if coming from different places, may use different semantics. For more details on the number of Business Models around, Bloor will be providing an overview of these standards as part of its Mutable initiative.

My colleague, David Norfolk, Bloor's Practice Leader, Development and Governance, when I discussed this situation with him said, "Well, first, I think you identify a real issue. Integration became an issue in the 1990s for client/server applications, because mixing apples with oranges leads to disaster - even if you call both of them "citrus fruit" and make them fit into the same field definitions. I think that the same will happen with many cloud applications - once a company tries to integrate two cloud apps and finds that what one calls "customer" (a fully authorised, credit-rated, client, perhaps) is different to what another calls "customer" (anybody who accessed the app on the web, perhaps). Secondly, this matters because there is huge scope for expensive mistakes again - the IT industry is the only one that makes 'reinventing the wheel' into 'best practice'. Actually, I think the 'Mutable Enterprise' will need no-code model-driven development based on automatically quality assured (complete, consistent, ie coherent) data, process and decision models. And, as you say, open and verified APIs (with assurance that APIs aren't bypassed."

One of the other points that Augustin raised which I felt was interesting was that when Sugar v7 was being designed, they developed their app front-ends as if they were client server applications. By doing this he explained that they made the majority of the work happen at the client device thus overcoming data bandwidth issues and time delays in having multiple exchanges with the server wherever it is in the world. Augustin mentioned that Sugar developers were providing through what they called "Premium Cloud" - a cost option - the ability for their clients to have SQL access to data held in their cloud database. One of the pieces I like about Sugar in the cloud is that each client has their own database and not as in the case in many cloud apps a single database for all clients with tags to separate client's data. The other key piece of the way Sugar works that I like is their use of workflow and the way they help their clients manage the complete client lifecycle from capture through to after-sales service.

Looking at what SugarCRM have done in their new version, one can see that they have made good progress to solve many of the issues that I have discussed in the first part of this article.

  • A strong candidate for organisations with a broad-based customer-engagement strategy that are looking for a more modern and appealing user experience at an attractive price. The user experience is delivered by presenting information in an intuitive way. On a tablet or PC the user will see relevant information to support their particular role, presented in three panels. A context panel displays customer information in a business-card format or list of contacts, opportunities, cases, or campaigns. A collaboration panel enables individuals to share information.
  • SugarCRM's pricing strategy supports wider adoption. SugarCRM offers Sugar PurePrice, a commitment to transparent pricing, with no hidden fees or forced upsells to more expensive solutions. There are three editions depending on the level of functionality required by the business. This ranges from $40 per month for Sugar Professional, $65 per month for Sugar Enterprise, and $150 per month for Sugar Ultimate.
  • Sugar supports a variety of deployment models. Sugar supports on-premise, private and public cloud, and white-label OEM deployments, as well as those through key cloud platform partners such as Amazon, Rackspace and Windows Azure.
  • Sugar is highly scalable, functionally rich, extensible, and attractively priced. This gives it the potential to serve a broad range of enterprise sizes from small through to large in both the private and public sectors and in all regions of the world. The company's partnership with IBM allows it to be used at the large enterprise level.

David Norfolk said, "Bloor sees Mutable and Cloud as the way forward but, as with anything else in IT, you can do them wrong. And you only find out you've done it wrong down the line, when you get to maintenance and integration. As you say, we have been here before. Which is why we have a 21-step path to Cloud in CIF - all the things you have to get right as part of putting TRUST in Cloud and which many people overlook."

Post a comment?

We welcome constructive criticism on all of our published content. Your name will be published against this comment after it has been moderated. We reserve the right to contact you by email if needed.

If you don't want to see the security question, please register and login.