BPM-EAI

Cloud computing today has become the buzz word in the IT industry and being seen as the big thing to address IT's ROI pain. However being involved with Integration, SOA and BPM for years I am constantly trying to see the value of Cloud in Integration or SOA or BPM space for the customers who already have invested heavily on a stack integration, SOA and BPM platform or on different individual platform to address all these areas.

The answer seems to be very simple; virtualize the hardware and implement the platform and you achieve a private cloud for Integration platform.

However when I analyzed some of the client situation, I realized that introducing virtualization of hardware platform would really mean introducting another element to be managed by the Integration team without realizing the benefit of cloud.

So I was back to the drawing board and thought let's look at the problem statements (Here I have assumed that organization is delivering integration through a centralized team and the data centre management is not outsourced). 

• Case 1 - For a business initiative developing new services and Interfaces
• Request to Integration team which says - Need 3 environment with X, Y & Z specification. X (X stands for Development Environment) is needed for t1 days, Y (Y stands for System Integration Test environment) is required for t2 days and Z (Z stands for performance test environment) for t3 days. No other work should happen on the Z environment as we would be doing performance benchmarking for the entire solution
• Case 2 - For a business initiative developing new services and Interfaces and re-using existing ones -
• Request to Integration team which says - Need 3 environment with X, Y & Z specification.
• X is needed for t1 days with A, B & C service / interfaces which are connecting to I1, I2 & I3 instances of their corresponding application
• Y is required for t2 days with A, B & C service / interfaces which are connecting to I2, I1 & I1 instances of their corresponding application
• Z for t3 days days with A, B & C service / interfaces which are connecting to I3, I3 & I2 instances of their corresponding application. In addition no other work should happen on the Z environment as we would be doing performance benchmarking for the entire solution
• Case 3 - For the same business initiatiative as mentione in Case 2, there is a new application being developed which takes data from an existing interface. The application team raises 
• Request to Integration team which says - Need 1 environment with X specification
• X is needed for t1 days with A service / interfaces which are connecting to I4 of the corresponding application

Entire environment provisioning and management would become more complicated when two big initiatives are delivered at the same time or when BPMS is also delivered as part of Integration Platform

One way of looking at this is to provision multiple envionment  to different business initiatives and let them manage the entire environment. However the moment we take such a decision the entire ROI for integration gets impacted.

And this is where we see delivering Integration Platform as private cloud maximize the ROI. So before we dive into how part of the solution let us analyze the "why" or the motivation part of cloud adoption

• Minimize environment management overhead
• How do we lay down my messaging platform, so that minimum instances needs to be managed simultaneously?
• Ensure basic integration platform QoS is delivered to all business initiative
• How do we ensure that the Integration Platform we are delivering to different projects confirms to the enterprise standards?
• Ensure automated deployment of services with minimal intervention by Integration team
• How do we ensure that the service / Interfaces deployed on the provisioned platform confirms to the requirement of the business initiatives
• Optimum utilization of hardware infrastructure 
• How we ensure that hardware infrastructure is utilized optimally
• Pay as you use 
• And lastly how do we ensure chargeback to the business initiative

This is what a private cloud for Integration Platform needs to address. This is what I have in all for today, in the next post I will discuss about the "how" part....

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

For the last one year I had been having interesting discussion around BPM with multiple customers in different industry vertical. And when I analyze these discussions one problem statement was strikingly similar across different verticals, which can be summarized as
  

"If you consider the end to end business process as seen by the business process owner, 60-70% of the process is currently encapsulated in ERP or certain be-spoke applications which are performing well, so how can I continue to utilize these investments and also adopt Business Process Management".

While analyzing this statement few areas came up for further discussion, which made everybody think about the end to end process implementation. Today if we take any end to end business process and system view we would see the implementation as shown in the diagram below

 

Resulting in  

• No end to end process view exists systematically which could provide business process owner a consolidated view of his/her process as he/she sees
  
