The differences between Business Process Management (BPM) and Service Oriented Architecture (SOA) are not always obvious to the average business user. This article explains the differences between these two concepts – and how they work together to help streamline business processes.
Do a search of service oriented architecture or business process management, and you’re bound to see the other referenced in the search results. Further research and reading will reveal even more confusion: improving business processes is often referenced in articles explaining service-oriented architecture. Conversely, BPM often talks about SOA. How is one supposed to make sense of these two terms, how they work together, and how they differ?
The best place to begin in differentiating between BPM and SOA is to first understand what they have in common. Simply put, both of these disciplines work toward improving integration of business processes. Much like the industrial revolution ushered in new methods of mass production and quality control, thus turning the page on handmade, “cottage industry” production, so too have SOA and BPM led businesses to better understand how disparate technology systems with their organisations lead to waste and inefficiency.
As a result, both BPM and SOA seek to integrate all of the systems within an organisation so that they can share data more easily and provide fresh, accurate means for servicing customers and clients.
Considering that both BPM and SOA seek to deliver streamlined integration to business processes, then one might wonder “what is BPM?” BPM is a holistic management process that seeks to align business processes so that they are optimised for the needs of an organisation’s clients and industry challenges.
While the IT perspective of BPM is concerned mainly with the technological considerations behind the middleware of a company’s business solution, BPM actually transcends even this restrictive view of what a business process means to a business. Bound up in BPM is not just the technological implementation of new middleware systems, but also a managerial roadmap that integrates human-driven processes in which human interaction takes place in series or parallel with the use of technology.
This isn’t to say that BPM is an intangible approach to integration; it is commonly implemented by a series of design tools, as well as detailed, time-proven methodologies, such as Lean Six Sigma. But all in all, BPM ushers in a complete management of how all operational processes are structured and implemented, all toward the one goal of efficiency and implementation.
Unlike BPM, which provides organisations with a specific management approach to implementing and maintaining efficient, integrated business processes, SOA instead provides a flexible set of design principles for developers, which are used during the systems development and integration phases of BPM projects. In this way, SOA helps to forge the blueprint and technological means for implementing the goals defined by BPM.
As stated earlier, at the heart of SOA is the integration of disparate systems within a company’s business solution. This is achieved by orchestrating software functionalities in a highly flexible, non-hierarchical arrangement. This is usually accomplished by using effective SOA software tools that allow existing software systems to communicate and interact. In this way, SOA gives developers the means of restructuring existing technological assets of companies so that they work more efficiently.
SOA and BPM Work Together
Because SOA and BPM overlap with each other in terms of what they seek to accomplish, both concepts are in many ways inseparable. While one could imagine BPM as a more philosophical design approach, its principles are firmly rooted in optimising business technologies – there is little need for business process management outside the realm of technology these days. Because this is the case, SOA functions as a key component of achieving the objectives that BPM seeks to accomplish.
The New World: Managing Uncertainty Means Managing APIs
In the past many enterprises relied on IT monoliths, in which changes in one place could break seemingly unrelated functions elsewhere. This was the world of SOA and the Enterprise Service Bus (ESB). Development was generally slow and unable to react to quick market shifts due to taking an inside-out perspective on providing data access to specific department and partners.
Modern API management, in contrast, can help enterprises break the monolith into discrete pieces, exposing individual components in well-documented services that internal developers and partners can tap into to rapidly iterate new features and offerings. API management takes an outside in approach to sharing data, thus making it much easier for app developers to leverage data to create great user experiences. It is a subtle change but it is why API Management has become a hot new segment of the technology industry with dozens of platform players vying for market share.
Properly managed and implemented, API-centric architecture shortens time to innovation and provides the foundation for business ecosystems. Because APIs can break monoliths into discreet microservices, separate teams can work at different speeds without impacting on one another. An internal team could add or remove a service from a company app without bringing down app components created by other teams. Because the APIs are managed and well-documented, they can be effectively reused and shared rather than lost to bespoke projects. This shift significantly impacts the pace of innovation by speeding up the introduction of new developments into production.
For most enterprises, working with a monolith today is akin to entering a long distance runner into a 400-meter relay race: He might eventually make it around the track, but he’ll be too slow to compete against a series of fast, connected sprinters. APIs act like these sprinters, distributing the work and passing data like a baton — a potentially huge advantage when it comes to iterating against rapid changes in user preferences or quickly growing the range of third-party partners who can integrate and sell your products or services.
This agility only leads to innovation if enterprises can pick out good ideas, identify problems and iterate on this information fast enough to stay ahead of the market — and that’s why management and analytics are so important. By providing insight into the APIs and apps that generate the most calls, latency issues, irregular behaviour, which developers drive the most value to the platform, and other important factors, analytics help enterprises understand what’s working or not working and place bets accordingly.
Making a success of APIs will be a major change in mindset and tooling – and it will be up to each company to scope out their requirements, evaluate available platforms, and implement their platform choices. Many of these will be seeking advice from platform vendors directly. However the best scenario would be for companies to get assistance from vendor-agnostic consultants who can advise on the best solution for their needs.
Find out more about this topic here: