Loosely Coupled or Tightly Integrated Enterprise Applications? Why Should a CFO Care?

It seems lately I have been hearing a lot about “loosely coupled” business applications. It started about a year ago at Infor’s customer event (Inforum) and then continued at SAP’s SapphireNow. More recently, with SAP’s introduction of Financials OnDemand, I heard it again. Financials OnDemand is a derivative of SAP Business ByDesign, a cloud-based, tightly integrated suite (that some might call ERP). SAP pulled out the financials that were previously embedded in Business ByDesign so they could stand on their own and be “loosely coupled” to other applications.

But is this what its customers and prospects are looking for? That’s hard to say because it is very unlikely its typical prospect or customer really understands the intended “benefits” of loosely coupled.  In fact, when you start talking about “loosely coupled” to CFOs you are likely to produce that glazed look that says, “I don’t know what you’re talking about… and I don’t really care.” If you refer to “loosely coupled” in contrast to “tightly integrated” you might get a glimmer of understanding, but not an immediate acceptance of the concept.

CFOs might intuitively understand the value gained from tightly integrated applications, particularly in reference to an integrated suite of modules like ERP. After all, who wouldn’t want a complete solution, one where all the pieces just sort of fit and work together, with no integration effort required and no redundant data? While there might be some inherent value to having a loosely coupled solution, that value is not intuitively obvious to a CFO. Yet the opposite is true for both Infor’s CEO Charles Phillips and representatives of SAP, including former SuccessFactor CEO, now SAP’s chief “cloud” guy, Lars Dalgaard. They see enormous value in loosely coupled. As a result they either don’t see a need to explain it, or they have difficulty in explaining something they just intuitively “get.” Either way, the message is just not very clear to your typical financial executive.

So let me try to explain. The biggest reason “loosely coupled” might be of very significant value to a CFO is because things change. Markets change. Companies expand (or shrink). Software is enhanced. Technology innovation happens.  In fact, technology innovation often results from change but is also often the catalyst for change. Yet responding to change is hard.

Let me give you an example that should resonate with a CFO. Let’s say you are the CFO of a mid-size manufacturer who has helped your company expand over the past 10 years.  You implemented an ERP solution back when you were small and your accounting needs were rudimentary. You chose a solution for its strength in managing inventory and production. While you started out operating from a single location, you have expanded globally and now operate in 6 different countries around the world. While the financial modules of your ERP met your needs when you first implemented it, now you struggle with compliance and tax regulations, multiple legal entities, multiple currencies and consolidation. This is a very real scenario. Our latest Mint Jutras survey on ERP indicates 75% of companies today operate with more than one location. Even small companies (those with annual revenues less than $25 million) have an average of 2.6 locations and this average grows to 7.5 in the upper mid-market (revenues from $250 million to $1 billion).

You’d like to move to a newer, more feature-rich accounting solution, but your ERP is still satisfying the needs of manufacturing and since you are continuing to grow, you don’t want to disrupt the business by ripping it out and replacing it. The very thing that attracted you to your solution is now holding you back. Because it is tightly integrated, you can’t just replace a piece of the puzzle without replacing the whole thing.

To make matters worse, your older ERP solution is not really meeting your needs for customer relationship management (CRM). This is not surprising. While the footprint of ERP has been steadily expanding over the past 10 years, the needs of sales and service organizations were not front and center from the beginning. If these needs had been met with early versions of ERP, companies like Salesforce.com would never have taken off like they have. Maybe you too are considering adding a stand-alone CRM to the mix. If so, SAP might be pitching its Customer OnDemand solution in addition to Financials OnDemand.

So is this building a case against tightly integrated, in favor of stand-alone solutions that might need to be integrated? Not necessarily. In a tightly integrated solution there is only one of anything – one chart of accounts, one customer master file, one item master, one supplier master, etc. But these master files are shared across different functions. Purchasing needs to access the supplier master to place a purchase order. But accounts payable also needs a supplier master in order to make a payment. Sales and order management need to maintain information in the customer master, but accounts receivable needs a customer master to apply cash receipts. Pull the accounting solution out and you still need the suppliers and customers. Does the new accounting solution have its own supplier and customer files? Does this mean maintaining two of each? Does the new CRM add yet another customer master? If so, how do you keep them in sync? Or maybe you don’t. But this adds all sorts of new wrinkles.

“Loosely coupled” applications could very well make your life easier. But what’s the difference between “loosely coupled” and what used to be called “best of breed?” This is where it gets harder to explain and I am not entirely convinced all vendors that claim to deliver it are talking about exactly the same thing. It took SAP several tries before I really saw the difference, and I live and breath this stuff. Your typical CFO doesn’t.

In trying to understand SAP’s definition of “loosely coupled” I described the scenario above to the solution marketing team for SAP’s cloud-based financials and asked how the combination of Financial OnDemand and Customer OnDemand would address this issue of redundancy. If each were sold separately (i.e. not delivered as the integrated suite of Business ByDesign) would the customer wind up with two different customer master files? SAP’s answer was no.

