The principles of SOA were sound, it was the implementation that failed. Service-oriented principles should be the underpinning philosophy behind integration; and an enterprise service bus pattern, when delivered with lightweight solutions, has been proven effective.
Service Oriented Architecture (SOA) has been both hailed as a modern and agile approach to enterprise architecture and software development as well as deemed as a colossal waste of time and money. Missed expectations for many SOA projects has led to frustration and ultimately a slowdown in business innovation. Many companies have turned to a standalone enterprise service bus (ESB) for their integration needs.
What we propose instead is a new way of thinking about both SOA and ESBs. Instead of thinking about them as solutions you buy, it’s time to consider them as principles for enterprise application integration, from an architectural point of view. In other words, as organizations approach application integration, think about the ideas behind SOA as the underpinning philosophy behind integration and the functionality of an enterprise service bus as the cornerstone architectural pattern of how integration is achieved.
The principles of SOA are still valid
The key principle of SOA was to design and build enterprise IT architecture around services rather than complete applications. In an architecture like this, the idea is to create components called services — small, discrete units of software that provide a specific functionality and, importantly, are reusable in every application. In this type of service-oriented model, developers create new applications by combining a collection of services rather than building out an entire software program, which eliminates code redundancies across applications and saves developers a great deal of time. An example of an application created with SOA principles might be a bank loan application; it would be composed of credit status check services, interest rate services, and customer data services.
In theory, SOA should break down the separate silos of business logic and data that are scattered across multiple applications. These islands of logic and data might exist in on-premise or cloud-based software, SaaS applications, or in devices brought from home by employees. In its ideal form, SOA should enable interoperability across all these business logic and data sources through integration, which should make it quicker and easier to automate business processes.
This service-oriented approach to enterprise architecture has numerous benefits. By making IT systems and business processes more agile, enterprises can respond to changes in the market much faster and more efficiently. They can more easily innovate new products to stay competitive. And by implementing an SOA architecture, they can reduce the bloat and complexity often found in legacy systems, lower IT costs associated with maintenance and upgrades, and increase developer productivity by making software design more intuitive. The ideas behind SOA aren’t bad ones. It’s just that the implementation did not live up to the promise.
A “Bottom-Up” approach to SOA – the Enterprise Service Bus
The reason many SOA initiatives failed was that they were initiated in a “top-down” way – they were launched as a single, organization-wide initiative, were often vendor-specific (perhaps IBM or Oracle) and entailed expensive, multi-year rollout plans often involving expensive consultants. They were laborious and time-consuming, and often the company’s development team would then need to learn and use the product to re-architect all existing systems as well as design new applications according to SOA principles. These developers would have to throw out their existing tools, processes, and skill sets and be heavily retrained on the new solution, which had negative effects on being able to innovate quickly and keep up with the pace of change.
A different way to approach the problems SOA was meant to solve is with a standalone enterprise service bus (ESB) or integration platform as a service (iPaaS) instead of a full proprietary stack. ESBs can power the creation and orchestration of services without requiring an application server or other infrastructure component, eliminating the high upfront costs of implementing SOA. Instead of a years-long rollout period, an ESB can be implemented and deployed in a very short period. This enables developers to build reusable interfaces with APIs while also establishing a core framework for integrating a governance model for the future.
An enterprise service bus allows companies to adopt SOA principles incrementally, without needing to rip and replace their entire infrastructure. And because standalone ESBs are typically built according to open standards, they give companies the flexibility to integrate a wide range of systems, cloud services, and applications. And unlike prior SOA initiatives, ESBs don’t impose vendor lock-in or architectural choices. In many ways, therefore, an enterprise service bus achieves what SOA initiatives promise.
For modern integration needs, an Enterprise Service Bus is only part of the story
An enterprise service bus is great for current integration projects and can make connecting systems simple and fast. But there are numerous components of connectivity needs for today’s organizations. For example, organizations that use APIs to compose their applications from reusable services will need a way to design, build, manage, and secure those APIs quickly and easily. There will need to be a way for developers to easily self-serve the reusable services that are frequently used and needed. And there need to be mechanisms to accommodate the common toolchains for continuous integration/continuous deployment.
That’s why Mule as an enterprise service bus is at the heart of Anypoint Platform, which offers not only enterprise-grade connectivity but full API lifecycle management on a single platform. Anypoint Platform provides capabilities at each of the stages in the API lifecycle: design, collaboration, build, test, deploy, publish, version, and retirement. Organizational silos are broken down through Anypoint Exchange, the component of Anypoint Platform that captures all APIs, connectors, and templates created by developers and offers them for self-service reuse by different groups inside or outside the business. And the platform is built for DevOps and agile development by utilizing the common toolchains used for continuous integration and continuous deployment (CI/CD) i.e. SCM, Maven, JUnit, Jenkins and works well in DevOps environments to build and manage microservices, as the platform can be containerized.
A unified connectivity platform uses the principles behind SOA and the functionality of an ESB to make a truly reusable, service-oriented enterprise architecture that provides the agility and developer ease businesses need to stay competitive in today’s environment. Take a look at Anypoint Platform to see how it can benefit your organization.
