Papyrus Project and Services Planning

Most Papyrus Platform projects go quite smoothly and deliver powerful functionality without the need for a complex development project. The broad functionality of the Papyrus Platform enables larger and more consolidated applications, with the consequence that some of the projects in large corporations are a struggle despite the advantage that there is no Java or other programming necessary and that the number of involved people is quite small.

Once Papyrus gets chosen as the solution it means that business users saw something in the demo that they liked in terms of frontend and IT saw the functionality required in terms of technology. Neither business nor IT seems to accept that there is a need to use their specific business data model and interfaces, create the role/policy setup for authorization, define the building block objects, setup the administration workflows, define and test the backend data interfaces (despite XML, it is always the last thing provided for testing by IT), interface the document creation with printing and archiving and some more linkage here and there. Once that has happened the business workflows have to be defined. We always recommend to use the UTA to train them, but often someone decides that the workflows have to be rigidly defined so that they can be audited in advance. So suddenly someone (usually a third party) sits down and does lengthy process analysis.

All the while we are typically training and supporting third-parties who have never seen the product before because they were chosen as the cheapest manpower option. Project management takes a lot of time as well with daily meetings that take away time from implementation. Project planning and timing hardly ever happens according to business needs and IT capabilities, but influenced by company-political turfwars and budget constraints. The later we are in the project, the more management gets involved who know nothing about it.

Then the document templates and components have to be defined by the business users. Instead focusing on that business users come forward with the first change requests to the user interface – that they originally liked. Not too difficult, but it is an uphill battle against time. New requirements appear daily and are made no-go critera without changing the productive date. The planned time for testing gets shorter and shorter and no one takes the time to define proper testcases and acceptance criteria. No people were trained to run production but the go-live date is adhered too. Obviously there are issues and therefore each and every situation is reported to ISIS as a BUG to get support for free. Often there are issues with other applications that we are connected too or network or server issues and these are ALL ‘Papyrus problems’.

Does that sound familiar? Yes, it can get very frustrating! Depsite all of that the team at ISIS Payprus has ALWAYS delivered. The projects that were not taken productive failed after the Papyrus implementation was complete. Look, I am not blaming anyone. I am just stating the facts. I cannot laugh about the Dilbert comics, because they describe corporate ignorance too accurately. But enough of black humor. Let’s look forward on how to avoid these situations. It is really not that difficult!

What can we and the business users at our customers do to speed up projects?

1. Create a milestone plan of implementation phases where each states the functional goal or achievement.
2. Project phases must not have a rigid completion date and be able to overlap with the next phase.
3. Utilize a business architecture team, one or more implementation/test team(s) and analysis/tuning team(s).
4. Business architecture should be inhouse IT, analysis/tuning from business and IT, implementation can be external.
5. Start with a simple phase that can produce benefits quickly and that allows gradual growth and expansion.
6. Papyrus is LEAN technology by design, so it makes sense to remain AGILE (expand iteratively) in approach.
7. Utilize teams in a mode that allows overlap of analysis, implementation, testing and tuning for phases.
8. ALWAYS COMPLETE the first phase without add-ons, but add new features to later phases.

Overall the project approach would look like this and enable the business users to get early results and be closely involved in tuning the application to the optimal functionality in the later phases.

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.