Article Preview
TopIntroduction
Organizations’ business processes (BP) are increasingly changing due to a diversity of factors, including new demands from the market and innovation needs. From the ICT (Information and Communication Technology) perspective, one of the challenges refers to how ICT layer should rapidly respond to changes at the BP design level (Hurbean, 2007).
The combination of BPM (Business Process Management), BPMS (Business Process Management Systems) and BPMN (Business Process Modeling Notation) has arisen as a prominent approach to help enterprises in the modeling, simulation, execution and evaluation of BPs as well as in the integration of intra and inter-organizations’ sectors and systems (Harmon, 2007). However, a more complete realization of BPM encompasses the adoption of another approach: SOA (Service Oriented Architecture) (Kamoun, 2007). SOA provides an adequate architectural view on design, implementation and integration of complex services-based distributed software systems, bringing up a sort of benefits, like better software reuse and flexibility for faster software composition (Neubauer, 2009).
Roughly, the essential goal of BPM-SOA integration is to provide a right framework for the execution of the right set of services (modeled at the ICT/SOA level) that can attend to BPs’ specifications (modeled at the Business/BPM level) in the right way as long as business logic changes (Fiammante, 2010). Nevertheless, this integration is complex to deploy, involving several different but complementary perspectives, like organizational, financial, ICT, human resources, and data and systems interoperation (Mircea, Ghilic-Micu, & Stoica, 2012).
From a more technological point of view, Fiammante (2010) points out that one of the main pitfalls in BPM-SOA integration projects is that they have reintroduced the tight coupling approach between BP models and web services, preventing organizations from having more flexible and agile adaptations. Under this view, several authors (e.g. Patricia, Perez, Giandini, & Diaz, 2012) have highlighted the relevance of the services discovery activity as a key element to leverage better BPM-SOA integration. Discovery can be defined as the process of locating service providers and retrieving service descriptions that have been previously published (Papazoglou, 2008).
Discovery can be very complex. It can be triggered by users or systems in different ways; there are several different strategies that can be applied in the search; the analysis and services selection require very proper criteria; semantics is usually hard to treat; BPM-SOA interoperability is difficult to handle; among other aspects. This is possibly the main reason why organizations have by far adopted a more conservative approach, binding services to BPs in a static and hardcoded way and with a weak computing assistance along the discovery process, i.e. once general managers specify the BPs (at BPM level), very experienced IT engineers manually bind them to - existing or to be developed – (web) services. Some enterprises overcome a bit this via reuse, allowing IT engineers going through internal repositories to find out services that better match the required BPs’ functional requirements. However, reuse does not guarantee the availability of “equivalent” services out of which the most suitable ones can be chosen. Yet, it assumes that services are already implemented, they can respond to the required QoS (Quality of Service) needs, and engineers know exactly about services’ business contexts, behaviors, names and arguments.
Another limitation in the organizations which have adopted SOA is that they use to keep services stored at their local silos (Dorn, Grün, Werthner, & Zapletal, 2009). Considering the recent movements of IT outsourcing, services ubiquity and SaaS model (Software-as-a-Service), it is important to expand the potential of services discovery to outside the bounds of one organization, giving the possibility to also invoke equivalent services (although published with different names) from other providers/silos, which can even better match the desired e.g. QoS levels for given BPs.