• Business process owner continues to get a segmented view of the process being implemented in different set of applications including ERP and been managed by different department resulting in
  
• No formal KPI ownership - With departmental view of the process, there are no formal ownership of end to end process KPI
  
• No holistic view for Process improvement - Process improvement initiatives are driven from a departmental view perspective and does not take into account the end to end process
  

And this where Business State Machine from BPMS offering comes handy and can address a lot of Business Process Owner concerns highlighted above. In this blog I am not going into details of Business State machine definition but to put it in simple language it is managing the process through well established States / Stages of Business Process which is important to business process owner.
So how do we apply Business State Machine to solve the problem? There is no single way to address the problem; however I have been using the following guidelines to drive the solutions for our customer 

• Working with the Business team and application group to identify key stages or states of the business process and utilize Business State machine to model the end to end process with these Key States / Stages
  
• Work with the Business team to
  
• First identify overall process performance KPI and KPI at various process states / stages
  
• Second identify overall business value KPI and KPI at various process states / stages
  
• Subsequently identify the source for Business States from underlying application which would be interfaced with the Business State machine to ensure management of overall Business process in terms of states / stages
  
• Understand the latency requirement from Business State perspective and identify a event based architecture to address the requirement
  

The value demonstrated by approaching BPM adoption using Business State Machine has been very promising and some of the areas other than end to end process visibility where our customer derived benefit were

• Increased Process Operational efficiency - Business State Machine coupled with KPI monitoring (Both process and business value) would enable business process owner to take an informed decision for marshalling its resources to manage the process better
  
• Support Process Improvement Initiative - This is one of the biggest benefit an organization can derive from BPM implementation. The decision to automate certain lag of the process would be driven and supported by a value driven approach
  
• Metrics driven management of business process performance - Any ERP or IT improvement initiative can be measures continuously to ensure the value realization
  

Although we see applicability of Business State Machine to any type of process, however we have seen more value realization for processes which are iterative in nature. Also one should be careful on approaching such solution as over engineering of the technical solution could lead to premature end of such initiative

Posted by Manas Kumar Sarkar at 03:55 PM | Permalink | Comments (0) | TrackBacks (0)

Lately I have had multiple conversations and discussions on the topic of product selection. In such conversations,  again and again I have seen the emphasis on why a product should be used for a given intent because that is what the product vendors have built the product for. Interestingly in one such conversation that I recall, the chief architect wanted to use a product that was meant for complex event processing to actually implement a process management capability. At the same time, there are products actually that do the process flow management that could be used. However, given the requirement of the software capability, both the products can do what is needed to be done. So now question is, in such situation, how appropriate or inappropriate is to use a software (if that meets your requirements) that is not intended to do what you want it to do from product vendor’s perspective.

Straight forward answer just could have been “Don’t misuse the product capability, stick to what the products are designed for”….but is it really that way? How do we approach this situation and make a decision that is not going to lend itself to disaster? That’s when the “repurposing” ideas started taking shape in my mind. In simple terms, repurposing is defining new purpose/usage of the object. In our case, we are talking about inventing/discovering new ‘utility’ of the software. Now, such new utility becomes innovation or misuse will possibly depend on number of factors that we will shortly come to.

Talking about repurposing, history has it that countless number of technology inventions that were originally designed for different purpose and then subsequently they were successfully adopted for a totally different purpose. This is a interesting topic, let me talk about a few of such inventions.

Microwave – apparently the original devices was meant to produce radio signals for radar usage. However it was discovered that such microwaves have capacity to heat certain types of material and thus it was repurposed to bring something that is so common in our life: the microwave oven.

Washing machine - This is the most interesting of all. I discovered it few years ago that a particular business community has adopted washing machines (after little customization) to produce a particular health drink using the sturring capabilities of the machine. Same machine is also adopted to separate out the butter from the cream of milk. Did you ever imagine that?

