BPM-EAI

Managing by Walking Around (MBWA) has been a well known style of management for years, probably decades (possibly centuries!), and I am sure the “managers” who are reading this post would have definitely practiced or read about it somewhere. The essence of this approach is to go to the shop-floor or the work-area to directly see things the way they are - the processes, the people, the problems, as well as the potential and as a result have a better grasp of the way the business is running and therefore manage it better. Today, the more I understand the drivers behind our clients starting BPM (Business Process Management) projects, the more I feel that what they really want to achieve has some strong similarities with the objectives of MBWA i.e. get a strong hold of the processes and events, as they happen, and just the way they happen. Walking around to do that, is of course, out of question. How about Managing by Clicking Around!? That is what BPM projects need to deliver in the end, but are they doing that?

Process automation is great, BPM can save a lot of time, errors and dollars. Process improvement is even better – BPM can help monitor performance, identify bottlenecks. However, lets remember, it is one thing to run your business efficiently and another thing to manage your business effectively. If the implementation does not help in improving the way the business is being managed through the use of applications aligned to business, it has failed to deliver full potential of BPM. The trick to get the best out of BPM, I think, is to do a few things beyond “BPM”.

You can’t manage what you can’t see, you can’t manage what you can’t measure and you can’t manage what you can’t change. A BPM solution helps you ‘look’ at and understand your business process almost exactly the way it actually is, and not as a set of disjointed actions, documents and numbers which is the traditional way that IT interprets Business. It also helps you measure the right attributes of your business process, providing you the ability to monitor the right indicators of the health of the process. It even makes it easy for you make and implement changes thus enabling you to respond to the market and internal needs much faster. A key element in all this, however, which I believe is what makes the difference between an efficient business and an effective business, is the power of decision making and predictive analysis. That is one of the two reasons why I love BRMS (the other reason being that it is not a 3-letter acronym again!). BRMS (Business Rules Management System) and CEP (Complex Event Processing) top up BPM with the strong decision-making and prediction abilities which can make managers look really smart by taking right actions at the right time.

BRMS is software that helps define and maintain the rules or policies that run the business and executes the decision logic required to identify the right action. Let me give a simple example. If movie rating is 5, and if movie has received Golden Globe, then movie is good – this is a Rule. Going and watching Slumdog Millionaire is the execution of that logic to take an action.

CEP on the other hand helps make sense of multiple different events, combines and correlates them to identify a pattern and detects situations that need to be responded to. For example, traffic on a road has slowed down, you can hear police siren, you can see ambulance lights flashing ahead – these are 3 different events which in isolation may not necessarily indicate the situation that an accident has happened. In business, early detection of a situation through the occurrence of separate events helps, it provides greater agility.

If I were to try to find an analogy to the value that BRMS and CEP provide, along with BPM, I would say that BPM provides a good detailed map accurately showing all the routes, locations and distances but you still need to figure out how to go from one point to another. BRMS, like Mapquest or Google Maps, gives you the ability to automatically find the route(s) by adding decisioning logic on top of the map data. CEP adds features of a modern GPS navigation system, which not only tells you the best route but also has the ability to tell you in real-time whether there is traffic or construction ahead and suggests alternate routes. Success in managing a business has always required good processes, powerful decision-making and sharp foresight. BPM+BRMS+CEP just provides the tools to do all that a little better.

Posted by Arup Raha at 01:30 AM | Permalink | Comments (0) | TrackBacks (0)

Over the past decade the enterprise application integration space has constantly evolved to embrace a very wide range of areas, beginning with various levels of application integration, business process management, web-services and now moving towards the higher echelons of service enablement of enterprise applications. This has made the business of what used to be a ‘middleware practitioner’ a few years ago all the more difficult. While, on the one hand it requires you to keep abreast of a slew of new trends, on the other it also requires you to bury theories that you have come to embrace over the years.

One such trend that has caught my fancy over a couple of years now is Composite Applications and their applicability in the integration space. While various definitions and interpretations exist for the term, in principle a Composite Application is one that is created by combining multiple existing enterprise functions, services or components. This is done to leverage IT investments by gradually integrating business services provided by enterprise applications and even business partners.

While the term itself is not restrictive to SOA – there could be a strong case of a composite application on legacy platforms on mainframes too – it is particularly relevant today, when large enterprises have been making substantial investments in creating service enabled applications, leveraging Service Oriented Architecture in various forms. It also becomes imperative for Composite Applications to incorporate some extent of orchestration between the various components/services being assembled together. Thus, the composite applications today have come to be the culmination of most developments in the Service Oriented Architecture and the EAI space over the last decade or more.

