How things go 'round and 'round - Column 2

« links for 2006-11-14 | Main | links for 2006-11-16 »

November 16, 2006
How things go 'round and 'round

I had an email yesterday from my friend Robb, which I have his permission to publish here. Robb used to work for me -- in fact, I think that I hired him a total of three times -- and whenever a company seeking to hire him calls me for a reference, I always tell them that the only negative thing about hiring him is that when I'm ready to start another company, I'll be hiring Robb away from them. Robb has four essential qualities when it comes to working: he's smart, he'll do anything to get the job done for the customer, he always has my back, and he's funny. His email yesterday, as usual, showed off the smart and funny bits:

Below is a newly formed company called Miria Systems. I give a history how this company came into being. Imagine how some things never actually die off:

1998 - A company named Application Partners was founded around an insurance/finance product and named it Sequis-- because apparently the English language is short of meaningful words
2000 - FileNet bought Application Partners and renamed it PeBA (standing for Panagon eBusiness Application) shortly after that they got bored with the name PeBA and renamed the product Acenza
2003 - After some successes the Acenza FileNet stalled the product program (to make way for BrightSpire) and effectively sold Acenza to a company called Endymion
2004 - Endymion changed the name from Acenza to (drumroll) Acenza for Payables
2003/2004 - Not satisfied with a simple named change Endymion completely re-wrote Acenza for Payables and changed the name to ManagedPay
2004 - Endymion apparently used up a lot of their budget on the name changes (and even more on re-write) because they were forced into a merger with Software Consulting Group (SCG) -- the two companies formed Soluziona USA
2005 - Not satisfied with a single re-write was good enough to keep their engineers happy Soluziona USA again decided to re-write ManagedPay but decided that the name should stay the same
2006 - Soluziona USA sold their ManagedPay product to a group of investors who formed a new company around this three-times-rewritten-and-five-times renamed product, keeping with tradition they gave the company a name with equally little English meaning as anything else in this brief history -- Miria Systems, below is the link

www.miriasystems.com
The interesting thing here to me here, besides the obvious snide comments around product/company naming exercises, is that the functionality of this product lives on despite name changes, rewrites, etc etc. That the market still has the (relatively) same problems almost ten years later makes me think that there is a disruptive or revolutionary solution waiting to happen.
No doubt you will recognize all of those companies and product names, most of which (except for Miria) I have been either directly or indirectly involved with.
Just some thoughts....
/rr

What Robb didn't mention is that PricewaterhouseCoopers also took the Acenza code base and rewrote it in J2EE around the time that they were purchased by IBM, to create a case-based application framework targeted at insurance customers. Once part of IBM Global Services, it was further rewritten to make it "vendor independent", meaning that the underlying content and process management could be either IBM or FileNet products, hence serving up the least common denominator of functionality and completely obviating proper use of the underlying product. I had the unhappy job of doing a review of an installation of this on behalf of the customer, and it's unbelievable how little of the FileNet product capability was actually exposed or used.

Although I agree with Robb that the market need for systems like this remains, I'm not sure at all that Sequis/PeBA/Acenza/ManagedPay/Miria product remains a viable solution. I haven't seen it in a while, but last time that I did look at it, it was too heavy and rigid, too old-school, and had the same problem as the IBM version that I mentioned above in that it completely hid the underlying capability of the BPM system below it: you might as well be using records in a database table for queue entries rather than a BPM system like FileNet.

I've talked about this problem of hiding the very nature and capabilities of a BPM product behind a rigidly-structured custom system in the past, and discussed it briefly on my Web 2.0 and BPM podcast, and I feel that it's a significant contributor to the lack of acceptance of BPM in many organizations.

I believe that the new world of enterprise software is less customization and more customizability: give the users the raw product and let them do what they need with it.

Posted by Sandy Kemsley at 12:52 PM in BPM • Business • FinancialServices • SoftwareDesign | Digg This | Add to del.icio.us

Trackback Pings

TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/991

Listed below are links to weblogs that reference How things go 'round and 'round:

» Let them eat cake (write code) from James Taylor's Decision Management
In a recent post Sandy K. said: "I believe that the new world of enterprise software is less customization and more customizability: give the users the raw product and let them do what they need with it" [Read More]

Tracked on November 18, 2006 11:12 AM

Comments

"I believe that the new world of enterprise software is less customization and more customizability: give the users the raw product and let them do what they need with it."

I totally agree. It's going to be interesting to see how we get there though--I bet on new players coming up with the products that do it rather than the big old guys evolving or replacing their existing stuff.

Posted by: Anne at November 16, 2006 05:00 PM

Anne, I agree, this is not going to be the same old players that do something as innovative as is required. As Einstein said, "We cannot solve the problems that we have created with the same thinking that created them."

Posted by: Sandy Kemsley at November 16, 2006 05:25 PM

I entered the picture in the middle of the evolution at Endymion, have also worked with Robb, and am now with Miria Systems as the VP of Sales and Marketing. While I understand there may be skepticism believing that the 8th time will be the charm, as Robb points out, there is still a very present market reality that breathes life into applications like ManagedPay and others in healthcare, insurance, finance (mostly mortgage), and government.

I would argue they continue to have legs because no one has yet figured out how to get any one but the very enlightened (read: biz and tech influencers and buyers with a clear understanding of the power and use for native ECM/BPM functionality) to appreciate the 'application' potential unless it's pre-built for them to see. Unstructured data is the classic Hydra and most people can only focus on one head at a time

This go around we've done our best not to bury our applications beneath heavy, seven-layer java dip so that our vision of having back office operations (A/P, contracts, HR) serve as the beachhead to demonstrating BPM usefulness can be best served. To that end, as a shameless plug, if anyone would like to see what we're up to, and it is very different this time, feel free to drop us a line.

Rod Casilli
Miria Systems

Posted by: Rod Casilli at November 16, 2006 07:25 PM

Hi, Rod, thanks for joining the conversation -- I recall meeting you at a FileNet dinner in Toronto back in 2004, the week that Endymion was acquired by Soluziona.

Your argument that no one can figure out how to do anything with the native applications but everyone has to have it pre-built is a bit of a chicken-and-egg phenomenon: if we never give them the out-of-the-box tools to play with, how will we know that they can't understand it? It's been years since I've seen most organizations give native access to these applications to the users, and the underlying apps have progressed significantly during that time (as have, likely, the users). Isn't it time to start exposing more of the native functionality to see what can be done with it, rather than perpetuating custom applications and frameworks that prevent anyone from using much of the originally design functionality of the underlying system, and usually require significant retrofit when the underlying system is upgraded?

I appreciate that you're trying not to create that heavy layered approach this time, and hope that the focus is not to constrain the underlying software, but to free it.

Posted by: Sandy Kemsley at November 17, 2006 10:05 AM