SMS text messages – these were designed to notify the users of mobile as test from network operators. However, given the simplicity and usefulness of the capability, they were launched as features for mobile services and now they are also being repurposed to operate certain electrical appliances/machinery using the sms capabilities. Amazing!

In the area of information technology itself we have so many variety of examples. Emails being used as draft documentation tools, Microsoft XLS being used as interactive application development tool, iPOD/MP3 players being used as storage disk, computer games (customized of course) are being used to train the business users. And the latest, as I write, tremendous repurposing effort is going on for the social network technologies to be deployed for alternative collaboration capabilities for the businesses.

That was fun side. Let me now take two key example from recent technology areas – BPM and CEP.

From my own experience, there are so many cases I have seen across fortune 2000 global companies where they have actually used the BPM software as a tool to develop applications. Now a purist will take offense (rightfully as one should) on this approach arguing the architectural contamination that such approach brings. And I too will agree on that if the organization actually uses BPM software tool for application development while thinking that they are doing BPM. But it doesn’t end here. I know organizations who have ‘deliberately’, in control of all their sense, to some extent I would say smartly decided to use the BPM tool as the application development platform. Why not? They figured out that BPM software with what it costs, there is far more utility in it to develop custom applications (with of course BPM embedded in that solution) than just using it to create process wireframes. In some of such cases, it took much lesser time for them to develop the apps, was easy to integrate with rest of the ecosystem and  has required much lesser technology knowledge (well, it does depend on the product though). So from ROI perspective, such organizations believed that with the sunk cost of licenses (which is significant cost actually), they are able to derive much better value from the product. I think in my mind such approach has a merit if carefully and strategically driven. Another reason also why I’m in favor of such repurposing is that many times product vendors build the product with very narrow purpose to gain the niche market space and mindshare while software actually has capability to do lot more. So it is more of a business marketing from product vendors than the real product fitment issue.

Let me come to next technology product – Complex Event Processing or CEP. There are many products in the market that allows us to model the event, correlate the events, model the event policies etc. Now there is a newly emerging paradigm of ‘management of unstructured and adhoc processes’. These are the processes that are not well-defined and categorically structured, rather, they are dynamic and get defined based on patterns of the events. Sounds similar to CEP? It does a lot in my mind and hence, CEP products are now being experimented to be repurposed as BPM tools to manage the unstructured/adhoc processes given that current BPM suites don’t offer such capabilities largely.

Now coming to important question. What decides if the repurposing is really an innovation or rather a dangerous misuse. In my view 4 key factors that iinfluence this decision will be:

• Interoperability and compatibility of the product (with rest of the eco-system) in the changed environment (due to repurposing) - if the repurposed capability doesn't really fit into the overall eco-system, it doesn't really make the case.
• Future roadmap of the product (sustainability of the utility of the repurposed software based on the changes being made in the product) - it ensures that repurposing is not a short sighted decision that create a disaster in making for future. To large extent its not entirely predicable or reliable since its difficult to figure out the future moves of the product companies. But the its a risk and hence best judgement should be used considering the expected shelf-life of the solution and trends/anticipated changes of the market.
• Cost effectiveness of the product with the repurposed scenario - quite obvious unless someone has to do it for the sake of other milages (read as policitical etc.)
• Unintended consequences of the repurposing - this is interesting. While we could have unintended use of the software but at the same time it calls for due diligence of any unintended consequence that the repurposing could lead to. Such unintended consequence could be TCO impacts in long run, legal consequences of software usage from angle of licensing etc etc.

So that’s my 2.5 cents (0.5 cents for the fun examples) for the product selection. I think we need to experiment little more with the portfolio of software capabilities we have in the market and I’m sure we would be able to create innovative repurpose cases to bring new values from the IT investments.

Posted by Rakesh Mishra at 07:14 AM | Permalink | Comments (0) | TrackBacks (0)

