BPM-EAI

I just came across group ABPMP(Association of Business Process Management Professionals) Toronto chapter. It's good to see these groups being formed to take BPM execution forward. I am yet to go through to see the activities to be taken up by these groups.

Another thought that came across the same lines is the recent trend of Mobile apps . All the Product companies in Mobile , Gaming industry are creating the platform and driving on the Collaborative model of people enhancing the applications on the platform. Having same analogy in BPM, I think there are many platforms already existing by multiple vendors , now is the time to throw this for Collaboration to open forums for building the Business Process Models which I call it as Collaborative BPM(Modeling) .

Collaborative BPM will be the key for Knowledge Management and Sharing in Industry Process Knowledge where we will arrive the best practice solutions for thousands of processes existing in each industry. Could anyone have imagined in 90's to create a knowledge base currently available on Wikipedia . These processes in similar fashion need to evolve and have multiple variances available for people to choose the best model practiced and plug it into any of the BPM products.  

Following factors need to be considered to make this feasible

Volume of Processes -  There are too many processes in any organizations, can we do it all of them.

                Prescription : As mentioned this has to evolve in collaborative mode as people are free to update based on their knowledge. Specialist will come forward and expand their knowledge through the platform.

Standards - There are two areas to be addressed

1-      Modeling Tool Output

This will be left to contributors to choose the platforms which will be more usable and also on Product companies to support portability of tool output to products.

2-      Processes

There are no standards for these processes and have grown over the years based on Org needs and maturity .

The intention of this exercise will not be to create a standard process as its going to be difficult to put standards unless they come as law/policy like US GAPP , Sarbanes - Oxeley , KYC. The intention is to have best process models available for use for future businesses or existing businesses to adopt.

Confidentiality - Important factor . I believe this still stands to be the problem of Web 2.0 in general . The important starting point here is to avoid Organizations and Customers disclosure to avoid this.

Validation and Verification - I think this directly relates to the usability issue. Will these models be usable once they are in place. My belief is YES once they are matured . In India for Travel people still believe in asking the people on road than Google Maps / India Maps as they are not yet matured . It takes time but the usage will increase over time. I can easily imagine how easy will it be to setup a new Business in 2020 as the processes will be matured and available handy to implement.

I believe there is just a need of platform for people to start modeling processes and let it mature the Social / Collaboration way. Soon we will see process models platform on Wikipedia , Google . The operating model will be similar to all open source forums, what is required is the backup by companies like IBM, MS and PEGA. I can imagine buying PEGA in TESCO / WALMART , Download Payroll Processing model from cbpm.com , upload and configure for business.

Posted by Girish Kukreja at 2:37 PM | Permalink | Comments (0) | TrackBacks (0)

We have seen that over the period of time organizations have invested heavily into SOA and BPM primarily to bring business agility in responding to change in their business scenario. In my opinion SOA has definitely brought about a transformational change. We could leverage existing investment organizations have made in the legacy applications and ERP systems and could expose their functionality as reusable services using SOA as architecture model. SOA has also provided sophisticated integration technologies like ESB (Enterprise Service bus) to build complex business processes around these services. We have been using BPM technologies to bring in agility in modeling and implementing new business processes on the fly and utilized SOA infrastructure and services to automate large parts of these business processes.

Even though BPM & SOA has brought considerable improvement I see these mostly reactive in nature. SOA functions and BPM provide business processes which mostly react to the user requests. It's not a mandate of SOA to identify trends and patterns across these requests and then proactively take action to benefit from these trends or avoid any unusual happenings. SOA & BPM does not proactively identify suspicious happenings across tens of thousands of these invocations. This is precisely where Compex Event Processing (CEP) comes into picture and brings the benefits of being a watchdog which can sense new situations and abnormalities and respond to these. CEP gathers hundreds and thousands of events originating from SOA and BPM and uses the rules to identify patterns which suggest anomalies, threats or opportunities. It then alerts manual or automated processes to take corrective action. Typical application of the CEP technologies can be identified which requires some form of "situation awareness" or "sense and response" and "tracking and tracing" aspects which are predominant in business situations.

