Case Management Frameworks: A growing subset of the Case Management market

Recently I read a new Gartner Magic Quadrant. The Magic Quadrant is titled: Magic Quadrant for BPM-Platform-Based Case Management Frameworks (12 March 2015). 

It is a new Magic Quadrant relating to a subset of the Case Management market. Case Management frameworks is a growing market, which is important enough for producing a Magic Quadrant. The Magic Quadrant was written by Gartner's analysts Jannet B. Hill, Kenneth Chin and Rob Dunie.  

What is a Case Management Framework?
It is possible to build a solution based on Model Driven tools or on Coding tools or COTS (Commercial Of The Shelf). 
if you need less flexibility COTS are better fit then modeling tool.

Case Management Use Case is exactly the opposite of a fixed solution. It is management of complex and less structured Processes performed by Knowledge Workers. A Case Management Process include ad hoc decisions based on Knowledge, Content and interaction with other experts.  

The Decision Centered subset requires even more flexibility than the other subsets of this market, therefore CMFs are Model Driven. Actually, they are Patterns, which should be adapted for specific Processes. 

The illustration is based on text retrieved from Gartner's Magic Quadrant for
Case Management Frameworks

The simple illustration above this line, depicts five layers of a CMF.

The lower basic layer is a BPM solution. The BPM solution could be a BPM product, a BPM suite or a complete IBPMS suite.

The second layer "General Purpose" is the only required layer in addition to basic BPM layer. It is Architectural Pattern for casework handling.

The third and fourth optional layers are cross-industry and industry specific business domain logic.

The fifth (optional) is a complete executing solution. 


Vendors positioning
Only two vendors, Pegasystems and IBM are positioned in the Leaders part of the Magic Quadrant. Appian is the only Challenger.
EMC and Eccentex are the only Visionaries.
The Niche Players are: Opentext, Newgen Software, K2, Kofax, Hyland and Micropact.

My Take
I have two reasons for not discussing CMFs beyond the limited discussion in previous sections.

The first reason is that you can read Gartner's Magic Quadrant. The analysts know better than me.

The second reason is that the CMF market is very immature. I repeat my comment on the IBPMS market in a post I wrote two and a half years ago: "Expect Challenges in Immature markets like IBPMS". Replace the acronym IBPMS by the acronym CMF and you will know exactly what I think of the Maturity level of the CMF market.

However, My Take includes some remarks:

• IBPMs Leaders are the the best candidates for leading the CMF market.

The two Leaders (Pegasystems and IBM) are also leaders of the IBPMS Magic Quadrant. The only Challenger (Appian) is the only Leader of the IBPMS Magic Quadrant, which is not a CMF Leader. I would not be surprised, if Appian will be a Leader in the next CMF Magic Quadrant.

• It is not a coincidence: CMF functionality is included in IBPMS 

IBPMS includes all BPM Use Cases. Case Management is such a Use Case. CMF is a subset of Case Management.

•   Do not expect pure BPM vendors to be CMF Leaders 

For the same reason that you should not be surprised to find IBPMS Leaders as CMF leaders, you should be surprised to find a pure BPM in the CMF Leaders square. 

 

• Gartner's CMF model is still immature and the evaluation criteria and the requirements could be changed in next CMF Magic Quadrant

According to Gartner's Magic Quadrant report, IBM and K2 support only the  basic layers of CMF. A Leader (IBM) who does not support three of the five layers, implies  market immaturity, as well as evaluation criteria immaturity. 

• I never heard of some of the Niche Players

It is not because of my ignorance. The reason that I never heard of Eccentex, MicroPact and Hyland, is the CMF market immaturity. 

It is exactly like the IBPMS Magic Quadrant of 2012. Whitestein Technologies is an IBPMS Visionary I never heard of. Mr. Dominic Greenwood, its COO, commented that it is not surprising, due to the company's low profile outside Europe. 

• Who is missing from the CMF magic Quadrant?

All the vendors positioned in the Visionary square of the Updates IBPMS Magic Quadrant of 2014, were not included. These vendors are: Oracle, Tibco Software, Software AG, Vitria, Whitestein Technologies and Bosch Software Information.

Missing BPMS Leaders and IBPMS significant market players such as Oracle, Tibco and Software AG is another indicator of market immaturity. Expect to find some of them as Visionaries, Challengers or even Leaders in an updated  CMF Magic Quadrant. 

Oracle is a giant which could survive without IBPMS product, but why should not Oracle attempt to lead the IBPMS market, as well as the CMF market?

