I hope this document will be helpful tool to lot of us to sail through EPM/BPM universe.
The document can be downloaded from Scribd.com.

Growling about Software Business, Agile, Scrum, Kanban, Solution Architecture, Design, Big Data, SOA, EAI, Cloud Computing, and many more things …..
SOA Governance is one of the most vigorously debated and misunderstood subject in SOA world. Because of inherent complexity of governance and SOA, SOA Governance becomes more complex subject.
Book is written is style of novel coupled with some hard technical talk in end of each chapter. This makes reading of book very relaxing though covering complex subject. Book covers governance issue in such a fluid manner that while reading it seems that one is just browsing a story book. Book starts with basic concept of governance and start peeling layers. It covers architectural, design and project management challenges to have good governance model from project as well as enterprise perspective.
Book also take advantage of case study approach and assume very realistic insurance company with all nuisance of IT Management and Architecture noise.
Book is certainly a good read for its target audiences – Architects, IT & Business management folks and certainly those who are interested in SOA Governance.
In SOA universe there are two types of players. One those who are selling different products under SOA umbrella and second one are pure intellectual efforts who are defining SOA.
There is also third breed which consists of service providers who are mainly focusing on implementation strategy.
Breed one and two has lot of cross pollination to promote their respective product suite. This cross pollination has resulted in plethora of specification and some time at the expense of each other.
So the question arises is this leading to some where or it will turn SOA into one more kind of Lock-in strategy by product companies?
Keeping EPM into sight, what is process?
“A process is a coordinated thread of sequential and parallel activities needed to deliver value to stakeholders.”
So what is EPM?
“Enterprise Process Management is assuming controlling position on processes from inception/idea to its delivery, from very first activity to last, and analysis of each and every activity for continuous and step improvement.”
From definition it is very clear that EPM can be visualized from three view points:
In real life settings, most of the enterprise processes are combination of MP, IP and HIP.
For simplicity let us consider a simple process: Opening a checking bank account by a new customer.
So to open checking bank account, customer has to submit a form to branch where he wishes to have account. The account opening form also need some supporting document like identity card of the prospect along with letter from an existing account holder. Upon submission of completed form and supporting document, a clerk at branch verifies the documents at preliminary level and sends to regional office for detailed verification. If verification result is OK, account is opened, base branch & customer are informed and checkbook, ATM card are dispatched to customer. If verification result is NOT OK, base branch & customer are informed.
In the first glance the process seems to be well structured and simple enough for automation. This process seems to fall in Material and Information Process category. So automation looks easy and within reach. Now let Human aspect enter into the process.
Mr. Clerk who accepts documents from prospective account holders has friendship with Mr. Tony. One fine day Mr. Tony reaches to branch where Mr. Clerk is stationed and submit Account opening form. Mr. Tony does not was not carrying supporting documents, so he talks to Mr. Clerk and makes promise to submit supporting documents on next Monday and asks Mr. Clerk to hold his docs till then. So human relations start tearing a well-structured process.
At first glance this would appear to be another "me too" title, and while in some ways that may be true. However there are a couple of things that set this book apart and it can be of value to those experienced in Integration & SOA as well as those new to the subjects.
Those who are new to the book I will recommend read as much as possible and this book must be one those. This book covers basic essentials of Integration, SOA, WebServices and BPEL in very simple and lucid language, which can help any greenhorn.
The most important part of this book is its language. The most glaring lapse in this book is assuming SOA means web services.
It has explained concepts of EAI in very concise & to the point in first chapter. While explaining Integration Infrastructure authors have drawn nice picture, which covers almost all aspects of integration tool stack. But in the section of Integration Technologies section, it fails to mention that MoM, TPM, ORB, App Server and ESB are various generations of the same and no word about “Several hybrid and proprietary products”.
The second chapter covers SOA in technology agnostic as well as Java &. Net specific way. This chapter nicely covers basic concepts of SOA, which include not only ESB but also web services and its Java and .Net implementation. This chapter also tries to cover process-based architecture in the end, which makes things little bit clumsy.
The third chapter covers XML, Schema, XML document security, and XML parsing. This chapter covers a lot but also leaves behind a lot. It totally neglects non Java XML parsers.
The forth chapter seems to be inspired from IBM’s eBusiness patterns. This chapter also touches Web Services Interoperability (WS –I) stuff, which is pretty elaborated.
The fifth chapter covers BPEL and integration with emphasis on process orientation. This chapter is good reference for BPEL and especially Oracle way of BPEL in its Fusion Middleware.
The last chapter covers ESB in detail. The name of the chapter and content of it does not match.
The most wanted but missing part in this book is references for each chapter in particular and for book in general.
In summary I would suggest that this is a good book for anyone involved in SOA and integration project. It will provide a good introduction for those new to the discipline of Integration and SOA. While acting as a useful refresher for those with more experience
SOA is for business enablement. It is for business to help manage IT assets more effectively and efficiently.
IT assets in general may be viewed from three perspectives.
Enterprise perspective include IT assets at inter and intra enterprise level. It considers Business value of IT assets on enterprise level; so it’s effects is also enterprise level. This perspective is generally elaborated in terms of inter and intra enterprise integration. This perspective is generally taken care by CIO and CTO level while deciding enterprise wide IT strategy. Enterprise Architects also play major role in shaping this perspective.
Application perspective limits IT assets within the boundaries of application – off the shelf or custom-made. This perspective considers Application or its significant functionality as service. This perspective makes sense to VP Engineering and CTO. This perspective gains significance in case of purchasing new enterprise application.
Product perspective becomes very important for product developing companies. This perspective focuses on the services offered within a product. Proper usage of this perspective helps in construction of robust and flexible product/product family. This perspective assumes significance for Technical Architects.
All three perspectives help business to save on cost and decreasing the recurring expenses in terms of maintenance & support. They also helps in reducing time to market.
SOA also brings technological breakthroughs which helps in cost saving and fasten the introduction of products in market.
Technical Challenges
All other advantages can be derived from these three.
Business & Technical Case for SOA
Business
Technical
SOA offer the following advantages over traditional approaches to distributed computing:
Short-term benefits of implementation:
Long-term benefits of implementation:
Every one is advocating for SOA. But there must be some scenarios when not to use SOA.