BPM: Agility is a Must

Agile Methodologies are used frequently in modern systems development. Readers of this blog, as well as many people who do not read it, know that the rate of Business changes was accelerated and Information Technology systems should be flexible in order to adapt quickly to the Business changes.

Agile Methodologies focus on high priority requirements. If you would use classic Waterfall methodologies, probably the requirements will change before you complete the Analysis.

According to an old Aberdeen Group's survey, published a decade ago, the time for implementing BPM is more important than the implementation's costs. The results of the Aberdeen Group's survey implies that Agility was required in implementing BPM. Those days, it is required more than it was required ten years ago.

Forrester's analysts Clay Richardson and John R. Rymer wrote in 2013: "The Mantra for BPM has always been "start small, think big, move fast!" However, most teams hit a brick wall when it comes to the "moving fast" of the equation"  (The Forrester WaveTM: BPM Suites Q1 2013).
This citation is actually a call for Agile Methodologies implementation in BPM Projects and Programs.

In the following section I will explain why BPM Agility is required now more than it was required 10 years ago. 

BPM's Evolution
In previous posts I described BPM's evolution until 2012.
In the post titled: BPM Market Growing Rapidly but still Maturing and Changing I discussed the relationships between BPM and Case Management and Software as a Service (SaaS). I also discussed the leading BPMS vendors. 

In the post titled: BPMS Next Generation: IBPMS I discussed a new BPM Use Case, Intelligent Business Operations(IBO) and the immaturity of the BPMS market.

Ten years ago most BPM implementations addressed Automatic or SOA Processes. The Processes were composed of Systems and/or Services executed one after another. Process Flow depended upon conditions. 

The next evolutionary step was Human Processes. 
Human Processes include Automatic sub-processes, however the human steps or human sub-processes are more complex. Addressing them requires more complex development than addressing the Automatic sub-processes.

The development required for addressing the next evolutionary step, Case Management, is a lot more complex and consuming a lot more resources. The next step addresses less structured Human Processes handled by Knowledge workers. The illustration at the beginning of this post depict the structure of a process of that type. 

Intelligent Business Operations(IBO) emerged afterwards. This new Use Case changed vendors position and only three vendors remained in the Leaders part of Gartner Magic Quadrant. Some of the former Leaders such as Software AG acquired smaller vendors of technologies they missed in order to improve their position. 

BPM and SOA alone are not sufficient: Other technologies such as Content Management, Knowledge Management, Complex Event Processing and Business Intelligence supplement them.

BPM for Case Management and IBO could turn into a large development project. Use of Agile Methodologies could help.

The consequences of BPM's Evolution are more Use Cases, higher number of Processes and more complex Processes handled by Human Processes, Intelligent Operation Processes and Case Management. Agility is necessary in order to cope with such complex environment.

Recently I read few articles and Research Notes on BPM trends.
The problem of Moving Target requirements, I mentioned in the context of systems development, was cited in some of the articles, but not in the context of developing systems. It was cited in the context of Processes development.

The next sections will focus on some of the Technological issues complementing Agile BPM Development usage, by shortening BPM development time. 

Low coding or Zero Code Processes
Less code means shorter delivery time. According to Forrester Research's Research Note written by Clay Richardson and John R. Rymer, titled: "New Development Platforms Emerge for Customers Facing Applications" (June, 2014): "Firms often Adopt Fast Delivery Practices with Low-Cost Platforms". 
The need for dynamic processes reflecting rapid changing Business is a must. 

The trend of Low Code Platforms is  especially relevant for Customers Facing Apps.

I recommend reading this excellent Research Note about  a paradigm change in Customer Facing Applications including: the Demand for new App Delivery Thinking, new Culture, Practices and Design approach. 

Unified Development and Execution Environment for all BPM Use Cases
a Unified environment eliminates the need to manage different environments for Automated Processes, Human Processes and Case Management Processes. It also eliminates the need to learn multiple environments, multiple tools and deciding which environment should be used. Unified environment also saves the time and effort of switching environments.

Seem less Integration with completing Technologies
Processes Development requires other technologies completing BPM. More complex Use Cases require more technologies than the simpler Use Cases. The BPM suite should provide easy integration or common operation between tools of those technologies.

If easy integration is not guaranteed, forget Agile Development. You will spend a lot of time and efforts in developing APIs and other integration mechanisms. 

Multi-Channel
a decade ago Multi-Channel  was crucial for successfully implementing CRM (read: The Marriage of Customer-Centric and Multi-Channel).

It was also a good practice to include adequate Multi-Channel Architecture as part of SOA Architecture.

Today Multi-Channel is required for BPM , Case Management and IBO, as well. Human Task performance should be independent of Channel. The implementation should enable usage of any Channel. No coding or minimal coding for addressing multiple Channels and variety of channels is a key for quick Development and rapid Deployment.

