Guest
Welcome login


TIBCOmmunity > Products > BPM
Home Members Communities
Conversations (824) Resources (17) Blogs (2) Set as default tab

BPM

Statistics: Blogs: 1 Blog Posts: 2
Items per page Filter:
0

In simple terms, Business Process Management is the capacity to completely manage the end to end lifecycle of the business process. The intent of BPM is to identify core business processes in an organization, automate them with efficient integration to the underlying systems and people and then maximize the process for efficiency. When the most important business processes in an organization are executing at peak capacity, the organization is bound to succeed. BPM has the power to spell the difference between success and doom for an organization.

 

This popular diagram below efficiently summarizes what components exist in end to end BPM:

 

bpm_e2e.JPG

 

It’s worthwhile considering the user persona while looking at each of the blocks in this diagram, just to understand the user needs when you consider a BPM offering.

 

Modeling and Simulation (includes Rules Design),

Persona: Business Analyst (TIBCO Business Studio):

Previous to BPM, a business process could very well lie as an undocumented artifact in minds of a few experts within the organization. It may trickle down through power point presentations, spreadsheets and word documents. However, the need to manage this business process results in a need to extract the process from all these resources and model it visually and document it in a single location.

 

The user who designs the business process is typically a business analyst – a persona who doesn’t want to get bogged down by technical details and just wants to model the process at a very high level. The user probably wants to simulate the process as well to identify bottlenecks and figure resource allocation before execution. Rules need to be designed as well in addition to the process and it is imperative that the set up be such that the rules are decoupled from the business process, as the two need to change independent of each other.

 

There are other requirements such as reporting for easy back and forth between the business user and the rest of the players, revision control as the process. Also the capacity to import business processes from third party modeling environments. Lastly, this business process needs to be handed off easily to a process developer for implementation with ease and no loss of information during the transfer.

 

Implementation

Persona: Process Developer (TIBCO Business Studio):

The Process Developer wants to pick up the business process designed in consortium with the business user and implement details. A process developer is a technical person who wants to get the business process ready for execution. For example, he may want to hook up a service step to a webservice call out or to a database, build out forms for user interaction steps, etc. A good point to note is the importance of decoupling the SOA layer from the BPM layer at this point so the two can change independent of each other.

 

Execution

Persona: Op/Admin (TIBCO iProcess Engine):

Once the process is ready for execution, the op/admin takes over in terms of ongoing operational management of the process. Levels of scale in terms of number of users being logged on simultaneously, number of transactions, capacity to set up the engine for high availability, scalability are all typical requirements for consideration. Other important considerations include the capacity to get visibility at the system process level to get an idea of health of the execution, capacity to pause and resume, upgrade the business process to newer version numbers without interrupting execution. Lastly, the ease with which you can design–implement–test, as you’ll need to execute that implementation lifecycle many times every time before you go into production.

 

Business Activity Monitoring

Persona: Business Manager (TIBCO iProcess Insight):

The Business Manager is the person who is accountable for the business process. He needs to get his hands on metrics that prove to him how his process is performing on a day to day basis and helps him identify the bottlenecks in the process. Ease and accuracy of reporting, report design and customization, drill down capability to various resources in the process are all critical requirements for this stage.

 

Optimization

Persona: Business Analyst (TIBCO iProcess Analytics):

One of the primary purposes of BPM is the need to improve the efficiency of the business process by identifying bottlenecks. For this purpose, the business analyst needs to be able to observe long term trends and drill down into various aspects of the business process to identify bottlenecks. In addition, the suite needs to have the capacity to “round trip” or feed back information from the trend analysis back into the process model for redesign to maximize for efficiency.

 

This white paper leads you into a more in-depth discussion on the various aspects of BPM: Guide through the BPM Maze

0 Comments 0 References Permalink
8

I was covering the BPM space for a while before I moved on to manage the SOA stack here at TIBCO. The repeat question I get asked from both sides of the fence is: what is the difference between BPM and SOA? It’s an interesting question with a myriad responses and I choose to start my series of blog posts here on this community, on BPM, on this particular topic.

 

BPM and SOA are two sides of the same coin, as one of my colleagues pointed out to me, in my early days at TIBCO. Another more concrete response – if 80% of your process is people centric and 20% systems centric, you are looking at BPM vs the other way for SOA. I’ve heard this one too – it’s all about the user, a more business centric user trying to define a process at the business layer needs BPM vs a technology-deep user defining a process at the systemsy layer, who needs SOA. I like this last one best: BPM is about extracting high level turnkey business processes and managing them as though they were assets in your organization, while SOA is about rewiring the IT plumbing in your infrastructure for efficiency and reuse; You need those business process assets to leverage your IT plumbing and you want your IT plumbing to always align with business process requirements.

 

While all these responses hold truth in them, the more I’ve worked in both spaces and closely followed them, I realize that the lines are blurry which is why people ask this repeat question. And when you think about it, a user wants to talk about finding a solution to the problem he has on hand, rather than be bombarded with three letter acronyms such as BPM and SOA. Vendors such as TIBCO are in a unique position where we have eons of experience in both areas that can leverage across product offerings so we cater to exactly this: provide the solution rather than a piece of technology that should be very carefully mapped to the problem.


Another point that is imperative: for the most successful SOA implementations, BPM and awareness of business processes is critical. Only then can you quantify and measure metrics against the business as well as design for the business, rather than just tweak and churn against technology for efficiency. If you read Paul Brown’s book on: Succeeding with SOA (highly recommend), he touches on this all through, where he talks about realizing business value through architectural design.

 

And the counter, at every point that a business process leverages the underlying infrastructure, a good design will allow it to reach out to an SOA implementation so there is always a loose coupling between BPM and SOA; rather than to hard coded systems interfaces to your business process. This loose coupling between BPM and SOA will allow one layer to change independent of the other. When you re-provision your IT infrastructure, you don't want to bring down your business processes, do you?

 

It’s important for BPM and SOA offerings to work well together – the BPM offering should be able to call out to the SOA services and orchestrations at design time with a few clicks of the mouse and work seamlessly at run time. And an SOA process should be able to call out to BPM centric processes without extensive work or rewiring. The best designs are from experience in both areas. My take, stick to your expertise be it SOA or BPM but learn extensively on the other area and attend conferences in both areas so you know what's happeninig on the other side of the fence before you sit down to design your architecture.

 

The takeaway is that BPM and SOA are interdependent and for good reasons, the best implementations leverage the strengths of both while keeping them decoupled.

 

In my next blog post, let’s look at what end to end business process management is all about before we dive off into the world of process modeling. Business process modeling is my favorite area where I’m hoping to explore with this audience, efficient process design using Business Studio. You can take a quick peak at Business Studio by visiting our developer center: Business Studio Developer Center

8 Comments Permalink
RSS feed of this list
A tag group is nothing more than a named collection of tags. The primary benefit of a tag group is that it groups your content dynamically. A wiki resource or conversation is not created in a tag group, but will be associated with one or more tag groups if it is associated with tags in the tag groups. If a conversation morphs into something entirely different in time, you can change its tags to change the tag groups it can be found in.
Shows all content, regardless of tags, created in this Community