Why Most IT Budgets Promote Point-to-Point Integrations
Traditional IT budgets can hold back the organization from becoming innovative and agile
The primary need is to exchange and synchronize data across business applications. Employee data is a strong example, since it changes frequently and often requires ongoing synchronization. A close second is providing access to data through custom APIs that support critical business processes such as employee onboarding, mobile or web applications, or integration with external systems following a business acquisition.
These are the types of projects that add real value and help move the business forward. At the same time, they can create significant strain on enterprise architecture. More importantly, when point-to-point (P2P) integrations are used, they can negatively affect the organization’s long-term financial outlook. The question, then, is why companies continue to implement P2P integrations instead of adopting a more flexible service-oriented architecture (SOA). Several reasons are clear, while others are less obvious than they may first appear.
The Economics of Budgets
Budget constraints are one of the primary reasons P2P integration solutions continue to be implemented instead of SOA. In many IT organizations, funding is established at the project level. An executive sponsor is identified, funding is allocated, teams are formed, and the project moves forward. This approach is logical and often difficult to challenge.
Under this model, P2P integrations are frequently the fastest and least expensive option in the short term. The integration effort is contained within the project budget, which means technical teams are not carrying requirements unrelated to the immediate business solution, and managers are not incurring costs that appear disconnected from the project objective. However, as Enterprise Architect Marc Rix notes in “Bottom Line SOA: The Economics of Agility”, this approach can create long-term financial consequences for the business.
Those long-term consequences are often difficult to quantify when short-term delivery goals take priority. In many cases, the organization may not experience the full financial impact of a P2P model for years. By that point, the original sponsor may have moved into another role, budgets may have been reallocated, and priorities may have shifted. Building and sustaining SOA requires patience and executive discipline, in part because the initial investment is significantly higher than a P2P implementation. The pressure to manage short-term budgets is one reason many organizations never make the transition to SOA and continue to absorb the cost of a less scalable architecture.
Transitioning to Change
I do not claim to have all the answers, because there is always more than one way to solve a problem. However, recognizing that a problem exists is the first step. Having the EAI program sponsored by business projects may eventually create momentum, but the team must remain disciplined enough to design for the enterprise rather than for a single project. That discipline becomes especially important when key architectural decisions are being made.
If one decision is allowed to favor the project because of time or budget constraints, it can quickly establish a precedent that is difficult to reverse. Real progress toward SOA depends on executives revisiting the budgeting model for enterprise functions and allocating funds in a way that supports the broader needs of the organization, not just the immediate needs of a single project.