One could argue that the concept of Composite Applications looks antithetical to Enterprise Application Integration, the latter being focused on enabling integration of discrete applications. But like it has been in the past, it’s not only the large enterprise application players that are gearing their product suites to this latest trend, but the pure play EAI vendors have accorded it an important status too. Needless to say a key ingredient of the Composite Application paradigm is an enterprise service that can be assembled into a Composite in a de-coupled manner that supports scalability, both horizontal and vertical.

All the top product vendors in the footprint of the BPM/EAI practice have made their intentions clear on how Composite Application development is a key focus area for the coming years. The main names that I can immediately recount at the risk of missing a comprehensive roster are:

• SAP Netweaver Composition Environment (7.1)
• IBM Websphere Business Services Fabric
• Tibco Composite Application Bundle
• Oracle Application Integration Architecture
• Sun Java Composite Application Platform Suite (Java CAPS)
• webMethods BPMS

Each of the above suites is backed by a strong integration platform either indigenously developed or acquired. But in my view it will be the availability of a plethora of enterprise services (enabled to be assembled into a composite application) that will act as the key differentiator in this new Service Oriented paradigm. In absence of that, the platforms are likely to become glorified versions of the integration and BPM suites that they are based on. It is no wonder then that the list of pure play EAI vendors making inroads into this space is not as large as some of us thought.

On the other hand, the market could still stay fragmented for a few years with one set of vendors specializing in tools to enable SOA, while the other set of vendors specialize in providing those services to the SOA. The possibility of this happening is low as enterprises realize the eventuality of sooner or later moving to the application suites provided by the big boys of enterprise applications, the ERPs. So while on one hand we have a Tibco Composite Application Bundle that combines Active Matrix complementing the Business Works suite, IBM’s vast array of Composite Application frameworks ranging from portal to Notes to Business Service Fabric,  SAP’s version of eSOA –“ pre-delivered services based on SOA rather than the development toolkit alone “- being delivered through the new Composition Environment definitely paves the way for an exciting matchup.

It remains to be seen whether the pure play vendors like Tibco, Sun (after the Seebeyond acquisition into JCAPS) can hold their ground by virtue of more effective dealing of common challenges like:

• Interoperability to create true enterprise service reuse, through industry standards like Service Component Architecture
• True de-coupling of the enterprise services in question, in order to remain truly scalable
• Availability to leverage existing BPM/EAI, to avoid creation of new enterprise service spaghettis

Posted by Srinivas Kamadi at 03:19 PM | Permalink | Comments (0) | TrackBacks (0)

Purists, till sometime back, considered BPM to be a forte of niche players like Pegasystems and Savvion. Recently, BPM market place has witnessed a change with pure play middleware vendors like TIBCO and package economy players like Oracle, IBM, SAP and Microsoft extending their product offering to include BPM as well. Still, we haven’t seen any dent into the revenue numbers of niche BPM vendors. So let us have a closer look at the BPM product strategies of each of the package economies, and how niche vendors have tackled the competition…

Post BEA acquisition, Oracle combined its own evolving BPEL Process Manager and established BEA Aqualogic BPM under Oracle BPM Suite. While Oracle has both the products can run on a single engine, there are separate process modelers and designer modules for Oracle BPEL and BEA ALBPM. However, Oracle could manage interaction between ALBPM and BPEL Process Manager in a short span. Oracle mentioned during Oracle Open World 2008 that the 11g release in 2009 will present unified BPM offering. Once offered, it will be difficult for competition to match the strength of BPM offerings available on a single platform. I still give big thumbs up for the swiftness shown by Oracle!

IBM has beaten Oracle in its own game. Two prominent niche players - ILOG and FileNet were acquired in a span of two years. IBM has WebSphere Process Server that has business processing capabilities. It used to partner with ILOG to cater customers requiring anything in addition to the vanilla rules requirements. So Ilog acquisition will help IBM to add rules engine to Web-Sphere Process Server. On the other hand FileNet acquisition has helped improve its document process management offerings. But all the smart thinking has been let down by the product team who have taken a long time to offer a common BPM platform to the customers. The decision was excellent, but it remains to be seen if it is executed properly.

