The trident SOA – BPM – EDA
Possibly a good time to compile in one entry the three pillars that make up the SOA strategy: the trident SOA-BPM-EDA. It is convenient to underline the importance they have and the role they play, before going further by expanding and deepening this whole issue.
I am very tempted to propose a very simple definition of what SOA is. It would be something like this: “SOA is, basically, how things should be done“. Of course there is a bit of a joke in this, but not everything. Because at the heart of this simplification is a reality: SOA shows a way of doing things in systems plan, interoperability requirements, process modeling, data modeling, testing, documentation, standardization, abstraction and reusability, which are so evident in their statement that it is surprising that they must be rescued.
The first of the pillars that support an SOA strategy is the processes analysis and modeling, BPM. Careful, because BPM has its own history, methodology, standard notation, objectives and rationale. The analysis, management and optimization of the business processes of an organization is a booming discipline that, in itself, is not related to SOA and does not need it.
However, BPM has some things that make it especially useful and attractive to complete and empower SOA as a business strategy in ICT (in fact, providers of major SOA suites include BPM tools one way or another):
- It is oriented to the business processes, not the functional areas. Moreover, it promotes this change of approach, which gives interoperability requirements the value they really have for the organization, and
- It has a very simple and easy to understand standard notation (BPMN), excellent for unifying the understanding of the business by different profiles. This notation also covers messaging flows and events of all kinds, which fits like a glove with the rest of the strategy.
BPM ultimately enables us to model and analyze the cross-cutting business processes of the organization, to discover interoperability requirements or repeating process patterns that could be published through business services or business rules.
The second pillar of the SOA strategy would be EDA (event driven architecture). It is an approach that promotes the asynchrony between the systems involved, and therefore minimizes the coupling, starting from the proactive communication of the business events, and the subscription of the systems interested in each event.
In this way, each information system focuses on two axes: functional requirements, corresponding to the functional area to which it belongs, and interoperability requirements, corresponding to the publication of business events that are of interest to the processes, and subscribing to the business events in which each information system may be interested.
By doing this the systems are no longer integrated with one another, but they acquire a defined role, self-contained, encapsulated, black box for the rest of systems, eliminating the coupling and significantly lowering costs in evolutionary projects and corrective maintenance of the systems map. A systems map that becomes a kind of assemblage of pieces at the service of the business.
And SOA? What is left? The title?
To test analogies, we could say that BPM and EDA are the two main actors, and SOA is the film.
SOA establishes the strategic, documentary, methodological and normative framework for the planning and execution of ICT projects with interoperability requirements, through the publication of a catalog of reusable business services, the unification and standardization of business semantics and the optimization of the entire system map infrastructure of the organization, resulting in a significant reduction of costs in the medium and long term.
And as it happens in movies, many other efforts participate in the creation of the film. There are other actors and participants, and we will visit them in this blog.
To be continued…