Articles tagged with: soa

BPM and SOA are joined at the hip - 5 tips - next mobile bpm is coming.

on Wednesday, 15 May 2013. Posted in Blog, BPM

BPM and SOA are joined at the hip - 5 tips - next mobile bpm is coming.

 

Over time, business process logic became embedded in these custom applications, often undocumented code and proprietary data structures that were expensive to change, the business answer was to duplicate business functionality, which of course increased the difficulty and expense of changing code. That resulted in higher IT costs and growing IT backlogs.

In my view most companies are starting the adoption of a data/process governance model across the enterprise and have understood the important link between BPM and SOA.

 


BPM is a management discipline that documents business processes so that they may be consistently executed, by measuring, monitoring and controlling process performance this includes key inputs and outputs of process.

BPM is a way of building operational solutions. SOA is a thought model that helps decompose complex problems into well-defined and reusable components. BPM ends with a statement of the desired level of automationand SOA begins with the set of services that are available to support the desired automation.

 

Tip 1 – Provide your business analysts /architects with BPMN 2.0 and BPEL modeling for your enterprise projects

Tip 2 – Embrace your company methodology don’t drop it because of BPM or SOA modify the governance process and add the new deliverables into your existing company methodology.

Tip 3 – BPM and SOA follow what you design is what you execute” (WYDIWYE) model. This model eliminates synchronization problems between design and run time, traditionally when the analyst created his business requirements document and the Developer developed the RICE(Report, Interface, Conversion Extension) Communication/interpretation issues occured. With BPMN Technical and Business Analysts are using the same tools.

Tip 4 - Connect your Business Analyst to BPM to create a realistic road map for process transformation. Anytime I'm in a room filled with enterprise architects and business process professionals, there's often a healthy debate back and forth about who drives transformation across the enterprise. The truth of the matter is that architects are usually the ones tasked with designing and delivering business transformation. And architects are often found in both EA and Business teams.  If your Business Process initiative doesn't have an architect, make it a top priority to bone up on architecture in and look to add architecture skills to your process transformation activities.

Tip 5Here are guidelines for which business problems are best suited for SOA adoption

 

Business Characteristics Unlikely SOA Case Likely SOA Case
Process Rate Change

Low

High

Shared Services

No

Yes

Business Transactional Model

Transactional

Procedural

Organizational Scope

Vertical

Horizontal

Runtime Dynamics

Static

Dynamic

Business Data

Centralized

Distributed

 

 

 

 

 

 

 

 

BPM next focus should go towards mobile.
But looking a few years ahead, there is a one technology that I believe will have an impact on the way BPM systems are built: Speech Recognition.

 

The business case is quite simple:
Most of the BPM solutions use forms.
Once forms were filled by pencil and paper, then came the electronic forms, then keyboards to fill in the forms, and now “Mobile” enables you to “tap” information into the forms.

Your thoughts what do you think... 

 

Below are some previous blogs on the topic of SOA and BPM:

Use BPM and SOA to drive out cost

http://appsconsultant.com/index.php?option=com_content&task=view&id=170&Itemid=9

Business Process Execution Language

http://appsconsultant.com/index.php?option=com_content&task=view&id=44&Itemid=9

 

SOA Architecture Strategy

http://appsconsultant.com/index.php?option=com_content&task=view&id=118&Itemid=9

 

Service Oriented Architecture (SOA)

http://appsconsultant.com/index.php?option=com_content&task=view&id=53&Itemid=9

   

 

 

 

Lessons Learned the hard way from a failed project – Do we learn from our mistakes

on Friday, 19 April 2013. Posted in SOA

 

People learn best from failure. It drives lessons home like nothing else. Here is an email from a reader:

From: *********** [mailto:***********]
Sent: April 16, 2013 6:33 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Building a Centralized Architecture

 

Dear Alex,

Pursuant to our telephone conversation today, I did some internal research and we are mostly an Oracle ERP,EPM, (back office applications) with Microsoft and Linux OS, and SalesForce as our CRM. Our companies strategy changed to a more centralized vision, mostly because some big IT projects being executed by us the business went really bad.

The following products ***** finance, procurement, hrms functionalities were not functioning for days.*********

Top management reacted and shutdown these initiatives.The cost was many millions but an excellent lesson learned, for all of us.

Top 4 points: 1- We hired the wrong consultants friendships with management existed that flawed results 2- Groupthink no one dared to challenge status quo, all of us did not foster diverse thinking 3- Project management provided too much of a rosy picture on status reports. 4- Fingerpointing existed and we lacked project members having the walk the talk attitude.

We had to rollback to our previous systems, and then the project was stopped.

My question, we are looking to purchase an architecture methodology mostly to help the organizations grow from our slip-ups we are starting with our SOA approach, governance and SOA operations.

We are looking at Zachman, Gartners, Oracle or TOGAF. Can you provide us your viewpoint on which methodology would you use knowing abit our environment and company.

Regards,

*********************************

*********************************

***Received approval to share this article from the reader.

 

 The lessons learned for all of us, in my view are as follows:

 1-      Sometimes you think you are so good and so far ahead of the curve that you fall right off the edge

2-      When a project is obviously doomed to failure, get out sooner rather than later.

3-      A square peg in a round hole won't fit any better as time goes on. Problems that go unaddressed will only get worse, not better, over time.

 

Here is my top 10 advice in an enterprise project environments with high stakes involved:

  1. Hire to elevate knowledge
  2. Stick to the facts always decide with data
  3. Respect your team and make it fun
  4. Listen, learn and execute
  5. Try simplicity every time - while it may sound easy, it's the hardest thing to practice and will force you to get creative every time
  6. Avoid buzzwords
  7. Forego your ego
  8. Walk the talk
  9. Enthusiasm is always infectious
  10. Never give up, nothing is impossible

My view on the SOA Architecture Methodology question

Often the most difficult and important task that any corporation must perform is to select and implement an all-encompassing architecture methodology.

My view all 4 architecture methodologies mentioned above (Zachman, TOGAF, Gartner and Oracle) offer a sound basis to build your company architecture methodology. The only tip ‘never take it as is always customize it to your corporations culture’.

In this case the corporation is in 10 countries and has revenues of about 130 million dollars. In my view they should go with Oracle’s Methodology since they’re back office applications are 90% Oracle based and it was given to them for free. By the way the Oracle architecture methodology in my view is inspired by the TOGAF Methodology.

When it comes to OUM (Oracles Unified Method) The SOA core workflow view answers their requirements .The SOA Workflow View is used to help organizations to execute projects within a SOA environment .

Here is an overall diagram: reference OUM Methodology – SOA Core Workflow View

 SOA Core Workflow VIEW - OUM

Overall, my view is that starting an enterprise project is not like everything else. Nothing important is all that easy. Work hard, Learn from mistakes, Be Optimistic, Try again and Face your fears.

As per SOA methodology, reflect on your corporation’s culture and take into consideration the internal decision making process and vision as per vendor neutrality.

Like always share your thoughts and experiences

Copyright 2015 Appsconsultant.com. All rights reserved.