Infosys’ BPM-EAI blog offers a platform to discuss the latest trends in the Business Process Management and Enterprise Application Integration spaces. Exchange thoughts, ideas and opinions with Infosys experts on how BPM and EAI programs can be leveraged to achieve operational excellence and maximize your return on investment.

« April 2011 | Main | June 2011 »

May 31, 2011

Simplify with Complex Events Processing

Customer Data is like the oxygen processed by the lungs and heart (systems in information technology) and injected into the blood (business processes) of any Company. Simplified, the purpose of IT is to harness this key information for the improvement of business operations. Eventually the goal of business is provide the best services to their customers. It is even more significant to know this information for a prospective customer which has the potential to increase the business for an organization. There is no secret that a company outwits competitors just with better customer satisfaction and services at the same time maintaining lower TCO and increasing bottom line. The question in today’s world when IT is ever changing, what is the current scope in usage of technologies such as complex event processing.

Consider a hypothetical scenario of events captured by different IT systems:

  1. A user located in suburb of Chicago (probably a fan of Manchester United) joins the facebook page for ManU on Jan 31 2010
  2. ManU launches a new series of accessories in collaboration with its sponsors and partners like Nike, Audi and Aon in mid of Apr 2010
  3. This fan as a registered user in ManU database follows the link on facebook page for the US online store to check the new accessories but does not buy. He visits 4-5 times the same site between May 15 and Jun 15 2010.
  4. ManU wins the spanish league in Mar-Apr 2010.
    ManU loses the UEFA champions league in May-Jun 2010.
  5. The fan updates his own page that he bought a 2009 version Man U accessory such as T-shirt with the team photograph from Amazon in mid Jul 2010.

Before the start of the next season, A report on the inventory is generated for the marketing leads on the sales in the last season for the accessories in account of the sponsor companies. The report shows that there is still a good load of stocks in their inventory and warehouses of the retailers and the sales are less than expected though there has been a little variation due to the wins or loses of the ManU games.
Market leads gets another report from Market Research team. The research analyzed that only 10% of the purchasers are hardcore fans who will buy any new that comes up. Around 30% of the purchasers follow ManU but would wait and buy only if there is discount or exclusive coupons and only partially get affected with loses or wins of the games. Others are not fans and buy sporadically who the variation is proportional to the loses or wins.

Though the above events were independent and happened over a period of half a year, there is a relation and if captured properly can provides intelligence to capture the 30% fan base to increase the sales and revenue.
This is possible with the application of technology “Complex Event Processing”. Traditional IT tools can only capture events in a short span of time and complex coding would need to be done to get the desired result. Business Intelligence can capture reports over historical data but cannot act on the basis of patterns. CEP fills this gap and provides the tools and means to catch, process, apply the pattern over weeks or months or years if required and even predict or provide customized solutions based on the configured rules.

In the above series of events, a CEP solution could have easily recorded the fans checking out pages but not purchasing (lets say more than 5) on the accessories and also integrated through 3rd party tools that access the user activities for ManU website. Based on the customer info and actions over different set of systems, one of the simplest solutions can be to process coupons and send as an email to the customer on the new accessories (obviously with usual marketing messages such as exclusivity, stores near the customer location or online itself). There is more chance that these fans will grab such opportunities and go for the purchase eventually providing a win-win situation to both the fan and the organization.

May 30, 2011

Where a generalist is a specialist

Generalist is defined as ‘One who has a broad general knowledge and skills in several areas’ and a specialist is defined as ‘One who is dedicated to one particular branch of study or research’.

In our day to day life we come across both the type of experts, like in health care we have Physicians (who are generalists) and other -ists (who are specialists in areas like Ophthalmology, Oncology, and Neurology etc).

Likewise in the world of IT Services, we have both kinds of experts, hence the McKinsey Matrix of service delivery units being formed as Horizontal and Vertical units, where Horizontal Units take care of the breadth of all the specializations like packaged applications, while the vertical units focus on the domain specific needs.

Having said that - EAI is a space considered to be horizontal, but an EAI consultant needs to have very deep understanding of both the worlds. Let us take an example as to why we need generalist with specialist like skills in EAI.

Here is a small anecdote from one of my colleagues talking about his past experience. It was a season of outsourcing in a major F500 company and they outsourcing for the first time. The expectations ran high and a simple task of generating a report from an application was considered a “great” achievement at cost cutting. As Murphy would have it, that day when the demo of the “outsourced team” developed report generation tool was being showcased to the higher-ups, the manager drew a blank report on the screen.

As you might have guessed by now, somewhere the data link got lost and this had to be fixed immediately (say with-in 10-15 minutes). The Infrastructure team that was responsible for the database and the data sink mentioned that data was intact and the query too was a success. The portal team which was responsible for “display” of the report on the screen mentioned that the data did not reach the said rendering component. So everyone made the poor EAI team the fall guy.

Then started the great hunt for the vanishing data! Query was checked manually and the results were accurate as expected. Even the queue through which the message (with results) was to be passed also worked well. Now the puzzle remained as to where the data had gone, as the message subscribing utility which picks up the message from queue and places it as a file too worked well and placed the file on the disk. The file picking utility from the application server picked the file and deleted the same within the SLA time meant for the same and yet the data is not being rendered on the screen. Everyone mentioned that something went wrong on the EAI side, as they are the only folks who talk to every application owner to get things going.