The term Multi-Channel denotes something slightly different from the same term ten years ago: It includes Mobile devices and Social Networks Channels.

Vertical Industry Specific Applications and Processes
Russell Keizere, a Senior Director in Pega Systems argues in a presentation: "The Platform should come with pre-built applications for your industry that you can quickly and easily extend and customize" The words quickly and easily were not highlighted by me. They were highlighted by Mr. Keizere. 
The principle of Agile and short time Development is presented again. 

his approach is not a new approach. More than ten years ago I was responsible of BPM Vendor selection in a Telco company. IBM, Tibco and Web Methods presented pre-built Industry specific processes.

The principle is not new but the solutions are more mature than they were ten years ago.

BPM in the Cloud  
Ovum believed on 2012 that Cloud Computing will not be BPM's dominant delivery model.
According to Ovum, BPM implementations invoke Systems and/or Services and the amount of code and data in them is minimal. 

Forrester's survey results on 2012 are different: The title of a the results graph is "Many BPM Programs Either Plan to Use Software as a Service or Already Do So". 
The results:
15% - "Already replaced most/all with SaaS" or "Plan to do so in two years".
33% - "Plan to Complement with some SaaS within two years or "Using some SaaS to complement" 
46% - No plans to use SaaS

The difference between Ovum's opinion and Forrester's survey results is probably because of the amount of code and data in BPM systems is no longer minimal. The more sophisticated Use Cases may require more coding and a lot of data. 

It should be noted that Servers and Software Infrastructure Installation and Customization takes a lot more time and human resources in the Data Center than in SaaS based Public Cloud implementations.

Summary
As BPM matures and addresses more complex Use Cases, usage of Agile Methodologies is a must. The long implementation time is a major barrier. 
I discussed some of the issues and some of the approaches and technologies enabling shorter development time. 
Short delivery time was important in BPM projects ten years ago. It is a must today and probably will not be less important in 2024.   

Will Software AG Survive until 2019? - Revisited

I am not happy to Revisit a Vendor Survival post saying that my prediction that a vendor will not survive was correct (for example, SUN).

If a vendor is not a monopoly, I am not happy to find that the probability that it will survive is lower than it was (Apple, HP etc.).

Even if it is a monopoly in specific markets and not a monopoly in others, I am not happy to find that its Survival probability is lower than it was (Microsoft). 

The reason that I am not happy is that competition is good for my customers: They can buy better products and pay less.

This post is out of the ordinary. The probability that Software AG will Survive is now higher than it was when I wrote the post: Will Software AG Survive until 2019? 
  

Software AG's Business Lines

In my previous Vendors Survival post on Software AG, I analyzed its two major Business Lines:

1. Mainframe DataBase, Development and Integration products

2. BPM and SOA products

I will repeat only the main point:
Software AG's Mainframe Business Line is gradually and slowly declining.

If another vendor will acquire Software AG, it will acquire it because of the BPM and SOA Business Line.  

Positive Indicators
A company could be an Acquisition Target but it also could vanish due to inability to compete.

It looks like Software AG is not a potential failing or vanishing company. 

It is a big, solid and stable company.
The following indicators support my view:

 1. Software AG has more than 5,400 employees in 70 countries that serve 70 percent of the Global 1,000. (The information is updated to the end of 2012). 


2. 1,047.3 million USDs revenues in 2012 


3. Consistent revenues and earnings

4. According to the WikiPedia: "The company is the second largest Software vendor in Germany and the fourth in Europe and among the top 25 globally". 

Transformation is the Name of the Game

In order to Survive and/or grow the company's difficult task is to transform itself from a Mainframe Software Vendor to Multi-Platform BPM and SOA Vendor.

There are two challenges types:  

type 1: The Mainframe Software Business and Business models are unique
The Mainframe software uniqueness is hilighted in the following bullets:

1. A limited number of customers and potential customers

2. The Customers Are Large Enterprises 

Each customer buys for larger sums in comparison to Open Systems customes

3. Higher prices than prices in other software platforms

The minimal Software Products prices are tens of thousands USDs. Usually DBMS's prices, such as Software AG's flagship product ADABAS, are hundred thousands USDs.

4. The Software prices are based on Site Licenses or on Computer models Groups. Larger Mainframes (more CPU MIPS) Groups prices are higher. Usually Capacity grows and new Mainframes with larger Capacity are included in larger Software Groups. The result is higher Software Products prices. 

5. A limited number of competitors. The main competition is IBM with its DB2 database and COBOL and Java programming languages. CA is another important competitor.

6. A very limited number of new potential customers. Migration to Mainframe is unusual. There are few new Mainframe sites.  

type 2: Competition in the BPM and SOA Markets 

