Dynamic SOA and BPM: From Simplified Integration to Dynamic Processes
- Common Pitfalls Limiting the Value of SOA and BPM
- How Other Industries Approach Varying Conditions
- A Streamlined Enterprise Architecture for BPM and SOA
- Basic Principles for Enterprise Dynamicity
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
- He that will not apply new remedies must expect new evils; for time is the greatest innovator.
- —Francis Bacon
Common Pitfalls Limiting the Value of SOA and BPM
When Services Oriented Architecture (SOA) was initiated, the simplified integration capabilities brought hopes of a simplified business and IT landscape with reusable business components enabled by open technologies. A few years later, the results are uneven; some have experienced substantial benefits from a move to SOA, while others experienced more average value, even though they've used the appropriate technologies.
There are multiple reasons for not realizing the full business value of this services approach. Let's look at three essential reasons:
- Many projects simply use advanced technologies to implement a client/server approach on Web Services—Even though the protocol and technical adaptation is no longer a problem, they faced the same issues as a decade ago: changes to the server interfaces leading to client changes. My team faced such a scenario when a large bank decided to expose all its mainframe transactions as Web Services, but the operation semantic remained the same as for mainframe transactions. This pure bottom-up approach did not bring much business value, and in some cases, it led to worse performance.
- Business processes reintroduce the tight coupling of flexible business services—In many cases, Business Process Management (BPM) has been established as a disconnect approach from the SOA approach in which business services were limited to the exposure of existing application functions. This model fails to address the modularization and variability of the business processes, and the processes act like glue rigidifying the services. For example, a large telecommunications operator implemented an end-to-end order management in a very large, single Business Process Execution Language (BPEL), including more than 300 activities, and ultimately faced a lack of reusability when some sequences could have been modularized and exposed as services.
- Rigid information models are used to expose business services—In many cases, services are only viewed as operations, forgetting that the business information structure they carry will vary as well with the evolution of the business. For example, another telecommunication operator was updating its product catalog weekly and generating a new schema at each change. This led to instability of the exposed services and integration processes, and delayed IT projects rather than enabling faster cycles.
Each of these experiences induced a deeper thinking process. What should be the essence of a business variable approach? How can we reach a true business/IT alignment with the expected shortened IT cycle enabling faster and cheaper business reactions?