It can afford acquiring an IBPMS or CMF vendor, same as it already did in the BPM market, the SOA market and the ERP market. 

Software AG and Tibco Software are large companies, but the BPMS/IBPMS Business Line is their main Business Line. They have no choice but to try to close the gap in the CMF market.

They can extend their products functionality or acquire a CMF vendor.

Micro Services: A new SOA style Architecture or a Buzzword?

Capability Analysis
Source: English Wikipedia

Micro Services is a new architectural style based upon independent Services. 

The terms Micro Services and Micro Services Architecture are often used. It is an architecture based on independent relatively small components named Micro Services.

Some people may think that Micro Services Architecture is a new and improved Service Oriented Architecture (SOA). It is not.

Martin Fowler is the first name mentioned in articles about Micro Services. Fowler is a British Software Engineer specialized in Software development. 

I read the article: Microservices in Fowler's Web site. I am more confused about Micro Services characteristics after reading the article.

The article was written by James Lewis and Martin Fowler.

What Micro Service Architecture is and what Micro Service is?
The articles discussed the following characteristics of Micro Service Architecture and Micro Services:

1. It is a new Architectural style 
OK, let's understand what is new and what is its Value Proposition.

2. "approach to developing a single application as a suite of small services" 
Nothing to write home about. Remember Cool:Gen? 
A leading Client/Server IDE. It was a leading Component Based Development (CBD) tool. Its first version was launch in 1987. It is easy to find other IDE tools which were available 15 years or twenty years ago and were based on CBD methodology.
The Services granularity is small, unlike the coarse grained granularity of SOA Services.

3. "each running in its own process and communicating with light weight mechanism, often an HTTP resource API."
This is a performance issue: is the Overhead of many Micro Services small enough? 
I am sure that for large applications it is not, unless light weight communication mechanism is used.

Similarly, REST is preferred over SOAP because of better Performance and reduced Complexity.

 4. The Micro Services are "independently deployable by fully automated deployment machinery" 
It could be a good technical approach for Deployment and for Change Management.

5. Monolithic applications run a in a single process they are scaled by multiple instances. Each Micro Service is deployed under a different process. No need to multiple instances, so Change Management is simpler and less error prawn. 
Monolithic Applications are not Silo Systems or Monolithic Applications in SOA context. In this article they refer to Server Side only applications, while in SOA context they include all layers: Server as well as Clients and Middleware. 

As in previous section the focus is technical. By running each Micro Process under different process, Performance could be improved and Deployment and Change Management of each Micro Service is less dependent on other Micro Services. 

6. "These services are build around Business Capabilities"
Now I am really confused. How componentization of Application could be related to Business Capabilities? 


Capabilities and SOA Services
Capabilities are defined as Coarse grained Business elements. Capability Analysis is used for bridging between Business Architecture and Service Oriented Architecture. 

Capabilities are Business entities defining what and not How the Organization could do something Valuable. 

System Analysis in Service Oriented Architecture could use Capability Analysis. After defining the Capabilities, you could map each Capability to Services i.e. according to the frequently used definition of Capabilities, a Capability is more Coarse Grained than a Service. 

How could a Capacity will be related to a Fine Grained entity such as Micro Service?

What is the relationship between an Inter-Application entity (Micro Service) and a Business Entity (Capability)?

I do not have adequate answers to those questions.

Even if you define Capability as a smaller Business entity mapped  Many to One to SOA Service, i.e. few capabilities included in a Service, I am still confused about its relationship to Micro Services. 

It should be noted, that some companies, defined Capability as a less Coarse Grained entity than a SOA Service.

The Bottom Line
Micro Service Architecture is a new architectural style using terminology and approach resembling Service Oriented Architecture. However, the scope of Micro Service Architecture is Inter-Application.

SOA scope is Enterprise and Virtual Enterprise. Virtual Enterprise may refer to Public Clouds and Hybrid Clouds, as well as other types of implementing some of the Applications or some of the Services outside the Enterprise boundaries.

SOA Services are defined by Business Services  boundaries. The alignment of Micro Services to Business Services is not well defined.

My Take
Micro Service Architecture could be useful. It is a small scale SOA like Architecture within an Application. It should be compared to other approaches to defining and managing Application Components. 

Service Oriented Architecture is defined in another level and is orthogonal to Inter-Application Architectural styles such as: Micro Services Architecture or OMG's CBD model. 

Micro Service Architecture could be useful for Agile Software Development Methodologies. It completes the methodology by adding a development and deployment style.