In a Press Release Software AG wrote: "Software AG's  strategy has been strongly focused on growth in the Business Process Excellence (BPE) business line since 2012. AS a consequence, the company heavily invested in new products and the expansion of its sales teams." 

The Business Process Management (BPM) market is a lot different. The following bullets highlights the BPM market:

Growing. 

The BPM market is growing rapidly. The annual growth rate of Leaders could be two digits growth rate.  

Immature. 

Read my post: BPMS Next Generation: IBPMS and you will understand. It is a market that from time to time a new Use Case shakes the market. This time it was Intelligent Business Operation (IBO). Software AG was one of the Vendors, which were moved from Gartner Magic Quadrant Leaders Square (BPMS Magic Quadrant) to the Visionary Square in the IBPMS Magic Quadrant. Software AG was not alone: only three Vendors appear in the Leaders Square of IBPMS. Previous Use Cases added and changed vendors position, were Case Management and Human Processes.    

Crowded.

In 2013, Forrester Research identified 52 different vendors competing in the BPM broader market (The Forrester Wave: BPM Suites , Q1 2013). Compare 52 to 2 (The significant competitors in the Mainframe DBMS market).

Acquisitions. 

No wonder that Large Vendors acquire smaller vendors in a crowded market. BPM is not an exception. For example, IBM acquired Lombardi and FileNet. Software AG acquired WebMethods and IDS Scheer and Aurea Software acquired Progress Savvion. 

Competition. 

The competitors include Mega Vendors (IBM, Oracle), Pure BPM companies (Appian, PegaSystems) and Integration Vendors (Tibco, Vitria). I named only few strong competitors. Each of them has its Advantages (as well as Considerations) over other competitors, including Software AG.  

Evaluating Software AG's Transformation
As stated in the title of the previous paragraph: "Transformation is the Name of the Game". In the following sections I would try to evaluate Software AG's Transformation efforts.

Business Lines Contributions to Revenues
Software AG's revenues for 2012 were 1,047 Million USDs. The three major Business Lines contributions were:

Business Process Excellence 547 Million (52%)

Enterprise Transactions 375.2 Million (36%)

IDS Scheer Consulting 125.1 Million (12%)

The raw data was retrieved from Software AG's Annual Report 2012.  I calculated the percentages.

Roughly, Business Process Excellence is BPM including  SOA. 

Roughly, Enterprise Transactions is Mainframe and Database, Development and Integration.
The ADABAS D and Natural business on other platforms is not significant.  

Roughly, IDS Scheer Consulting is Business Process Analysis (BPA). BPA is a part of the BPM Life Cycle, so IDS Scheer Consulting is included in the BPM and SOA Business.

Conclusion: in 2012, BPM and SOA Business Lines revenues are more than 60% of Software AG's revenues. Mainframe revenues are more than 30%. 


The Bottom Line: Software AG transformation from Mainframe Software company to BPM and SOA company was successful. It still has significant but gradually and slowly declining revenues from its Mainframe Business Line.

Acquisitions
Acquisitions are complex you have to chose a suitable Acquisition Target and you have to execute the complex merging process. The complexity includes  Organizational issues, Organizational Culture differences and Technological issues.

The wrong acquisition of Compaq by HP, many years ago, still hurts HP business.

You can also read my post: Acquisition is not simple: SAP-Sybase acquisition agreement, in order to understand the issues facing a company acquiring another company.

WebMethods acquisition was the first significant Software AG's acquisition. It looks like a plausible acquisition, because WebMethods was a Leader in the BPM, SOA and Integration markets.
Software AG branded its SOA and BPM suite as WebMethods and kept key WebMethods employees.

IDS Scheer was the second significant acquisition. A German company (Software AG.) acquired another German company (IDS Scheer). IDS Sceer's ARIS is a leading BPA product especially for ERP suites. 

In order to improve its position in the new Intelligent Business Operation Use Case, Software AG acquired two companies:
Jackbe provider of Mashups and Real Time Business Intelligence platform and Apama a Complex Event Processing company. I already discussed these acquisitions in my post: IBPMS: BPMS Leader Software AG attempting to lead in IBPMS.  

Bottom Line: Reasonable acquisitions and adequate merge execution.

Technology
WebMethod and Software AG products overlap: both companies had SOA products. However, Software AG did not develop a BPM solutions. The decision was to base the suite on WebMethods products. 
Software AG's leading SOA Registry and Governance product: Centrasite (co developed with Fujitsu before WebMethods acquisition), is the Registry used in WebMethods suite.  
After IDS Scheer Acquisition, its BPA products replaced WebMethods solutions. 

The two BPM suites (WebMethods and IDS Scheer) were not integrated to a single suite, but tied the environments together. The quality of the mechanism of using artifacts from one environment in the other environment is good.

The Bottom Line:The technological decisions and implementations are reasonable. 