The onus of debugging the entire supply chain of data fell on my colleague and he started out testing each of the components and writing his own code mimicking the components. Finally he found that the file being picked up by the application server was having 0-bytes and on further digging into the case found that the disk had some bad sectors and the files were getting corrupted.

Had it been the case that an EAI specialist was only a specialist in his/her tool alone, say Tibco/webMethods/Vitria/MessageBroker the case would not have been resolved. An EAI specialist means, he/she not only needs to know his/her tool of specialization but also should know JAVA/C/C++, with at least one scripting language, say PERL/TCL and some working knowledge of testing with idea about quality.

Hence we at Infosys have a dedicated Academy for all of the BPM-EAI folks as a part of larger Enterprise Solutions Academy, where the generalist with specialist like skills are imparted to the consultants.

May 18, 2011

HIE Integration: The Future Lies in the Past (and the Present)

Guest Post by Dave Bennett, Chief Technology Officer and Board Member of Axway NA. Dave regularly blogs on topics related to B2B integration, Cloud Computing, Enterprise Application Integration (EAI), and Health Information Exchange (HIE).

When it comes to how the Health information exchange (HIE) market is integrating into their customers’ and partners’ systems (providers, patients, states and regions), the market has yet to catch up with its supply chain, high tech, manufacturing/CPG and financial services peers. Yet it is fielding the very same challenges these markets faced decades ago when faced with the problem of handling a host of varying semantics (information structure, meaning, and purpose, not just syntax) across critical value chains. And it’s doing it with new, supplemental innovations on hand.

HIEs and their customers and partners use different semantics in different ways, generating the very same security and privacy challenges the aforementioned markets once had to solve - but with undeniably greater urgency, since now we’re talking about the exchange of sensitive data contained in patient records. Today, providers are spending too much time looking at detailed medical records that don’t summarize the information the provider wants to see.

How do we make this data align semantically and make it useful at the same time? How can HIEs successfully and securely communicate a range of small to high-volume bursts of sensitive information despite the wide range of structures, patterns and protocols required to align providers, patients, provider networks and hospitals?

Well, the federal government has been investing a lot of money - digitizing health records and creating a fluent exchange forum - in an effort to answer these questions.

What this investment ought to be honing in on is the challenges that traditional value chains have always had to solve: processes, structures, semantics, security and trust.

Federal government efforts don’t directly address the hardest integration challenges, which center on the demands of semantic alignment, protocol alignment and trust alignment. In fact, most HIE-focused technologies seem to ignore these three patterns completely.

That’s a mistake. Because it’s these same patterns that have successfully been solved and deployed across very large value chain environments for quite some time.

And supplementing this legacy are new technologies - for instance, content-based routing, community management, and problem notification. Content routing enables routing of messages based on key elements you define. Yet, one of the problems of classic information exchange is that when a message errors out, the error message simply gets sent back. The sender isn’t engaged to correct it and it could take months for the error to receive human attention. But if you combine community management tools with the ability to receive notifications from registry services when there’s a problem with a particular data element, then you can alert community members, fix problems quickly and work to increase the overall value of the information moving through the hub.

Doesn’t it make sense that this approach - older, successful technologies supplemented by new technologies - should be deployed across HIE environments? Doesn’t it make sense to solve problems in a classic way when you can, and at the same time leverage new innovations?

May 5, 2011

Web of Web Services

In the era of BPM, with much more enhanced tools and techniques, let's look at a more common and realistic scenario. Where disparate systems identify to interface with other systems, web services, play a huge role. Need of the system is to get the information as fast as possible and accurate for sure! As cliché as it may sound, the very concept of web services is to ensure application interfaces are not affected. But, this pool of web services ensures that they are not left untouched. One of these scenarios, customer information system highlights this phenomenon clearly. Few characteristics that could have been over looked or been in place initially and lost over time:
- Business perspective to technical requirements
- Long term vision for middle ware technical architecture
- Evolve the architecture based on introduction of new entities
- Standards and guidelines for middle ware ever emerging development cycle.
Having defined a middleware tool to ensure the systems are connected is only half the job done. To ensure the operability and maintenance of what is developed is a bigger on-going challenge. Not forgetting to include enhancements. While architects struggle to identify the correct approach of which functionality to fit into which web service, developers struggle to fit the pieces of code into the existing web of web services.
With this highly complex set of interfaces, web services revolve around content and data. And much of the installation, configuration and maintenance work are done manually. This means managerial talents, user-experience knowledge are as essential as defining the technical architecture. At the core, following features when implemented would benefit the landscape of middleware:
- Simple Configuration
- Minimal or no Application Code Changes
- Interoperability
- Increased Application Performance
- Optimizing network traffic
- Increased Scalability/Maximized Network Throughput
To re-iterate the obvious, in most practical scenarios with ever reducing variables of budget and time, it becomes more of a necessity for architects to have holistic and futuristic vision of technology with business perspective.