Here’s how it works: Think of the customer (master data) as a business object. An older ERP solution will build that customer master file (the business object) right into the solution. Instead, these OnDemand solutions treat the customer master as a separate business object that lives outside of the application. By doing this, both applications can point to, access and reference the same business object.

But what about maintenance? Instead of building the maintenance functions directly into each application, SAP treats that function as a separate function as well. Instead of building that directly into Financials OnDemand and Customer OnDemand, SAP builds it once and puts it in a “business process library” which both (and other) applications can use. The term “business process library” might be a bit confusing because most think of business processes in the context of processes like “order-to-cash” or “procure-to-pay” or “plan-source-make-deliver”. These are workflows that string together different functions. But in this case the business process is much more granular. It refers to the process of maintaining the customer master data.

So by loosely coupling these two applications, the customer still winds up with one customer master file. And both applications use the exact same functions to access and maintain it. These external business objects sort of plug into these applications.

This solves an important problem, but in our scenario, where we are replacing the accounting applications of an existing ERP solution, it is only half of the problem. If that existing ERP is still managing customer orders, it too needs to access the customer master file and it probably assumes the customer master file is the one that is delivered embedded in the ERP. So until or unless you do some potentially invasive surgery to the existing ERP, you are going to have to deal with some redundancy of data.

Of course if you replace that tightly integrated ERP solution with a newer or upgraded solution that has been assembled with loosely coupled external business objects, this problem goes away. In the meantime, SAP, and potentially other solution providers are beginning to re-architect their solutions to make this much easier. They are essentially performing this surgery and delivering applications that make better use of underlying supporting technology to make this happen. Remember the $6 million man and the bionic woman? They were still people, but with some of their “parts” significantly enhanced. Think of it as bionic ERP.

This entry was posted in ERP and tagged , , , , , , , , , , , . Bookmark the permalink.