Implementing BPM 
In a previous post, I explained why SOA is implemented by more enterprises than BPM. 
Few years ago, more than 50% of enterprises adopted SOA according to surveys results.
According to Forrester's survey results, only 26% implemented or expanding Business Process Management tools in 4thQ 2012. 

According to The Forrester Wave: BPM Suites , Q1 2013, "Best Practices dictates that to get a good return on your BPM investment means scaling from project to program."   

Program includes many Projects, is more strategic and more tightly coupled to Business.

SOA is not a Project it is a Program (or Initiative or a Journey). You may find positive correlation between SOA as a Project and failure in implementing it or not achieving enough Value for justifying the SOA effort.

Starting SOA or BPM by a project addressing a Pain Point is a good practice, however afterwards you should build a Program and not execute isolated and uncorrelated projects.

The main difference between SOA and BPM is the approach. SOA Program could be relatively slow and gradual. According to Best Practices, in BPM Program execution, shortening the time is more important than reducing costs.

The reason is that benefits could be realized quickly when the lack of Process Visibility is replaced by Process Visibility inherent in BPM.

As BPM will mature expect more BPM Programs.

According to Forrester Software AG major strength is  "Software AG strikes good balance between project and program". 
If other vendors will not catch up in "good balance between project and program", Software AG Market position could be improved.  
  
My Take
Software AG's long transformation from Mainframe Software company to Business Process Management and Service Oriented Architecture was successful.

The largest Business Line in terms of revenues is BPM and SOA.

The company positioning in the crowded BPM market is good.

The Mainframe Software Business Line is declining slowly. Rapid decline could reduce the revenues significantly. 

The company is one of the top 25 global software companies i.e only Mega Vendors can afford to acquire it.

The combination of all the factors cited in this paragraph is higher Survival probability in comparison to 2009.   

However, inadequate strategy or inadequate execution could hurt its stability and profitability and reduce its survival probability. 

It should be remembered, that even if Software AG will be as successful as it was in the last years, that does not guarantee that it will not be acquired. 

Mega Vendor could acquire it. As long as the Mainframe Business Line is viable, it is unlikely that a Mega Vendor will do this. 

For the Long Term, it is a possible scenario. If Software AG will become an Acquisition Target, I guess that the potential acquirer will probably be SAP.

 

Will Business and IT Aligned?

For decades we are talking about closing the gap between business and IT, but the gap is still as wide as it was.
In the beginning of the ERP era, we focused on aligning Business Processes and Core Systems, but in most enterprises we failed.

SOA was the next alignment promise: defining the SOA Services in Business boundaries instead of Technical boundaries, should narrow the gap. However, despite of SOA Business Value (Agility and Reuse) in most enterprises, the large Business-IT Gap remained as large as it was. 

The IT Community aimed at the next alignment attempt: SOA is technical and BPM is its Business related complement. 

Will the current BPM based alignment attempt succeed? I do not know, but Nick Heath's article  titled: Stop doing what the vendors tell you, CIOs told, published in Tech Republic, suggests that the root of the problem is not Technological.  

Stop Doing What the vendors Tell You
Nick Heath's article is based on Gartner's CIOs survey. Gartner surveyed more than 2,000 CIOs about their plans for the coming year.Heath's  summary of the survey result is: "The problem with CIOs is they don't appear to share the singular focus of their organization. In general, Corporate IT strategies are largely unchangeable and loaded with generic  statements about cost and service levels."

In other words: 
1. IT priorities are not in accordance with Strategic Business priorities.
2. IT Strategies are inflexible and static. The CIOs do not change strategies when the Business is adapting to changes.     

My Take
It is not because of SOA or BPM or ERP that Business and IT Alignment is not improving. 
The reasons are closely related to perception:
How IT professionals evalute their department's  contribution to their Corporate Business (They think that they contribute a lot) vs. the way Business professionals perceived their Enterprise IT  (You can not do Business with them and you can not do Business without them, Inflexible, not aligned with Corporate Goals and Missions).

The Gap could be narrowed, if and only if,  IT professionals and Business people views of the other team DNA and Role will be changed. 

The Risk of Consumerization and Could Computing
Consumerization may reduce IT and CIOs responsibilities and budgets, because users could bring their Own  Devices and Software.

Cloud Computing could also narrow IT scope, because non-IT managers can buy IT services and systems directly from Cloud Vendors.

The risk is Chaos or loosing Control of IT Systems. 

IT Vendors and CIOs
Gartner's recommendation to CIOs, as described by Nick Heath, is not new: IT Vendors could shift IT goals away from the Corporate goals and strategies.

Few years ago I wrote few posts on possible Vendors conflict of interests e.g. 
SOA VDS – AmberPoint Example, ESB for an Orphan.
  
CIOs not stop always from doing what the vendors tell them, but they should understand when it is proper to act according to a vendor recommendation and when it is not.