Coming to Microsoft, we are yet to see any seriousness as far as BPM is concerned. The nearest it has come to BPM is by offering Windows Workflow Foundation (WF). WF is Microsoft's technology platform for creating workflows. However Microsoft has not shown any inclination to bring WF and BizTalk together in next set of releases as well. It still expects its Business Process Alliance partners to create solutions that enhance BPM enablement on Microsoft platform. I fear that soon SI partners, customers and analysts will stop giving a thought to Microsoft while talking BPM!

SAP had ARIS to compliment BPM approach. Last year, SAP acquired Yasu Technologies to enhance its BPM offering with business rules infrastructure. The vanilla BPM platform was showcased during SAPPHIRE 2008. SAP isn’t clearly competing in the BPM space – but BPM vendors will definitely encounter stiff competition in selling their product to SAP customers.

Large players joining the bandwagon will continue pushing the prices down. We have already seen BEA customers benefitting from Oracle’s slashing of maintenance charges. On the other hand SAP customers need not go shopping for BPM licenses—they might get BPM offerings as a part of ERP software! With uncertain economic conditions looming, niche BPM players will take the path of innovation to tackle the threat of the package economies. A pure play BPM vendor, Fujitsu has upped the ante by promoting the usage of XBRL thereby positioning it as a de facto standard in the world of financial reporting. At the same time, Savvion and Pegasystems have already launched solutions targeting specific verticals, whereas many players (Lombardi, Appian, Cordys, etc) have stepped in with on-demand BPM offerings.

Ladies and Gentlemen, BPM space is witnessing a revolution! Aren’t we blessed to witness it? Your opinions are welcome…

Posted by Piyush Swain at 10:11 AM | Permalink | Comments (3) | TrackBacks (0)

Today SOA is the buzzword in the IT industry and organizations are grappling to have a grip on it. The confusion is – is SOA is all about ESB based infrastructure or is it all about approach or both? Organizations adopt all the three approaches and still feel that SOA is not delivering. We keep on breaking our head on getting around all WS-* standards in the name of SOA adoption or exposing application as service using adapters, and forget the true purpose of SOA. We analyzed some of our SOA implementation in our existing clientele, where client did realize the value of SOA. Interestingly, we could identify a common pattern, that reinstated our trust in SOA. The summary of findings follows:

• Use SOA to attack the most problematic area Business is facing from IT implementation — Every organization has a few scenarios like Order Processing and implementing data as a service, that are ideal for SOA adoption. In such cases, organization realize the true value of SOA only when they see SOA based approach and technology is enabling them to ease out their core business pain points. Prioritization is a must in every SOA adoption journey.
  
• Adopt pragmatic approach for identifying Service — Classic SOA Approach (Top down, bottom up and meet in the middle) is the best approach. However, the investment, business time and type of program charter required to adopt this type of approach is always difficult to get. We may argue to say for SOA approach we would require business involvement, but in reality it is always difficult to get. This leaves us with implementation of service from IT’s view of business process. However this is not a bad start at all, but at the same time we should have a provision to come out with a view of how business processes are implemented within IT. This was a specific approach we had taken in one of our client where we applied a common event infrastructure with service based integration where we generated event from service invocation which were correlated and a business process view was shown to the business with possible bottlenecks. This enabled business teams to identify relevant avenues for process improvement.
  
• Build your SOA infrastructure incrementally — Non functional requirement drives SOA infrastructure and it is difficult to get all these upfront. This escalates the cost of SOA adoption without seeing the value. However the effort should be made to provide a SOA infrastructure based on the business criticality and end point application quality of service. Hence there is no point in making SOA infrastructure highly available and perform if the business criticality and application quality of service do not meet the standards.
  
• Manage SOA adoption through a COE — SOA based solution has lot of features in common and as an organization goes through the adoption journey, it is important to manage the cost of solution from day one. If we are not able to re-use the common services like error handling, logging, data referencing, exception handling, it would be difficult to sell the idea of re-use of business services. In addition the COE should own up the initial governance of the service on business behalf in the earlier phase of SOA adoption. Also COE plays an important role in provisioning of SOA infrastructure ensuring re-use at infrastructure level.
  
• Standards are good to have but not a must have feature for SOA adoption — Standards enables easier integration is a truth, however SOA adoption should be standard based is a miss understanding. Service is all about how one exposes business function of an application to be re-used or how to construct a new business service which can be used for wider range of requirements. This can be achieved by simple message based interaction with application using MQ or any other messaging platform which the application supports. The important aspect that should be key focus for service implementer on 'what' aspect of service rather than the 'how' aspect of the service. Most of the SOA platform provider would have capability to address the how aspect but it is the onus of the implementer to identify the what aspect.

