Analysis, Fact and Prediction

I am sitting here sipping my morning coffee in the Tradewinds Resort in St. Pete Beach, in Tampa Bay, Florida. I flew in to attend the XPLOR conference from snowed-in Boston last night where I had another fairly tiring meeting with Forrester Research.

By chance I had arrived when Forrester’s Andrew Bartels just held a presentation on the economic outlook. Following current industry estimates he believes that the IT industry will start to see growth again from the 4th quarter 2009. Well, could be. If nothing happens in between. I found more interesting that he proposes that we are at the beginning of new cycle of IT spending for applications that are ’smart‘. I am in principle agreement because we started that with our User-Trained Agent, but the term ’smart’ has been so oversold that it will be hard to use it that way. He then suggested that the ’smartness’ would have to be focused on certain market verticals and here my question was why? If the software was smart enough it would adapt to the needs of the vertical. He said, it would not be that smart. But after a little discussion I came to agree that some knowledge acquired by our User-Trained Agent could be valuable within the vertical – if the business is willing to share it. Another subject to be clarified in the near future …

I have said previously that I prefer Forrester over many other analysts because they are attentive. I have met with Craig LeClair and Sheri McLeish to discuss an upcoming report on customer communications or CCM, which is an expansion of the previous DOM Document Output Management field. Craig and Sheri are very knowledgable in this arena and it was still extremely difficult to get the functionality of the immense spectrum of Papyrus across. I was my second visit because during the first one hour session there was not enough time to discuss the Papyrus Interactive and On-Demand functions. It will be very interesting to see what comes of this resarch. As we are covered by Forrester for the first time (because I had not bothered before) my expectations are low. I cannot imagine that they will let us leapfrog the ‘established’ players on our first participation no matter how good we are.

A couple of discussion points are worth sharing with you. First, Craig did say that he considers the number of installs in the US as a measure of product quality. Well, if that turns out to be true then Forrester just slipped in my rating. Papyrus rating of Forrester is limited by a lower number of customers and customers won’t buy it because it is not well rated? A classic Catch22 and hen or egg paradox. So now you know why you will find the large players up front and it is not because they have the better product. When analysts consider market share and revenue, they rate advertizing budgets and sales tactics but not how good the product is for the user!

One point of poor rating was my sceptic stance towards the use of ’standard’ XML. Craig in my mind fell for the empty claim of vendors that native use of XSL-FO ensures higher quality and accuracy of processing than conversion to an internal format. Excuse me Craig, but there is no logic in that statement. According to Information Theory the functionality of a language such as XML is not intrinsic but defined in how the tag structure is interpreted and executed in the code. There is no difference between a conversion to internal formats or mapping one XML to another. As the meaning of XML tags is never fully defined (try to look up and understand XSL-FO descriptions!) the quality of interpretation is always limited. This is proven by the available open source XSL processors which are not compatible in function. Therefore all software vendors have their own special versions. Conditional processing, resource management, font support, multiple codepage support and external SVG charts make the use of XSL-FO a propietary affair. XML and ‘open standards’ is no more than buzzword marketing.

There is one acceptable XML benefit that is obvious, when you are transforming into a web document. But for any serious business application you have to create an electronic original (sometimes even digitally signed) that you need to present and transmit. It is a grave mistake to accept the limitations of XML for transactional business documents for this tiny benefit. Additionally the presentation of XSL into web browsers is not standardized either. An enterprise user only gets controllable document quality by presenting to either image, AFP or PDF. I will need cover the subject of XSL-FO on my Real World blog soon.

On top of that it would require twenty different XML structures to create a fully functional customer communications application. Where is all the other functionality outside of XSL-FO? Exactly, it is hardcoded. Can you take the complete application of one XSL-FO vendor to run on another?  NO! I rest my case.

Another point Craig made was that only Adobe gets the highest mark on PDF support. I see. Thank you for admitting that PDF is still a proprietary format. Why do we not get the highest mark for being best in supporting the Papyrus Repository?

Craig also took issue with our Papyrus EYE user interface, saying the FLEX is better because there are more developers for FLEX on the market. What? I do not get it. We do not need programmers with EYE but FLEX is better because there are more programmers for it? A FLEX programmer would be five times more productive to do your EYE application but when he leaves you are still in control of your final GUI that you can maintain with a non-programmer. If you have a hard-coded FLEX GUI and the hacker leaves … have fun with maintaining your frontend. I am now worrying that they will rate our repository poorly because it does not require Java programmers, when there are so many on the market. Right, so why are we outsourcing to India?

