Today many IT departments have a hybrid of legacy on-premise applications and newer, more innovative Software-as-a-Service (SaaS) business applications that they need to manage. Salesforce.com is no different; we have a lot of SaaS and on-premise applications that we use to run our daily operations. Our Enterprise Application Integration program has a number of use cases that we support, but can be consolidated into two main concentration areas: 1) System-to-System Data Exchange, and 2) API Data Access.
The first and most primary need is to exchange and synchronize data across various business applications. Employee data is a great example of data that changes and needs to be synchronized quite often. A close second is providing access to data via custom APIs for projects that support critical business processes, such as employee on-boarding, various mobile or web applications, or integrating with “foreign” systems as a result of a business acquisition.
It’s these custom projects that help add value to the business and propel it forward, but at the same time can wreak havoc with your company’s enterprise architecture. More importantly, this can impact the long-term financial outlook of the company when point-to-point (P2P) integrations are used. So why do companies still implement P2P integrations rather than a flexible SOA solution? Some of the reasons are apparent, but others are not as intuitive as one might think.
The Economics of Budgets
Budgets are the number one reason why P2P integration solutions are still implemented rather than SOA. If your IT department is anything like mine when it comes to budgeting, then you already know funding is established at the project level. This means an executive sponsor is established, funding is allocated, teams are created, and a project is born. This approach makes logical sense to most people and is difficult to mount an argument against changing it.
In this microeconomic model, P2P integrations are the fastest and cheapest solution when it comes to budgets. This is because the project encapsulates its integration work within the project budget. This means technical teams aren’t burdened with requirements not affiliated with the business solution and managers don’t have to incur expenses that aren’t directly related to the project objective. Unfortunately, as Marc Rix, an Enterprise Architect, points out in his Bottom Line SOA: The Economics of Agility whitepaper, this approach has long-term financial consequences to the business.
It’s these long-term consequences that are hard to quantify when short-term goals are at stake. In fact, an organization may not see major financial consequences for years to come when choosing to integrate using a P2P model. By then it’s likely that the project sponsor has moved on to another role, budgets re-allocated, and priorities shuffled. It takes patience and discipline from the executive team to plan and budget for SOA. This is because the initial investment required to get up and running with a SOA implementation is much higher than a P2P implementation. The heavy burden on budgets and the organization’s focus on short-term results is why most organizations don’t ever transition to a SOA-based infrastructure and continue to be a a financial drag to their company.
Transitioning To Change
I don’t propose to have the answers, as there is always more than one way to solve a problem. However, recognizing and accepting that there is a problem is the first step. Having your EAI program sponsored by business projects may ultimately get you there, but your team will need to have the discipline to design for the enterprise rather than for a project, especially when crucial design decisions are discussed. If one design decision goes to the project because of timelines or dollars, then you’ve set a precedent and it’s really hard to change course after that. It won’t be until executives take a look at their budget model for enterprise related functions and allocate funds appropriately for the greater good of the enterprise that SOA can really be achieved.