BPM-EAI

For someone who was not in touch with the application integration industry, the term “Consolidating Integration” may have sounded pleonastic. Well, not in today’s tough economic situation for anyone in the IT industry. A few years back, the thought of Consolidating Integration should not have surfaced in any one’s mind. Well, the entire idea of Integration was to “integrate” disparate systems. And theoretically, it would have made common sense to adopt one tool for integration – the purpose was just “Integration”.

Well, that was not the case to be. Organizations cannot adopt theoretical models. Even though there were organizational mandates to adopt a uniform middleware, factors like resistance to change, finding benefits in traditional ways of integration, fear of lacking direct ROI for his or her division/project, immature integration products adopted, complexity of products, etc. contributed to some pockets (may be significant sometimes) continuing to adopt non standard integration methodologies. Another factor was differing organization models; for example an organization may have 10 different LOBs (Lines of Businesses) and each one of them may have adopted a different middleware for various reasons. With the advent of “newer” concepts (reference point is a few years back) like BPM, more tools found their way into organizations’ already complicated middleware space. To add to this, every one wanted to jump the SOA bandwagon and this again gave inroads to tools that could do things unthinkable in the past, for example web service enabling applications running on a mainframe. With mergers and acquisitions being the order of the day, integration tools in an organization got to almost unmanageable levels of complexity.

Clearly, the case for consolidating integration exists in organizations today. So, why not move ahead? Benefits are evident – I do not need to elaborate on that. However, the biggest hindrance is the investment required. And in today’s situation, this may be treated a taboo word. The order of the day may be “if it is not business critical, it can wait”. The question is - “Can it?”. The real question should be, “If I do not start acting now, how much more will I have to spend some time later when the my landscape will get even more messier?”. Organizations are feeling the pinch of not having a uniform Integration strategy, again! Isn’t it time that organizations start taking at least baby steps that will be implemented, if not go all out?

Posted by Madhu Pulasseri at 5:48 AM | Permalink | Comments (1) | TrackBacks (0)

I believe, in the next-generation view of the ICC, a key area of focus will be  'adoption of lean methods to reduce eco-system fat'.  Let me talk about this ‘eco-system fat’. This is just a terminology that I use to represent the ‘undesired’ elements in the ecosystem of people, processes and technology fabric, similar to ‘undesired’ fat in our body. So even though organizations might have an ICC already in place and operating (in whatever capacity), over period of time processes tend to become difficult and ineffective, people seem to be getting stuck in a pattern of activities and hence become difficult to change etc etc. At the same time, context of what ICC does for the organization changes over period of time, need of the organization changes, environment changes. While all of that changes, things in ICC typically do not change in the same proportion and pace and hence what happens here that a layer of fat starts growing on various capabilities of the organization. By capabilities, I mean processes, knowledge, operations, contribution from staff, technology performance etc. Over a period of time, this fat makes the entire organizational system of the ICC  slower and less effective (in terms of delivering results) which basically means burning lot of dollars to improve anything in the eco-system.

With the current acute economical cost pressures, a shared system like ICC will need to reduce this fat significantly. One of the most successful ways to reduce this fat, (or better called non-performing elements of the ecosystem) is to adopt lean methods.

‘Lean’ principals are not new and have been fantastically applied in manufacturing processes. Six Sigma advises lean methods and now there is a great shift in ‘services’ industry to adopt lean principles. You can view this another view-point paper from Infosys on how lean can be applied to IT services segment: LEAN-on-IT

Lean thinking is a very powerful tool that can drive high degree of efficiency in the operating environment. ICC as an IT portfolio today is not a very mature portfolio and hence lot of organizations don’t bother too much about it to apply advance principles like lean. However, things will be different in future. With BPM, SOA and integration all put together, it will be a significant portfolio to look after and hence, organizations will be forced to adopt lean thinking to reduce the non-performing or even slow-performing elements, whether its process or people or technology. Some of the significant opportunity in the world of integration as I see are:

• Consolidation of integration investments (for example common infrastructure) and expenses at enterprise level, reduce localized management and planning
• Measure the operational process effectiveness through KPIs and charter the improvement goals for process owners based on that.
• Establish mechanism to identify redundancies and create opportunities to remove them. Redundancies could be in form of duplicate interface, more than one standards for the same thing, redundant roles (from business result perspective) etc. Regular governance process should be able to identify the potential redundancy scenario right when new things is being introduced and resolve it then and there itself in the beginning.
• Continuous process improvement practice must be adopted in order to identify the process issues on regular basis and charter the improvement plan as a mandatory cleaning activity in the ICC.
• Link the funding process to the amount of fund wasted by ICC. Fun waste could be in form of rework, redundant investment, failure rate, service level performance etc. As components of ICC starts performing better by demonstrating higher quality of delivery and hence savings, they should be allowed incremental funding bonuses for betterment efforts. That will encourage the lean thinking. Similar wastage tax should be levied on the parts of ICC that are not performing well. Tax could be in form of fund restrictions, reduction of power of decision making etc.
• Cross-skilling of the staff to derive more value from their contribution and utilization.

And there are many more. We soon will be publishing a view-point on it with far more details. But needless to say that in current situation, going lean is the absolutely right thing to do, especially for the organization who have significant size of their integration portfolio and have really high cost going into it.

Posted by Rakesh Mishra at 7:17 AM | Permalink | Comments (0) | TrackBacks (0)

As if the world of BPM wasn’t amazing enough, we now ironically have something called cloud brightening up the spectrum of benefits that BPM can provide to an organization. Cloud computing no doubt has taken the IT world by storm, a storm which is almost on the verge of transforming into a hurricane (hopefully not as damaging!).  Cloud computing obviously has its advantages and I don’t need to talk about that here. The subject of cloud computing, like SOA, is already being beaten to death by everyone, even as the application of the concept is yet to come completely alive. What fascinates me however is that BPM particularly appears to have a lot to gain with the advent of the cloud model. Besides lower cost, no infrastructure, low maintenance and quicker implementation that a cloud does offer, cloud is making BPM more interesting and affordable for various other reasons as well.

Cloud computing is definitely creating new opportunities for BPM product and service providers.
BPM vendors have already latched on to this opportunity. Late last year, Pegasystems announced its cloud enabled BPM PaaS with the promise of a platform that will not have the risks of security, performance etc that are usually associated with SaaS. Pega, being Pega, I am sure is coming up with something exciting and I am looking forward to the market’s reaction to it. Vitria too, had launched its VitriaCloud, which allows use of its M3O suite in the cloud model. Appian has its Appian Anywhere BPM PaaS offering and Fujitsu has introduced multi-tenanting capabilities into its Interstage BPM suite version 10 that allows its use as a SaaS. Other BPM vendors too have come up with some form of a BPM PaaS/SaaS offering.

Does it make sense for enterprises to go for these offerings? It definitely gives the smaller enterprises an opportunity to use the power of BPM, without having to make heavy initial investments. Even some of the larger enterprises that I have spoken to are approaching BPM very cautiously, and for them cloud BPM helps adopt BPM one step at a time, one process at a time. Compared to regular business applications, BPM applications have a greater need of participation of remote teams spread across geographies and cloud BPM enables greater collaboration than an on-premise implementation. However BPM, to go beyond just process modeling, needs to integrate with a multitude of applications within an enterprise and that may not be easy to do in the cloud model. Inter-enterprise processes that integrate with external systems are probably more suitable for running on an external cloud BPM platform. The concerns around data integration and data security in a cloud environment are also coming up in the BPM context. It is probably lesser of the issues though, considering that cloud based data integration solutions have been implemented successfully. (Infosys recently implemented a hub-in-the-cloud data integration solution for auto-dealers).  May be the concept of an “on-premise cloud” will prove to be the best fit BPM for many large enterprises, but not for all. I think various flavors of Cloud BPM will be used and on many occasions Cloud BPM and traditional on-premise BPM may co-exist. The key to BPM success would be to identify the right model which would depend on answers to various questions e.g. which process, what is the scale, what are the integration touch points, what is the type of connectivity, what are the security requirements, what is the usage and most importantly what is the cost and pricing model!

Didn’t someone call cloud computing “complete gibberish”? I read that somewhere. Only time will tell if he was right. As far as Cloud BPM is concerned, I do find it promising. It definitely has some thunder in it. Will it deliver its rain or just disappear like a passing cloud? Whatever it is, I think BPM has some bright days ahead with some scattered clouds. Here is your local TV weatherman signing off!