9 Responses to Loosely Coupled or Tightly Integrated Enterprise Applications? Why Should a CFO Care?

  1. Dave Barker says:

    Cindy – good description. If I understand correctly, ‘loosely coupled’ equals ‘best of breed’ but from the same vendor. Or are the vendors that are promoting this concept opening up the common business objects with suitable APIs and Web Services that other vendors can use in thier own applications. But that would still leave the challenge that each vendor would still have to produce for example a customer master and they would inevitably be different. This reminds me of the discussions from 20 years ago when we all dreamt of common, open, Business Objects standardised by agreement between vendors. We now have the technology available (Cloud, Web Services etc.), but will it ever be in the major vendors’ interest to facilitate a competitor’s modules alongside their own.

    • mintjutras says:

      Hi Dave – I think it does go beyond “best of breed” from the same vendor. Yes it might be APIs and web services. Of course the cleanest approach will use a common platform. Both Infor (ION) and Epicor (ICE) are doing this. Infor is a bit more universally applicable because they use OAGIS standard business objects. But in either case some work needs to be done to legacy apps before they can take advantage of the underlying platform.

  2. Doug Hadden says:


    This is the kind of common sense analysis that folks in our industry need to understand. I can’t count the number of times I’ve heard non-IT people talk about “seamless integration” without any idea of what that really is.

    Many ERP vendors have painted themselves into an integration corner. Oracle, SAP and others have been selling the ERP portfolio management concept where the functionality of a single ERP may be less than a combination of best of breed. The notion is that the integration and management costs for multiple best of breed exceeds any functional advantages.

    I can tell you that this myth is strong in the enterprise software market to the point where it is viscerally accepted by CFOs and CIOs alike. The problem with this notion is that numerous acquisitions have challenged ERP companies to provide any kind of tight integration. Most of these software applications are monolithic because of legacy design and difficult to interoperate.

    The trend towards industry standards such as Web Services makes proprietary vendor integration schemes appear very dated. And, it is very difficult for ERP companies to redevelop software using modern SOA architectures where business objects like the Chart of Accounts is easily reused. There is no granular integration available in most ERP applications. Of all the major vendors, only Oracle has attempted a re-write through Fusion. Microsoft started it. SAP seems content with wrapping legacy client-server code. Yet, it has been my experience that all 3 of these vendors push the integration value despite serious problems.

    Infor hasn’t painted themselves into the monolithic corner.

    • mintjutras says:

      Doug – I would agree SOA architecture is a requirement. But SOA suffers from this same problem in that the line of business folks don’t know or seem to care about it. But when you break down what SOA can deliver to them (e.g. easier integration, particularly with a hub and spoke approach) then they do care about what it delivers. I would say though that Oracle Fusion is not the only product that does this. I agree Infor has not painted itself into a monolithic corner. I would also point to Epicor and its ICE technology. Epicor 9 was essentially re-architected and re-written, originally with a convergence strategy in mind. But now gives Epicor an opportunity to apply that technology to its other product lines.

  3. Christoph Burkhardt says:


    interesting thoughts, and an important question you raise.

    I’ve worked for many years as software architect and finally as R&D director for an international ERP vendor, and I also worked as CIO for a 700 employees software company. Now I run my own business as SAP VAR for SAP Cloud Solutions. So I know all three perspectives quite well – ERP vendor, ERP customer, ERP implementation partner.

    “Loose coupling” originated as a technical term in software architecture, see e.g. http://en.wikipedia.org/wiki/Loose_coupling: “A loosely coupled system is one in which each of its components has, or makes use of, little or no knowledge of the definitions of other separate components.”. The main goal is to make it easy to replace a component of the system by another one. You provide some use cases, why it might be desirable for a company to be able to replace one component of its enterprise software portfolio by another one in your article.

    Being able to replace parts of your business software by another software sounds great. However, loosely coupled, as mentioned above, means that the components of your enterprise software portfolio have little or no knowledge about each other. This is, and will always be, the exact opposite of why businesses use ERP software! The business value of ERP software is, that all components of it know everything about each other. You change a setting in one place, and all processes know about it. In particular this applies to the integration between logistics / SCM and finance – integrated value flow. For a manufacturing business, like in your example, a loosely coupled financials is a bad idea. A loosely coupled financials does make sense, if your financials and your “operations” don’t need to know much about each other, and/or if you simply have no alternative to loose coupling, e.g. because you require some very special vertical industry functionality that is not available in an integrated way. There is definitely a marked for these “financials-only” plays (or let’s more precisely say “no logistics / no scm plays) – look at financialforce.com, netsuite.com, etc. This is the market for Financials On Demand – where SAP is focusing on the “large enterprise” part. While you can have SAP Business ByDesign for 21.480 Euros per year (15 users), the minimum annual base fee for Financials On Demand is a 6-digit figure (!)

    Similar logic applies to the value of SalesOnDemand / CustomerOnDemand, i.e. to loose coupling of CRM. If you need a deep integration between CRM and logistics, don’t do it. If your CRM processes, i.e. marketing, sales and service depend on access to information maintained/created in your ERP system, e.g. past purchases with prices, warranty, serial number, payment history, service history, complaints, stock inventory, complex pricing), then don’t go for loose coupling of your CRM solution. It will be a nightmare. But if you need this integration, or if you are happy with synchronizing the customer address and contact information only, then loose coupling gives you the great freedom to choose the CRM solution that fits best with your requirements.

    This old story of “LEGO”-like business objects, processes, or “services” (… the terminology has changed a few times during the past 20 years …) which you can configure in a plug- and play-manner like LEGO pieces, is complete nonsense. I have seen it for more than 20 years now that these promises have been made – including by SAP – and they never have been delivered. They never will be. No matter how often Lars Dalgaard says so.

    You have to choose between the benefits of integration and the benefits of loose coupling.

    • mintjutras says:

      Christoph, I most definitely agree that you will need to choose between the benefits of integration and loosely coupled. I don’t necessarily think any of the players are describing loosely coupled as a configurable plug and play like LEGO pieces. There is still work to be done. But I do think the technology to support “loosely coupled” has improved dramatically over the last few years. In fact I just came back from Inforum and talked to several companies that had implemented Infor ION for exactly that reason. One customer used it to integrate ERP with EAM. The asset management team has complete control over the repair parts now; ERP still controls the purchase and payment process and the connection appears seamless. Since the integration, they have upgraded the ERP (new releases) 3 times and the EAM solution twice. So far they have not had to even touch the integration.

      And by the way, I would not put NetSuite and FinancialForce (or Financials OnDemand) in the same category. FinancialForce and Intacct, yes. Both are accounting solutions. NetSuite is definitely in the ERP category and therefore will compete against ByDesign. It might still play in a two tier environment, but wouldn’t have the same application as Financials OnDemand.

  4. Pingback: Infor's Inforum 2013: Building Momentum; Going Faster | Mint Jutras | Making Enterprise Business Systems Pay Dividends

  5. lauralou says:

    Brilliant article. I agree with the other commenters, this is something that we all need to understand yet few seem to grasp.

    I particularly liked your explanation here: ‘The biggest reason “loosely coupled” might be of very significant value to a CFO is because things change. Markets change. Companies expand (or shrink). Software is enhanced. Technology innovation happens. In fact, technology innovation often results from change but is also often the catalyst for change. Yet responding to change is hard.’

    Adapting to change in the ever changing business world is so so tough, but I think certain ERP X3 Solutions do the job (an example is here) but other solutions are still behind.

    Maybe one day CFOs will take more of an understand actually understand the software jargon!

  6. I spent 20 years in K-12 education before joining a non-profit in education. We had been hearing about the promise of SIF (schools inter-operability framework) whereby disparate systems would be linked together by a ZIS (zone integration server) to use the student information system as the authoritative database and populate the secondary systems (library, nutrition services, transportation, etc) with the necessary data, eliminating redundant data and so forth. This SIF system required all vendors to follow certain programming protocols in the development of their product. It actually worked quite well but was fairly expensive. Then, with XML and web and api integration, it all became much more affordable and attainable. The moral of this story, loosely coupled is the best approach and vendors should work with their clients to achieve the integration.

Leave a Reply

Your email address will not be published. Required fields are marked *

fake luxury watches for sale