End to the day, it is good to have a service portfolio and plan out service rollout. Since business is eager to see the value added, adding business value must take the center stage during SOA adoption. I welcome your opinion on the findings above.

Posted by Manas Kumar Sarkar at 07:48 AM | Permalink | Comments (0) | TrackBacks (0)

I’m not really surprised to see the love-hate relationship between senior executives who own the integration portfolio and the ‘strategy consultants’ in my observation. Its love-hate dynamics because on one side where senior IT leadership strongly believes that a ‘strategic’ view is needed for creating the reliable roadmap for their initiatives, at the same time, there is really no reliable methods today to evaluate the appropriateness of the so called ‘strategy’ deliverables that consultants deliver. From the observation of the legacy in the enterprises I worked with, I find something very fundamental missing in those mysterious and high-end strategy documents: ‘Life’. Lack of life means that these strategies are more or less used as ‘initial requirements’ for certain programs/initiatives and as time progresses, strategies are not updated/maintained in line with changing state of the organization.

I have not seen too many of ‘good’ strategies in as far as integration/SOA is concerned for many large enterprises. So I thought I will put together a perspective on creating sound strategies for integration/SOA portfolio. To start with, I would like to share my view on what I found lacking in the strategy documents that I reviewed/audited for my clients:

• One of the big disappointment has been the ‘lose’ purpose and meaning of the strategy.  Many of the strategy documents didn’t give me confidence if they had been developed being so particular about ‘strategy’ as such. So people who developed the strategy deliverables may have not paid attention what’s really needed in a strategy  and might have limited the strategic view to just few principles/vision statements. It is quite evident when I see plethora of basic introduction to fundamental concepts like EAI/SOA/ESB/Architecture patterns etc in the strategy document. Will talk about it more in the next bullet.
• Next big issue I found in the strategy documents that really distracted the whole purpose of the strategy document. I find many of these strategy documents providing huge documentation around technical concepts, product capabilities etc and even the architecture blueprints in some of the cases. In  my view, architecture blueprints and design guidelines need to be looked as separate elements and not mix them up in the strategy. Prime reason is that it dilutes both the purposes, strategy as well as architecture.
• Another key aspect that is critical for sound strategies is the clear understanding of the elements that drive and influence the strategies. I found it very difficult to figure out why a particular strategy was the ‘right’ strategy for the organization. Strategies need to be driven by the well defined drivers (like IT strategies, existing challenges) and the expected strategic results where number of strategic options need to be evaluated to arrive at a strategy that sounds ‘better fit’ for the organization.
• Almost in all the cases, I didn’t find any significant focus on the ‘strategy implementation’. Strategies were written mostly like ‘knowledge documents’ where implementation was not much of concern. So while strategies were interesting to read, my discussions with document owners revealed that organization really struggled to figure out how to implement these strategies and as result, most of the strategies kept sitting in the document only and find their way to real-life.
• Again, almost in all cases, there was no consideration of impact of these strategies on the enterprise and no aspects of ‘readiness’ of the organization to be able to roll out these strategies. I don’t find such strategies very ‘real’. Point of strategy is not to gamble but to strengthen the chances of success.

List doesn’t end here but let me stop here. If I were to suggest how integration strategies need to created for the enterprise, here is what I will recommend to be considered in the strategy formulation based on my experience:

• Team that is creating the strategy should not look at the strategy articulation as a template that need to be filled. If that is how it is being done, that’s first sign of the disaster. Team needs to clearly understand the ‘strategy engineering’ process where set of information (like vision, issues, expected outcomes etc.) are taken as input, processes and based on certain hypothesis, strategy formulation needs to happen.
• As I said, strategy starts with getting clarity into what is driving the strategy. It helps defines the goals that need to be put forward as a ‘result expectation’ for the strategy. For example, enterprise could say that one of the key goals of the strategy should be to reduce the our TCO by 10% in 12 months.
• Team needs to consider the major influencing factors for the strategies that could be recommended. To arrive at such factors, SWOT analysis of the integration portfolio is must. Further to that, team should consider the possible scenarios that the strategy implementation could be facing and from there analysis must bring out how these strategies are anticipated to perform in those scenarios. This will help kicking out the strategies that sound exciting but can’t perform to the results in most realistic scenarios.
• Before strategic options are identified, we must identify all the strategy areas/themes where strategies need to be built. For example, for integration portfolio, it could be Architecture/Technology, Service Delivery model, Sourcing model etc.
• While formulating the strategies, there are 3 elements that need to play a role in defining a credible strategy. First: Input – something that is given and cannot be changed. Second: choices – to meet the objectives with what is given, what strategic options are available. Third : Action – how selected strategies need to be deployed.
• Once set of strategies are defined, a prioritization needs to happen based on the feasibility. Input of scenario performance of the strategies will be a good input.
• It is very important to analyze and details out the impact of the strategies on the exiting eco-system of the organization. That makes the strategies real and practical.