In last couple of weeks, I have been reading about virtualization and externalization view-points. While churning the ideas around it in my head, I’m also trying to clearly distinguish between externalization and virtualization. While some principles across these two could be same, I see them as two different design strategies, applicable with different strengths and needs. This blog I’m dedicating to my views on externalization design strategy that I believe represent the ‘deployment’ view of the SOA paradigm in some way.

What’s the meaning of ‘externalization’? In the context of software design, we take externalization as the strategic (I used this word intentionally to stress upon the fact that it has long term strategic benefits) separation of certain overarching capabilities (that otherwise are inherently embedded inside the software all over the place) from the rest of the capabilities. In simple terms, the way I view externalization it is very similar to MVC (model view control) principle: It separates the ‘global control’ aspect from the ‘local execution’. This way, I have flexibility to:

• One) focus upon the end-to-end view of the design without infecting that with low level details/concerns of local execution capabilities
• Two) provide the freedom to plug in adequate local execution capabilities (and change it as we want) without breaking the global configuration

Let us come down to specific to make more sense of what I said. There are 4 critical architectural capabilities as greatly being discussed across the globe today which are fantastic realization of the design externalization strategy. Here are those fantastic four with the illustration of the two benefits that I described above:

1. BPM Layer - Transaction flow externalization: BPM in its purest form externalizes the business transaction flow or the business process flow. What it means that we can construct the global wireframe of the business process with end-to-end view and then decide at which point of that flow which kind of business transaction capabilities need to be plugged in. At those point, appropriate invocation of transactions/application services will be done. With this kind of approach, we can instrument and administer the overall IT solution capability at two level. First level at the global flow level where it allows us to reorganize, enrich and mold the overall flow according to end-to-end view-point. Second level, it allows us to replace a given transaction services/capability (at a given point in the flow) with another one without disrupting/breaking the overall flow including replacement of legacy applications with new generation applications.
   
2. BRM layer - Business/transaction rules externalization: BRM layer allows us to extract all the rules that are implemented the process logic and make them independently executable policies. This way, a transaction logic or a BPM layer flow becomes the overall wire-frame in which rules can be executed. By externalization, rules become independent and individually available objects (local execution) that can be plugged in the global wire frame of the application (transaction delivery) or BPM (overall process delivery).
   
3. MDM layer - Master Data exchange/management flow externalization: This is important one here. MDM as a design strategy allows externalization of the process/flow for the data events. Through MDM, we can separate out the individual data transactions across multiple data masters from the overall control/flow in which these events are plugged into. So it could be same update customer master data event that could be plugged into multiple data flows arising from variety of business processes. Having said, that, based on my experience, I found that many organizations tend to complicate the MDM layer by intruding the MDM capabilities/software scope into BPM space. If MDM layer is over-engineered to start designing the business process capabilities also, it will lose its strength and actually make the architecture highly fragile and complicated. So MDM needs to be carefully integrated with the BPM such as business process flows are managed by BPM and then at appropriate nodes, MDM services are plugged in to execute data events necessary to keep the data masters clean and consistent.
   
4. ESB layer - Event/message flow externalization: ESB or the erstwhile middleware capability is externalization layer for managing the execution of event and services messages. ESB separate out the overall flow and orchestration of these messages from the execution of individual messages/events. This again is integrated as a capability with both BPM and MDM layers to provide them event management, service management and message management capabilities. From BPM layer, at some node when local transaction execution capability has to be invoked, it is orchestrated by the ESB event/messaging wire-frame that knows precisely which all touch points to be connected in order to get the transaction nodes executed within BPM flow.

Diagram below gives pictorial understanding of how these different externalized layers interact with each other.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

I  do realize that possibilities with such view-point is diverse and hence it will be interesting to hear from others on this.

Posted by Rakesh Mishra at 10:55 AM | Permalink | Comments (2) | TrackBacks (0)

After my recent blog "The telecom ecosystem is changing....Can BPM help?", I have been pondering over the 'What' and 'How' of my next blog (which is this very blog you are reading). Today, there are many events (change factors) taking place in the telecom industry. I believe, it is prudent to have a basic understanding of all the events, to appreciate the 'new' telecom industry and role of BPM-EAI products.

I now know what I would write in this blog and the ones to come. Consider this as the first part (in a series of blogs) that I would write to unravel the Telecom industry - covering basic Industry understanding, latest technological trends, challenges, and how does BPM-EAI  fit in. I am tempted to start with technology trends and BPM-EAI, but I would start from the basics….building up with each blog. So let us start….

Telecommunication services:-
Telecommunications has come a long way from the days when a Telecom operator was a firm providing pure phone services. Chances are that today,  the same operator would be bundling a plethora of services that are not limited to phone services. Sometimes, I ask my self 'What sectors (read business verticals) would Telecommunications cover?". I believe, telecommunications would encompass firms providing the following services:-
- Broadband and Wireless Internet (Internet Service Providers)
- Phone services (Wireless and Wire line)
- Television (Media and Entertainment)
- Value added services (on-demand services, mobile banking, etc.)

Why do I say so ? Today, I can buy a bundle of services from a single operator. E.g. BSNL (Indian Telecom PSU) today can give me a broadband service, IPTV and a landline (PSTN) or mobile (Wireless- cellular) connection. Or Airtel (Private Telecom Player) can give me the same services along with satellite TV ! What you are witnessing here is 'convergence' of services and technologies.

Technology landscape:-
Most operators maintain multiple networks for different services. These networks are managed by multiple IT systems. Broadly speaking, the IT Systems in place manage everything - Networks, Customers, Suppliers, product lifecycle , and other support functions. And believe me, this is a very complicated system. You can have a look at the Applications map at the tmforum Application Framework website.

These multiple networks have created complex management problems, and maintenance issues. Multiple IT systems have created data islands that make it difficult to get a 360 degree view.

To summarize  - 'Telecom operators today create and manage multiple networks to provide multiple services (covering voice, data, & video). Multiple IT systems are used to manage the overall functioning of an operator'.

This would be all for now.....

Posted by Komal Sethi at 09:00 AM | Permalink | Comments (0) | TrackBacks (0)

“Lead-time to Deliver Business Value” – that’s the value perspective I will discuss in this bloglet (didn’t your hear about “bloglets” lately? That’s what a blog in a progressive series of blogchain on a topic). This value statement has two segment. First is about the delivery of business value and second is the lead time. Business value in the context of this discussion can be any specific business results that is generated by sequence of business activities. So in B2B context, let us say that it is a buyer-seller network where organization is buying certain material/components from a third party seller using B2B platform. In such case, business value that organization will be concerned about (for the supplier business value chain where lead time matters) can be:

• Speed and ease with which suppliers can be on-boarded on the B2B so that lead time to start the electronic business dealing with the supplier can be started as soon as contract has been signed between the parties. Any delay happening there is loss of business to both the parties.
• Cycle time to fulfill a valid order right from the order generation within the organization boundary, posting of the order to supplier and provisioning and fulfillment of the order by the supplier and finally closure of the order in the system. More the cycle time, lesser the agility with which organizations can cope up with the dynamic/unpredictable demand.
• Speed and flexibility with which organizations can change and optimize their B2B processes based on the capabilities of the business partner network could determine to great extent how fast they can innovate new business results using the existing resources/constraints. In this case, lead time to evolve the business processes in B2B network (that removes inefficiencies, ineffectiveness and other bottlenecks) defines how costly the changes will be and how soon organization could start getting benefits of the process improvements/innovation.

So if we look at the end-to-end supply chain that is being served by the B2B infrastructure, organizations should be able to monitor how fast (or slow) values are being created at every node of the business exchange. With that, they should be able to identify strategies to reduce the lead time and improve the speed and agility with which values can be created.

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