The Infosys Labs research blog tracks trends in technology with a focus on applied research in Information and Communication Technology (ICT)

« November 2009 | Main | February 2010 »

January 22, 2010

Can BPMS expedite Application Development?

BPMS brings in the capability to model, execute and monitor processes carrying with it the promise of flexibility, workflow automation and process management. It is finding increasing use in organizations at different levels: be it for better management of its processes or just for integrating different applications.

 

The question I would like to pose here is “Is it worth for application developers to use BPMS for application development?” BPMS definitely offers lots of features useful for application developers out of the box. These include Quality of Service (QoS), state-storage, monitoring capabilities, failover support, reliability, SLA management, task allocation, amongst others. Today, some of the BPMS tools provide e-form generation capability while others even provide process mashup capability out of the box.
If application developers  plan to use the BPMS for application development by leveraging the available features, let’s find out the possible set of problems. Firstly if a commercially available tool is chosen to implement the application, the license of the tool needs to be purchased. The license cost of the BPMS tools vary from $25000 to $1 million. Considering this, this approach makes sense only if the organization has available enterprise licenses of BPMS which can be used for app dev. The other alternative is use one of the low cost or open source BPMS options. Usually a product/tool , even if it is lightweight or open source, would need the support so the client has to sign up the annual support contract with the product vendor.
Most JEE based BPMS tools are deployed on clustered Application servers. This enables the BPMS to be scalable but at the same time creates a need for extra hardware for deploying each application server and database server. Though the cost of hardware today is not very high these days still this is an extra cost to the company in case it opts to use BPMS for application development. A high performance BPMS where a single instance can hold high volume of transactions is more useful in such a scenario.
I would like to see the case studies where BPMS is used for application development rather than process management. We need to evaluate the ROI of using BPMS for application development based on those case studies.

January 19, 2010

Agile BI - Why it makes Business Sense

I, like most of the BI dreamers and practitioners who get challenged by latest in the BI world, have been trying to make some sense out of the mad rush towards host of BI solutions which are claiming to reduce latency between data creation to decision taken. Making an effort to simplify the whole perspective of Agile BI.

For years faster processing, reduced costs, automations have driven the IT budgets of organizations. The result of this demand from IT is: increasingly complex world of ERP, Supply Chain, CRM, Financial applications, BPO based applications. However, in today’s fast changing world where latency between data creation to decisioning leveraging that data is reducing - those applications in itself are no longer serving purpose of competitive advantage for corporates - because that every other corporate too have.

Reduce the IT investment and increase the operational efficiency - two inversely proportional aspects theoretically, but then again isn't that what every CEO/CIO is demanding? We have been hearing terms like Real-time BI & when someone realized that's not practically possible it was re-framed as near Real-time BI. If that's not enough to confuse you, let me add another term "in Memory solutions" - which will act like a blackbox between source systems and end-reporting systems, and with a magic wand, provide you with an integrated live transaction data to do BI reporting on.

We already understand and know about the Agile development methodology of Software Engineering principles. Typical Agile methods break tasks into small increments with minimal planning. Iterations are short time frames, called timeboxes, of few weeks. Each such iteration involves a team working through a full SDLC including planning, requirements analysis, design, coding, unit testing, and acceptance testing via which a working product is demonstrated to stakeholders. The key to success of agile methodology was the IT teams were able to demonstrate tangible results to stakeholders in shorter spans of time, and allow them to add value to enhancing solution towards their needs.

Effectively all those new terminologies/solutions are result of the pains the organizations have been going thru to deliver effective decision systems in shorter span of time, and thus the advent of term "Agile Business Intelligence". Agile BI can be defined as inexpensive (in terms of lesser resources or time or infrastructure), quick access thru visualization to the wealth of information lying in any corporate that can be brought to the desktop of business users for which its relevant, context sensitive and timely. Benefits:
1. Low upfront investment - fraction of overall BI budgets
2. Immediate yields for better business insights
3. Daily non-technical users of business data can work directly with the data effectively, intuitively, and yet have better insights towards solving their business challenges - instead of requesting IT to provide those solutions
4. Allows for data modifications, drilling, mining, filtering etc
5. Focused on business users rather than technology - equipping users to be innovative, creative and find their way towards answers to business problems

Today the target audiences for Agile BI are small to midsized organizations, and even the smaller departments within few large corporates, as for them agility and responsiveness to the data needs is utmost priority.

Expectations from an Agile BI - Business Perspective
1. Give me tools that i can navigate and work my way around - with minimal to know help
2. Should have the insights into context sensitive data - drill down/up, slice/dice, filter, pivot, compare, merge etc functionalities
3. Flexibly add more data sources to increase scope of analysis
4. Least dependency on IT for any data need
5. Better visualizations, intuitive dashboards/scorecards, graphical representations etc

Expectations from an Agile BI - IT Perspective
1. Tools that can integrate with variety of data sources, scalable, handle larger sets of data etc
2. Require least involvement and technical support once implemented
3. Scalable model from department to Enterprise level strategy and solution

The concept of Agile BI can be related to the maturity of a product wherein companies provide early adopter mechanisms to their customers - giving two fold benefits, organization adopting early can tune their solution on the product & product matures when it gets real life taste. Similarly exposing BI systems to stakeholders, using Agile BI, quite early in the game, will help business stakeholders shape their vision and provide concrete feedback about the system. This in turn will allow the developers to respond by continuously maturing the system to align with the stakeholders' vision.

In my view the Agile BI is definitely going to shape the future of BI in a big way, bringing down the cost of IT and yet remain operationally efficient. Especially when we have burnt our fingers in the recession times recently. I would like to hear your experiences in speeding up decisioning for your customers, and thoughts on Agile BI – the way forward.

January 6, 2010

How do web 2.0 technologies really impact business processes?

As I think about the linkage between web 2.0 tools and collaborative behavior in an enterprise, I came across a great article that brought a lot of clarity to my thoughts - http://whatmatters.mckinseydigital.com/internet/using-technology-to-improve-workforce-collaboration

What this article really covers is the styles of collaboration that are adopted by knowledge workers and best fit technology and tools that support these styles of collaboration. This provides a method that simplifies the analysis of the collaborative needs of an enterprise and increases the robustness of the decision making on the acquisition and application of the right web 2.0 technologies.

The big question then arises - can web 2.0 technology get implemented in a prescriptive manner or through top-down policies for certain kind of work processes and workforce style within an enterprise?

In my view developed through personal experience and reading reports, it is clear to me that web 2.0 technologies enhance and explode the interaction possibilities that would otherwise not be possible due to constraints imposed by time, availability, relationship and trust and corporate budgets. Hence while we are redesigning processes to take advantage of these technologies, it is important not to hardcode technology with business activities but instead to provide a range of technologies that can be chosen by knowledge workers to increase their effectiveness. In a way this is like keeping all channels open for interaction between customers and customer support function whether the channel is telephone, web, email or physical service desk. The choice of which channel to use ultimately rests with the customer and so should be the case with knowledge workers.

So I would recommend companies to plan for an infrastructure that encompasses all possible methods of collaboration and let the basket of web 2.0 technologies be available to processes with high interactivity needs!