In these areas Forrester analysts have to step away from their technological shadow and past. George Colony, Forresters President, focuses on the other hand on a Business Architecture as the basis for tomorrows applications. Yup, that is the way to go and that’s what we supply with the UML2 models in our Papyrus WebRepository. I am bracing myself against the disappointment of Forrester rating us poorly because they can’t understand the power of our repository that are also valid for a seemingly simple communications application. But then all formatting vendors claim to have a repository, because they just call it that. AIA ITP has a directory with a couple of configuration files and a few tables with text and letter structures and they call that repository??? Get real, please. Seriously, I would expect that the ananlyst community sees through those marketing ploys and properly informs their clients about the true capabilities of products. Sofar, that is not happening.

What is Papyrus EYE? And how did we get there?

When I designed the Papyrus Objects concepts in 1997, it was one of my criteria to keep the presentation of information seperate from the functional logic. I guess it is much in line what is called the MVC or model-view-control pattern of OO programming. But it was not my main concern. I did see at the time that there were the business objects in the WebRepository that represent the metadata models of business and the functional objects that were needed to control the application. It was immediately obvious that the control part of the application was related to business process.

How would we present then the business objects to the user? I have to admit that this has been the toughest and most difficult part of developing the Papyrus Platform. First and foremost because we were way ahead of available technology. Everyone wanted us to code DDE, COM, and later .NET programming interfaces so they could hack into our functionality and code their own GUIS. I refused and still do. Today when all the buzz is SOA and messaging interfaces I have been proven right.

So we developed the Papyrus Desktop. It never turned into something that I was very satisfied with, despite being a fantastic, flexible do-it-all environment, but it was quirky and unusual. I was unhappy because it was too slow to respond to our customers needs. That had to do with programming and users not knowing what they want. Users only know what they DO NOT WANT once they see it. So we would do projects, define user interfaces and expand our desktop to support them and then the business users would always reject it. We always delivered … not always on time, but we delivered.

Obviously when we started to hack into our standard product in those late stages of a project there is no way to stick to a three month quality cycle as is normal with our products. Therefore the Desktop and Papyrus Client acquired a reputation for being buggy which was highly unfair (but understandable from a user perspective) as we changed it to satisfy those users.

in 2000 we started to do those web projects with WebArchive using modules and scripts running in Apache or IIS and even early WebSphere (till today a dreadful product!). Soon everyone – business users, IT and our consultants – were complaining about HTML and Javascript work. We had dreadful problems with IIS and Apache versions being incompatible and even with Apache that was incompatible between operating systems. We added the HTTP interface to our kernel program because I had decided at the time that I wanted Desktop and browser applications to be compatible and to some extent we did that with simple screen layouts using the same GUI view definitions in the WebRepository.

We needed our own stable technology to make the web compatible with Papyrus and thus created the Papyrus WebPortal, our own deeply integrated HTTPS server in 2002. Over the next years we worked with a variety of technologies such as Ajax, OpenLaszlo, and others depending on what customers wanted in the Portal.

Then I decided that a huge step forward was needed and we defined what was called XUI or eXtendeable User Interface. A library of GUI objects managed in the repository and presented via Flash code or QT. We started to develop kernel side functionality in PQL (Papyrus Query Language) in 2006 to make the creation of XUI user interfaces even simpler and faster. We did our first projects and inhouse applications.

By 2007 we knew that we were on to something big, because everyone (Adobe with FLEX and others) were beginning to market RIA or Rich Internet Applications built on Flash, Ajax or Java toolkits to run in the browser. But it is all pure programming on the server side, while with Papyrus we were doing a definable and manageable set of GUI components deployed under full version-control from the WebRepository.

As we did our first demoes and were able to present to customers Web GUIs in a few days where we had taken months of Desktop coding before we decided to make this a new mainstay of our Papyrus Platform by naming it independently of the Portal. Annemarie Pucher (CEO of ISIS Papyrus Software) suggested to name it Papyrus EYE with me suggesting the Egyptian Udjat – the eye of Horus – Symbol we now use as logo. There are still some customers who see the Flash Frontend as a problem but that will change as Adobe pushes forward. We are anyway not dependent on it as we run in our own QT based desktop also as a Plug-In in the browser and we can implement EYE also in Ajax with not too much effort.

We were always more concerned with core technology than fancy and flashy frontends and to some extent that was a drawback but pays off today. We have less legacy problems in Papyrus now. Powerful user interfaces are the key to user-friendlyness but only if they are not hard-coded and forced on the user. We are using the Papyrus EYE technology at this time to define a new Desktop layout that is very generic and provides the business user with simple OO navigation and search as well as full customizable context layouts.

If you will join us at the ISIS Papyrus Open House in April and May you will be very surprised.