Posted by Arup Raha at 10:46 PM | Permalink | Comments (3) | TrackBacks (0)

The world economy is passing through one of the worst economic times in the recent history since the great depression of 1930s. There is hardly any industrial sector that has not been impacted by the economic slowdown. Many Governments all over the world are increasing the spending and adopting fiscal measures which in their view will help revive the global economy. The debate amongst the economists of the world, between the appropriateness of the Government intervention led policy as enunciated by Keynes and the non interventionist policy of Milton, rages on and there is no clarity on when the economy will revive and when things will get back to normalcy. The discretionary spending by the industrial houses especially in the IT function has witnessed cuts in these tough economic times. Enterprises are exercising caution in their spending and more than the actual impact of the economic slowdown the fear of the unknown is keeping spending by the enterprises at bay.
 In the current scenario, where in the discretionary spending and capital expenditure in IT function is being scrutinized to a great extent, new paradigms like Cloud Computing might just be the prescription to address the needs of the enterprise. Cloud computing includes Software as Service, Platform as a Service and Infrastructure as a Service and these models can eventually become the one stop shop to address  some of the key enterprise IT needs. The enterprises can avoid capital expenditure on the IT Hardware, Software and package implementation costs and can instead look at newer pricing models such as usage based pricing and subscription based pricing. There is no lock in and risks associated with spending as the services from the service provider can be terminated very easily if the customer does not see benefits from the offering. The Cloud Computing “service providers” will have economies of scale which an individual enterprise cannot achieve and can pass on some of these cost reductions to the enterprises. This is a neat way for an enterprise to convert Capex to Opex and still get all the benefits of having invested in a full scale IT infrastructure. The enterprises can also get the benefits of tiding over the peak and trough demands with out the hassle of investing in an infrastructure that is needed to meet the peak demand.
 Gartner defines cloud computing as a style of computing where massively scalable IT-related capabilities are provided “as a service” using Internet technologies to multiple external customers. According to Gartner, Cloud computing heralds an evolution of business that is no less influential than e-business.

Posted by Deepak Kumar Pelluru at 6:09 AM | Permalink | Comments (0) | TrackBacks (0)

Now that ESB has become the defacto standard for integration, all of us at some point of architecture definition experience faced situation where we had to make a choice on what will be the preferred strategy for ESB deployment.

Some of us who come with the baggage of older EAI technology tends to think we can make enterprise scalable & adaptable through distributed ESB. I guess the root cause of this lies in the way older EAI technologies worked where components within EAI layer were so interlinked that a small change within EAI layer meant considerable impacts to other components which lead to longer time to deploy changes.

However if we analyze current ESB offerings from existing EAI vendors it is evident that the product offering has matured considerably and these not only provide a highly optimized runtime environment but also componentized the ESB architecture enabling faster changes and deployment. Hence we are forced to rethink the ESB federation approach. In addition ESB also supports the concept of service domain which should be utilized to the fullest extent to separate out the concerns rather than handling through federated ESB.

This does not mean that federation is not required, it is there to stay. A good ESB federation strategy is a key differentiator between an over engineered enterprise and well engineered enterprise. However the problem is that the choice is not a straight forward one, there are lot of factors that needs to be considered before making the right choice. I have come across various factors that drives the choice but after analyzing various situations the factors that I felt were key to the decision making were
 

1. Clear separation of Organization both external and internal 
2. Secured access to enterprise information systems 
3. Business Strategy that leads to outsourcing of business functions - This is one of the interesting areas that has found lot of relevance in the recent time, where organization were able to identify a business area that they want to outsource and made it possible by separating out the key business services through a dedicated ESB layer 
4. And last the political control within organization. This one I felt was the most trickiest of the all as a wrong choice out here does lead to more federation than required causing a maintenance nightmare
   

If you are initial adopter of ESB (Starting small) federation strategy should be one of the strategy but it should not be a day one strategy, rather it should be build overtime. This implies we need to plan service deployment on ESB using Service domains and have a transition plan for federation as ESB adoption increases within organization. However if organization is going for a big transformation program ESB federation strategy should be part of Integration architecture strategy from day one. 

Posted by Manas Kumar Sarkar at 9:13 AM | Permalink | Comments (1) | TrackBacks (0)