Unlike technology and architecture, unfortunately we can’t have one standard solution for strategies. That makes it very vulnerable for enterprises in terms of their ability to judge a strategy. But I also believe that process of strategy development itself in many ways a revealing and learning experience both for the client and the consultants. Hence in area like integration where strategy may not have been playing so much critical role so far, it must be taken very seriously as move in the next-generation enterprises. I would keen to know how my experience aligns to other practioners in field. So drop your view-points on this topic if you are here.

Posted by Rakesh Mishra at 04:30 AM | Permalink | Comments (0) | TrackBacks (0)

I am writing another blog entry on SOA knowing very well the risk of triggering a yawn and ‘not again’ response from readers. In terms of sheer volume of debates and opinions generated, SOA will undoubtedly qualify as the most productive IT topics of recent times. However, the same can not be said about the true impact it had on the IT and business. Moving away from ‘Is SOA good or for real?’ debate, I wanted to touch upon the topic of how to deploy SOA for creating tangible benefits for organization. Offcourse I assume that debate around ‘Is SOA for real?’ has been settled (in favour of SOA. Now you know on which side of divide I belong to). 

Once the initial debate on SOA among architect community in organization is over and decision makers decide to do something with it, the debate moves from ‘What’ to ‘How? More often than not, the first step undertaken by IT organizations is ‘SOA platform evaluation and establishment’. In my experience, this approach though fitting the logical pattern of establishing a platform capability first lacks effectiveness on two counts. First, the tangible business benefits of establishing SOA platform are not visible immediately and any attempt to demonstrate value invariably leads to maze of technical and architecture jargon. Second, the participation and engagement from business is almost always missing.

 I have myself faced the challenge of explaining the benefits of SOA platform establishment to business users and the response almost always draws blank. Promises of Improved modularity of software, increased reusable potential, faster application development time, reduced maintenance effort etc. always evoke the response of ‘So what?’. Is there is a direct impact on my business? Will my new product introduction, sales revenues, profitability or channel response improve? If not, is this another expensive toy IT geeks have got for their fun?
Recently, I witnessed a painful phase in SOA platform establishment program for a customer wherein the scope had to be altered in the middle of the program to include tangible benefits to business, else the entire program faced the risk of being scrapped. How can IT decision makers avoid such situations and potential failure of initial attempts of SOA adoption?

An analogy from Greek mythology provides interesting approach to respond to this challenge. The story of ‘Trojan Horse’ from Homer’s Odyssey. ‘Trojan Horse’ was the trick Greeks used to enter the city of Troy during the Trojan war. In the context of SOA introduction, ‘Trojan Horse’ approach will involve deploying SOA principles, platform and patterns in the organization, but with the help of a ‘Trojan Horse’, an IT initiative that lends itself well to SOA principles adoption and delivers significant business value at the same time.

In my view, following are some of the attributes that can be considered for selecting such initiative.

Business attributes:
·         Improving the performance of processes interfacing with customers or key partner channel
·         Improved visibility into key data and processes
·         Enabling a new business model for organization
·         Addresses key regulatory and governance concerns

Technology attributes:
·         Involves multiple applications or system of records on heterogeneous platforms
·         Spans beyond the organizational boundaries to include customer and external partners
·         Requires high level of scalability
·         Includes IT modernization elements
 

Careful selection of sponsoring project, considering the above factors can provide a platform for SOA introduction coupled with business benefits. In my experience, initiatives related to Enterprise and partner integration, process integration and automation, process monitoring and reporting, supply chain visibility and executive dashboards are types of solutions that have the potential of being perfect ‘Trojan Horse’ for SOA.
 

Would like to know how you feel about the challenges related to initial introduction of SOA. Do share your views.   

Posted by Kapil Mishra at 07:23 PM | Permalink | Comments (0) | TrackBacks (0)