Posted by Prakash Rajbhoj at 7:47 AM | Permalink | Comments (2) | TrackBacks (0)

What happens when the one of the world's largest retailer invites its partners to a forum and ask them to share equally the great responsibility to go real environment friendly and greener? Plan was laid for co-development of a sustainable product index with the idea that this index will provide customers with the transparency into the quality and history of products that they don't have today with the focus on following four areas: energy /climate, material efficiency, natural resources and people / community.

This phenomenon is referred as corporate social conscience. What followed is an avalanche of PR from vendor after vendor claiming that they were greener than their competitors

Let me open a Pandora's Box on how SOA is enabling the green IT infrastructure.

Out of many definitions of Green SOA, in simple words - a green SOA allows us to blend green concepts psychologically and in a symbiotic manner into enterprise business processes, a win-win for the corporations. Green SOA allows a corporation to minimize economic demand (such as rising cost for energy, raw materials, and waste disposal), satisfy customer and stakeholder demand (such as environmental, social, competitive or market scenario) and compliance (such as regulatory requirements or legal constraints).

Here IBM as one of the industry leader in innovation seized upon the business concepts of carbon emission management for policy and linked it to a metric called a KPI (key performance indicator) as a base for what it calls Green Sigma. KPIs are metrics used to help organizations define and measure progress toward organizational goals. Apply this concept to carbon management, and way to go green SOA.

IBM's Green Sigma is five-step process that begins with the definition of KPIs till finally to track and account for carbon credits, also known as green currency. Carbon Credits then can be exchanged (for example, to finance carbon reduction between global trading partners), bought/sold on developing international markets at the prevailing market price.

Until sometime back, the concept of carbon emissions management was limited to Pen & Paper. With the arrival of green SOA tools and concepts into the marketplace, corporations can begin to develop, implement, monitor, manage, and govern everything from green business processes to green IT infrastructures. Not only business costs will decrease, but process improvements will occur through increased compliance and improved performance.

Have you witness Green IT around you and how it is benefitting. How other technology vendors are doing? Please do share your experience.

Let us know your feedback and valuable suggestions on this blog.

Posted by Manish Kumar Gupta at 5:48 AM | Permalink | Comments (0) | TrackBacks (0)

Service Oriented Architecture (SOA) is a business-centric IT architectural approach that supports integrating your business as linked, repeatable business tasks, or services. With the Smart SOA approach, you can find value at every stage of the SOA continuum, from departmental projects to enterprise-wide initiatives.

Below are some of the availabilities of SOA.

Application Infrastructure Build, deploy and run applications in a secure and flexible SOA environment.

Application Integration At the core of a Smart SOA deployment enabling seamless universal data exchange.

SOA Governance Helps you make better IT decisions and drive service re-use value.

SOA Management and Security Enables visibility to monitor and control SOA based services and applications.

This new IT delivery model can significantly reduce enterprise IT costs & complexities while improving workload optimization and service delivery. Cloud computing is massively scalable, provides a superior user experience, and is characterized by new, internet-driven economics.

Information technology is changing rapidly, and now forms an invisible layer that increasingly touches every aspect of our lives. Power grids, traffic control, healthcare, water supplies, food and energy, along with most of the world’s financial transactions, now depend on information technology.

Cloud computing has been gaining increasing attention from businesses of all sizes as a way to obtain secure access to advanced technology that is not necessarily owned or hosted by the user. Midsize companies, those with 100-999 employees, can benefit from cloud-based capabilities. The variety of applications and approaches to cloud solutions and the different resources companies can draw on will make a difference in how these companies implement cloud computing into their business. According to IDC research, public cloud approaches are beginning to gain traction among midsize firms, while private cloud solutions are far less prevalent. Roughly twice as many midsize firms plan to implement public cloud solutions compared with private cloud solutions in the next 12 months. However, IDC expects SMB spending on cloud solutions to grow by 20% annually over the next five years.

Let’s know more about Cloud Computing more…..

In its most basic form, the cloud can be described as on-demand computing for anyone with a network connection. Essentially, users access applications and data located on their available network. Wherever a user can access the network, the user can also access his/her cloud. Consumer-level cloud computing exists with sites like Facebook and Flickr which act as digital holding areas located on the Internet. This model is also evident in web-based mail such as Gmail and Hotmail.

Clouds can be categorized into Private and Public. Private clouds exist within an organization and Public clouds exist to provide services to users outside of an organization. The common thread is the location of application processing by a physical data center may be anywhere on the clouds network.

Using the cloud, organizations and individuals can use computers in a more flexible, efficient, and scalable manner. The cloud is easier to manage than traditional infrastructures.

As defined by many in the industry, the commercial Cloud comprises three layers: Infrastructure layer (which supports Infrastructure as a Service), Platform layer (Platform as a Service), and Application layer (Software as a Service, or SaaS). Unlike the previous generation of the model, in which multiple, dedicated instances of the software were hosted by the provider on behalf of clients, cloud-based SaaS is a single instance, multi-tenant delivery model. This decreases the provider’s labor and infrastructure requirements, which leads to lower costs for clients.

Have you come across the Clouding? If yes, then please share your views.

Posted by Musa Shaikh at 5:20 PM | Permalink | Comments (0) | TrackBacks (0)

Earlier this week, during the Welcome Keynote by Oracle CEO Larry Ellison at the Oracle OpenWorld, Oracle introduced the world to Oracle Exalogic Elastic Cloud. As a side note, the Infosys CEO was there as well at the event. The OEEC is a complete system of servers, network, storage, VM, operating system and middleware, all engineered to work together thus providing the foundation for a highly elastic, super-fast, secure and proven platform to host the entire enterprise application suite. The proposition being offered is simple. With cost containment being a major driver for most IT organizations, there is an increasing trend towards opting for setting up a private Cloud. It is this market that Oracle is trying to target by offering a machine that can host all the applications that would usually reside on a multiple hosts and allow the administering and metering capabilities that are crucial for operating the virtualized eco-system. The OEEC is a package of hardware and software components boasting of a 64-bit x86 processors, an InfiniBand-based I/O fabric and solid-state storage with Oracle WebLogic Server, other enterprise Java Oracle middleware and a choice of Solaris or Linux. Due to this, it offers the computing capacity required for hosting a private Cloud.

My view

Oracle has long been trying to convince its clients the concept of Enterprise in a Box. The concept of a fully loaded rack with enormous computing capacity and all relevant Enterprise Applications pre-installed and ready to go with minimum fuss is at the core of this offering, and this latest offering is a logical extension of that trend. While the OEEC does make a compelling proposition on the face of it, its not really a Cloud-In-A-Box as Oracle would like us to believe. The way I see it, it's a highly potent platform which supports dynamic resource allocation and metering.

Lets look at the things that work in this offering :

1. Faster than the Cloud : Definitely. With a super optimized platform and co-located software (yes, it all resides on a single physical box), the latency is obviously minimal - something which is not realizable over a network in a real multi-tenant solution such a remotely hosted Cloud.
2. More Reliable than the Cloud : Lets face it, Security has been a top inhibitor for Cloud adoption, and with OEEC, these concerns are greatly reduced due to, again, the 'co-location' factor of the OEEC offering. Its all still within the Enterprise. Its also more stable, at least for the on-board components due to the robust architecture incorporated.
3. Greater InterOperability : The Software stack is all developed on the Fusion platform and once the integration of all the acquisitions is complete, the software stack will be seamless and highly efficient. The enhanced compatibility of the software lends itself to simpler configurations and thus it takes much less time (and cost) to get it up and running. In fact, the software deployed to the reference system uses default tuning and configuration to get you started. The platform is also closely integrated with the Oracle Cloud platform.

Why will it not replace the Cloud ?

1. Higher Costs : Well, lets face it, this just another fancy hardware(plus software) platform that needs to be purchased up front and installed before you can start using it. While, the exact cost details are still not known, there is definitely a bulk investment required. The usage metering is to allow charge-back from the users as opposed to metering the TCO for the enterprise. In that sense, its no different from setting up a traditional server farm for hosting your applications.
2. No genuine Multi-tenancy : The enterprise applications are all hosted on the same machine and if the machine is decapitated for any reason, the only resort is to fall back to the DR option, which is no different from what needs to be done in a traditional "Server Cluster" world.
3. Still Requires Maintenance : One of the most compelling offering of Cloud Computing is the almost complete lack of any maintenance requirements for the users. This is in-fact a basic tenet of a service. It should be noted that the almost 60% of the TCO during the life-cycle of a platform is contributed by maintenance costs and its this cost which is obviated by the Cloud Service. The OEEC still requires a dedicated platform support team to keep it up and running. 

All said and done, the fact that the Enterprise should concentrate on running its core business and not spent effort (and mind share) on the platform is one cogent argument offered by the proponents of the Cloud Computing mantra and hence this offering from the Red Giant still doesn't qualify as a real "Cloud in A Box".

For the moment, I am with Benioff, a former Oracle executive and now an Oracle competitor. "Clouds aren't in a box," he said during an earlier OpenWorld session. "That's the whole idea."

Posted by Maloy Patnaik at 6:55 AM | Permalink | Comments (1) | TrackBacks (0)

Point of View

One point where there is agreement is that today we work in area dominated by terminologies which do not have clearly defined meaning and is open to interpretation. Good example is: Business Process Management (BPM). BPM has been divided into various categories human or system centric, structured and unstructured, etc based on the nature, actors, etc. In this article we will try to explore the various faces of Business Process Management.

Business Process Management discipline is “a synthesis of process representation and collaboration technologies that removes the obstacles blocking the execution of Management intentions and can have multiple players who are either Human or System.”

Business Process Management can be discussed from the perspective of a discipline and available packages enabling implementation of BPMS as a discipline.

BPM as a Discipline

BPM discipline emphasizes on overall approach to coordinating work across all resources - people, information, machines and systems. Coordinating the interactions across this broader set of resources requires workflow technology, embedded in the BPM suite to coordinates the interactions between all resources. Workflow is just one of the many technologies found in a BPM Suite today some of the other critical technologies are BAM, Rule Engines, quick UI creation toolsets, and a graphical authoring environment ideally based on Explicit Process Models.

In conceptual terms, BPM is used to facilitate the following sequence of activities needed to:

• Move data between applications to change status of “systems of record” or provide ability to an actor to act based on certain set of well structured steps and Business rules.
• Facilitate collaboration between knowledge users as they use their expertise and judgment to decide upon the next set of actions based on the uncertain situations.

Having said that, BPM discipline can be categorized as Structured and Agile BPM as described below.

Structured BPM

In structured Business Process Management, rules and processes defined as design time drive the flow of the Business Process. Structured BPM can be used to allow software/hardware devices as well as Human to integrate with each other in certain set of well structured steps and Business rules defined at design time. An excellent illustration of this is found in the financial industry, where clerical workers - who have very little knowledge about the claim and processing but is able to processes claims.

Agile BPM

The fundamental distinguishing characteristic of this approach is that knowledge workers, rather than rules and processes, drive decisions, Whereas structured BPM tasks are guided by defined (and inflexible) algorithms, Agile BPM allow users to interact with each other and set their own parameters. Agile BPM will work only if knowledge workers are allowed free hand to evaluate the request and if necessary propose alternatives rather than a task being assigned by the manager with the expectation of a binary outcome (done/not done). Knowledge workers decisions should drive the sequence of flow, who will participate and SLA of the Business Process.

Takeaway

In an ideal world, the negotiated commitment should be the essential unit of Agile BPM software solutions. The problem with most of the BPMS packages implementing BPM is that they are built on the “command and control” framework used for structured BPM in which orders are given and expected to be followed. Although with the exposure of Business Rules and advance Business Process Modeling capabilities, there is some form of agility that BPMS packages provide there by enabling development of hybrid Business Process combining structured as well as some aspects of Agile BPM Business process.

Package implementation of Business Process Management

Business Process Management Tool/Package can be Human centric or System Centric depending upon the capabilities that they provide.

Example of some of the rich Human centric BPMS package features:

• Independent environment for Process Modeling.
• Rich User Inbox features.
  • Task Management.
  • User Management.
  • Task Search Capabilities.
  • Task Notifications.
  • Task Escalation.
• 360 view Reporting.
  • Business Process visibility - BAM.
• Efficient KPI / SLA Management.

Example of some of the rich System centric BPMS package features: 1. Enterprise Integration capabilities. 2. Workflow capabilities.

Most of the packages today provide both system as well as human centric capabilities; it is the depths of these capabilities were one product scores over the other.

Conclusion

Business Process Management discipline should not be categorized into Human Centric or System Centric; on the contrary Human and Systems are just actors participating in the lifecycle of a Business Process. Extent of Human or System involvement totally depends upon the nature of the Business Process and the kind of problem that it is trying to solve. BPM can either be Structured or Agile, although most of today’s BPM solutions implemented using BPM packages are hybrid (a combination of Structured or Agile). BPM Tool/Package can be Human centric or System Centric depending upon the capabilities that the tool provides. BPM packages have not matured enough to support in principle Agile BPM.

Posted by Mohammad Faizan at 6:45 AM | Permalink | Comments (0) | TrackBacks (0)

Google changed their main search page from Static to Dynamic with Instant. One of the challenges as pointed out in their official blog was increase in 5-7X hit to their servers due to this enhancement. Naturally the Infrastructure team had a huge challenge to deal with this without affecting the existing performance. But they solved the problem with changes as pointed out in the blog. Performance as we know is an obvious expectation from any solution from a Non functional requirement (NFR) perspective but still in most of the solution implementations it is not given the same impetus that the functional side usually gets. Most of the projects in initiation stage wouldn’t have planned for addressing the non functional requirements as compared to addressing the functional requirements. Down the lane during the software development it is often experienced that performance is not as expected and then time and effort is spent on tuning the solution to meet the NFR through cycles of load testing-fixing-testing. Though Performance Engineering is a vast topic, the interest in this post is towards an architecture pattern called SEDA (Staged Event Driven Architecture).

Briefly about SEDA, it was envisioned way back in 2000-01 as a pattern to address the performance problem associated with high concurrent processing such as web servers overloaded with requests (note the connection to Google or any search service provider problem). The creators of SEDA based their hypothesis with the knowledge that most of the software applications as well as the Operating system execute the incoming requests concurrently as concurrent threads but not as concurrent events. SEDA’s principle is to add a layer for processing by considering Events as separate Stages. Basically, distribute applications (or modules) as separate stages and process them under separate queues. This way if we take the example of web server, it can combine aspects of threads and event-driven programming which in theory should provide better performance benefit. The original theory and explanation is explained in the white papers in the above referred site. Carrying forward the theory to middleware, consider the following example of a standard interface implementation in an EAI implementation. An EAI implementation will have multiple such interfaces using a VETRO (Validation, Enrichment, Transformation, Routing and Operate) pattern. In Figure 1, the implementation showcases traditional EAI concepts about when an event is generated, it will be traverse through multiple steps in an interface as the message gets enriched and transformed from original system to destination system. But the same event when generated in realtime through multiple sources will be handled by the underlying engine concurrently. If there are 50 threads, then 50 concurrent messages are processed concurrently. In Figure 2, the implementation showcases how each stage in the interface is configured to listen to a queue independently. This way each of the stages would be configured to have its own set of threads at runtime. With this pattern, one of the advantages is reusability. Any stage can be independently configured and can serve multiple event types and not necessarily one type. Second development itself can be broken up. Third this can easily be adapted to SOA etc, etc. Performance should increase as possibly different stages could run in parallel depending on whether it needs to wait for data from previous stage. On the flip side, disadvantage is in maintaining additional components. Second, number of failure points increases. Third, transaction management becomes complicated etc, etc. It can be observed thus that not only thread concurrency but event concurrency can also be employed with this pattern. Not all EAI vendors in their suite or their SDK packages have support for this pattern. Some examples which support SEDA are open source ESBs such as Mule ESB and Apache ServiceMix ESB.

Posted by Narayanan Chathanur at 12:00 AM | Permalink | Comments (0) | TrackBacks (0)

It has been fascinating to see the recent advances in robotics … recently Little Dog from Boston Dynamics, demonstrated advanced, automated locomotive skills. Not only maneuvering skills - similar to its predecessor Big Dog - but with added agility and adaptability to various terrains.

What does robotics have to do with BPM?

Business process management is often touted as a management discipline that models “as-is” processes, analyzes them, comes up with improved “to-be” processes - with hopefully improved efficiencies. These efficiencies could correspond to both improvements in the internal processes (Lean) - through reducing waste and improving speed - as well as the overall perceived consistency and quality of processes (Six Sigma). Continuous improvement methodologies and initiatives are valuable. However, BPM’s greatest value proposition is execution. Now, through BPM suites some tasks will be completely automated and executed through policies (business rules) that drive the processes. BPM also involves human participants. So in addition to automating some of the tasks, through BPM Suites human participants will be assisted, guided, and empowered through decisioning rules in BPM suite solutions - even as they carry out their tasks. Most importantly, the end-to-end business processes are executed by the BPM suite engine that keeps track of all the events throughout the lifecycle of executing processes. The BPM value proposition at its core emanates from the execution of policies and procedures (processes).

A business is a collection of policies and procedures, Where are these policies and procedures?

• Regulation Policy and Procedure - Typically these are the “bylaws” for internal, regulatory, production and customer facing policies and procedures. Whether they are automated or not, it does not matter, they need to be followed.

• Decision policy and procedures by experts - These are the decisioning rules that are in “people’s heads.” Every organization has knowledge workers that know how things get, or should be, done

• Ossified policies and procedures - This category of policies and procedures are “hidden” or embedded in legacy code or ossified in ERP systems. There is little or no visibility of these policies and procedures. Interestingly, another source of this type of policies and procedures is data. One of the biggest challenges is the visibility, transparency, and agility of the processes ossified in ERP systems.

• Modeled policies and procedures - This category type is often used to capture “as is” and “to be” process maps. There could be, and typically are, other modeling elements. Sometimes enterprise architecture or business process analysis tools are used to capture these models. The problem is that models sometimes become an end in themselves: with voluminous modeling artifacts or documents and little or no demonstrable improvements.

• Execution of policies and procedures - Execution is the biggest value proposition for BPM. BPMS technology is essential for process improvement. Execution facilitates the governance of improvement as well as work optimization for your BPM initiatives. Yes, there will always be manual, undocumented, or “modeled” policies and procedures. But the greatest value of BPM emanates from executing the modeled policies and procedures, through a BPM suite.

Why execution? Here are some key advantages of process execution:

• Process Improvement, governance, and/or compliance - Modeling is useful. However, often process improvement initiatives end up with voluminous documentation, with little or no value. The chief objective of improvement is not voluminous documentation or artifacts of models. It’s about getting results. To achieve concrete results, the proposed process improvement needs to be executed through a BPMS. So, with the process execution platforms (i.e. the BPMS), what gets modeled is what gets executed - thus you benefit from immediate process improvement and quick time-to-value. The BPMS business platform that immediately provides executable solutions with all the assets (process flows, business rules, information, service integration, UI, etc.) - is essential for agility with tangible results.

• Continuous business process activity monitoring and improvement - What gets measured gets done. Since the processes are automated, the BPMS can keep track of all the activities and events from the execution of the processes. With robust BPM platforms, you can establish metrics throughout the entire lifecycle of a BPM project (design-time to run-time). These quantitative metrics can be tightly linked to key performance indicators to proactively drive continuous improvement. With BPM execution, this process event-driven monitoring is “free” - the measures are there and the overall solution can proactively keep the processes in control.

• Assist, Guide, Coach and Optimize your operators - Similar to robots assisting humans, either in labor or combat, the automated procedures, policies, and decisions in the context of automated processes assist the human operators in carrying out their day to day tasks optimally.

• Build corporate assets and apply the best asset contextually - Some of the “assets” in BPM include the process flows, the decision rules, the service levels, the event correlation rules, the expressions, the constraints and also the information model, the User Interface and service integration with incumbent applications or legacy systems. With BPMS execution, you have the opportunity to leverage a dynamic multi-dimensional repository of these assets, so that during the automated execution of processes the most relevant asset is applied, depending upon the context: what product or solution is being executed, at what time, where, when, by whom, for whom, etc.

These are few of the advantages of process execution. The analogy to robotics is compelling. BPMS solutions are agile. New policies and procedures could easily be introduced to execute for specific contexts. The BPM solution empowers the human participants - those who execute tasks in the context of process applications. Most importantly, business performance metrics could be drilled down to detect potential bottlenecks in process applications, operators, or organizations that own the process. Thus, process performance is tied to executing and automated process elements. We have called this real-time Lean Six Sigma: where processes are kept in control and continuous improvements are achieved while executing the processes in real time (vs. after the fact, as in traditional LSS).

Finally, similar to execution in robotics, process applications could also learn, adapt and optimize. Thus process behavioral patterns and optimizations could be mined from process, operational, warehouse or census data. The discovered policies and patterns could then be operationalized in the context of automated processes. We will discuss predictive and adaptive BPM in a subsequent blog posting.

So what does robotics have to do with BPM? Well, as you can see just about everything. What automation does for robotics, BPM can do for business applications with human participants execution - always agile, responsive, and continuously improving.

About the author

Dr. Setrag Khoshafian is the Vice President of Product Marketing and BPM Technology at Pegasystems Inc. He is our guest blogger on topics related to BPM, BRE/DM, CRM, Case Management, and Risk/Fraud/Compliance through BPM

Posted by Dr. Setrag Khoshafian at 10:54 AM | Permalink | Comments (0) | TrackBacks (0)

The epic of Narasimha Avatar of Lord Vishnu (The Protector) as mentioned in Bhagavata Purana talks about the reason for Him to take an Avatar. It was about a Demon by name Hiranyakashipu, who undergoes many years of Tapas (Penance) to achieve “Invincibility and Immortality”.

After Lord Bramha (The Creator) come to him asks him to make a Wish, Hiranyakashipu mentions that he does not want defeat in any form and death never to meet him neither in day nor at night, neither by animal nor by man, neither indoors not outdoors, neither by a living thing nor by a nonliving thing, neither in sky nor on earth, so on and so forth, which he feels would safeguard him at all the times.

However, Lord Vishnu (The Protector) takes the avatar of Narasimha and kills the demon after finding loop holes in the “Wish” he has asked for. The avatar does the following: a half-man-half-lion (satisfying neither man nor animal), in twilight (neither day nor night), sitting on the threshold of courtyard (neither indoor, not outdoor), on his thighs (neither in sky nor on earth), with sharp finger nails disemboweling him (neither by living nor nonliving thing), there by killing him.

Editor’s note: For brevity’s sake the story is cut short into two paragraphs, however interested readers are suggested to check out various sites providing the detailed epic on Internet.

The above epic showcases the triumph of Good over Evil. But, the reference to this epic in this blog is not about Gods, Demons and their epics, but about something else.

Yes, you guessed it correctly. It is about “Requirement Specification”. A lot of time, when the requirements are not articulated clearly, the result would have a correct solution to a wrong problem.

We are in the business of IT Services, where we adhere to what is called as “Software Development Life Cycle” process for providing IT Solutions to business problems of our customers. In SDLC, we start with our first step to understand the “Requirement” of our client, which then is “Analyzed” to come up with a feasible “Design” of a solution for the “Requirement”. Till this stage, the actual nuts and bolts of the software are not assembled, but the solution is still at drawing board level.

Later, based on the “Design”, the solution is “Built” wherein all the components discussed at the drawing board are assembled to form the IT Solution. ‘Taste of the pudding is in eating it’, so that “Built” solution is then tested to see, if there are any leaks or malfunction or if it is in adherence to the “design”.

Finally, the solution is presented to the customer, who would then “test” the solution to “accept” the solution. Once the solution is “accepted” it is “deployed” into the daily use for the customer.

In the entire life cycle of the software, from the solution “idea” germination to “deployment” into daily use, as the time line moves, the cost of fixing any mismatch between the requirement and the solution grows exponentially. Barry Boehm, in this magnum opus book, “Software Engineering Economics” [ISBN 0076092033097] mentions that ‘the cost of removing a software defect grows exponentially for each downstream phase of the development lifecycle in which it remains undiscovered’.

All along we have been discussing about a popular SLDC model called “Waterfall” model, which is a unidirectional model. Another popular model “Agile” used for software development is an iterative model, where all the stages are met in a short span of time. Here too the risk of “Skewed Requirements” plays the Demosthenes sword. As each of the iteration builds upon the previous iteration, if somewhere in earlier iterations, the requirement is wrongly met, the whole solution that is build and deployed in the final iteration might be different from the expected.

So, how do we come over this problem of omitting a requirement or misunderstanding of a requirement, before things go on to different phases of SDLC?

A quick answer would be - by following good requirement gathering practices, better listening skills (if provided with a workshop), better reading comprehensions (if provided with documents), like good data eliciting techniques (if on a consulting mode) or prototyping models (to showcase our understanding) etc.

There is always a risk of human error in the above mentioned techniques. We at Infosys too understood the limitation and identified a technique to overcome this limitation. Setlabs our research and development unit has come up with a tool called InFlux, which can help the development team for gathering requirements in a way that nothing is either misunderstood or missed out altogether.

In an ESB implementation engagement for one of our Energy Utilities client in USA, InFlux was used to gather the requirements and a solution was provided. Later, for another subsidiary company of the same customer, the requirements were gathered again using InFlux, the tool showed that near to 60% of the requirements are similar to the earlier requirements, suggesting the team to “reuse” most of the already built solution. The customer made a saving of 50% on the development cost.

For more information about InFlux, please visit link

Posted by Anil Prasad Kurnool at 12:03 PM | Permalink | Comments (9) | TrackBacks (0)

Most of the time we end up over engineer application integration without giving the right focus on the context of the application within the business. As a result we end up implementing integration patterns which does not suit the business context as we continue to focus on technical context.

To me Service Oriented Integration, Event Driven Integration, Process Integration and Information Integration are mere technical approach, which as an architect needs to understand these approaches and apply based on Business scenario.

Based on my experience what I realized, is that all these approaches are successful in specific business context and are not fit all approach. For example

• Service Oriented Integration approach is typically successful in business use cases which are related to servicing of end customer for example Multi Channel Integration or supporting eCommerce
• Whereas Event driven integration approach are applicable to business use case where upto date information are required for decision making and subsequent processing for example determining stock level and ordering replinishment
• Whereas Information Integration approach is typically successful in business use case requires synchronization of information in back end systems for back end processing like employee information synchronization, product synchronization etc..
• Whereas Process Integration are applicable for business scenario where process automation is required for improve operational efficiency and improving organizational responsiveness like New Product Introduction in FMCG, Manufacturing, Telcom or New Account Opening in Banking etc..

In general a typical end to end scenario would require combination of these approaches however based on the end to end business requirement there will be one primary approach.

I believe that all these approaches are significant to all industry segment but distribution of its applicability varies from industry to industry and within a single industry it varies based on the business value chain

Posted by Manas Kumar Sarkar at 10:05 AM | Permalink | Comments (2) | TrackBacks (0)