Forrester Application Development & Program Management March First Look

This is my response to Forrester’s Jeffrey Hammonds March First Look:

Dear Jeffrey,

I have read your March 20th First Look several times now. For some reason I kept it in my inbox.

Now when I was about to clean it I found what was bothering me. Everyone at Forrester is talking about what the NEXT FIVE years will bring in terms of application development technology to enable change. You say that developers need to develop means to enable change, because of the fourth paradigm of SOA, rules and CEP will enable that.

What I disagree with: First, programming in the sense of coding for applications is too complex and there is nothing anyone can do to make change easier. Second, agile processes will never be delivered by coded applications and best-practice release management. It requries a life-cycle repository but that can’t be used with coded applications, because there is no 100% roundtrip from model to code and back. Third, why should anyone need to wait for five years?

You also mention that RIA will be the next big thing and here I am not in disgagreement. It should however not be a programming model like Adobe Flex which will once again resist the change you are asking for. What I see missing in most process applications is however not a cutsy web-GUI but the core information carrier - content! Business documents are not BLOBs, because they typically contain data that has to be mapped to the data models of the business process. Why does NO ONE talk about that? There is a huge amount of coding going on to integrate MS-Word and PDF and OCR-images and all that code will resist change! XML, XSL and other acronyms do not solve that problem as promised. It all requires a lot of code to work.

The future that you are talking about is here and has 200 corporate users with up to 3000 seats!
a) The ISIS Papyrus Platform has a model&rule-to-production paradigm via its WebRepository to deploy powerful versioned application models time-synchronized to any number of production servers.
b) Papyrus uses a state/event model for processes rather than an limited flowcharts.
c) Business rules can be created to control processes in terms of compliance.
d) Processes are created by teaching the complex event patterns (CEP) that define the process progression to our User-Trained Agent.
e) The metadata model of the platform is populated via the Adapters (DB, MQ, SOA) with federated business data and thus directly available to the users, content, rules, and the CEP functionality. This enables real-time business data to be used for process decision making without the need for a data warehouse.
f) Inbound and Outbound content is handled by our ECM and DOM modules and imbedded into the context of the process/case.
g) User frontend is either the configurable Papyrus Desktop our the new Papyrus EYE web presentation that uses Flash and is deployed also through the repository. In difference to Adobe Flex there is not a single iine of Java or .NET code needed to trigger a process from a business application data set, create the related content and present it to a Web front end.

There is more on our Website http://www.isis-papyrus.com and we have our OpenHouse in Dallas and Vienna coming up and you are invited to see this for yourself. We may be at the Forrester IT-Forum if things work out, so please drop by.

Sorry for budging in on you and thanks for reading this!

Freundliche Grüße,
With my best regards,
Max J. Pucher
Chief Architect ISIS Papyrus

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.