ISIS Papyrus Software

Posts Tagged ‘SOA’

Business Architecture: Consolidation vs. Integration

In benefits, markets on November 12, 2009 at 2:30 am

The enterprise IT market is often characterized by fragmented products for specific applications. Although their hard-coded functionality may seem sufficient for the intended purpose it is time and again overlooked how much effort it takes to integrate them via XML and SOA.

The Business Architecture concept of ISIS Papyrus therefore provides businesses with a single consolidated information system that offers collaboration, process coordination and role coaching on top of the background data processing. This single information platform enables a business to model its key information assets, to support its process workgroups and to create and retain the knowledge about how the business actually performs its processes. All this knowledge and experience is shared between workgroups according to authority. Management can monitor quality criteria and audit each single process if needed. Because it is a single life-cycle platform, software borders do not exist and process optimization is a continuous exercise that does not require complex projects.

Enterprise architects who hope to  create an infrastructure of replaceable components by segmenting and layering various products have to consider poor compliance to standards and continuously changing products. These are major stumbling blocks for an enterprise architecture, whereas ISIS Papyrus integrates seamlessly with legacy applications to provide instant benefits with its rich functionality and platform and output channel independence. On the long term it provides an application infrastructure that allows for a gradual enterprise strategy towards consolidation with no additional integration efforts.

Advertisements

Seamless Integration For Legacy Applications

In product on October 29, 2009 at 1:45 am

SOA is not merely a promise but rather a practical solution available today to enable organizations to re-use valuable legacy business processes for enterprise content management. Enterprises have increased focus on the usable and practical possibilities of SOA protocols for integration of content management applications across the organization.

Taking an interoperable approach – beyond mere integration – to delivering specific business value with SOA, customer-focused organizations can now use data from legacy business applications for personalized business communications that transform transactions into 1:1 interactions with customers.

Using Papyrus, changes in business correspondence require no changes in legacy applications because the platform’s metadata repository manages all access to and interaction with content from these existing systems.

Read the full story including an interesting application sample here.

Handling Enterprise Growth Without Java

In scalability on October 22, 2009 at 2:02 am

With many Papyrus Platform installations experiencing substantial growth the topic of application scalability has come to the foreground. Owing to its design the scalability of the Papyrus Platform is unlimited in principle but it is restricted by certain synchronicity needs. Simply reading or displaying documents or content from storage has no limitation, but keeping multiple write accesses in sync creates scalability issues. Clearly, when the number of users is doubled from 1,000 to 2,000 users then it does require monitoring and, if necessary, scaling of the hardware. When the number of documents or process tasks is doubled from 1,000 to 2,000 per hour that also requires consideration how that load can be safely spread across server nodes. However, scaling Papyrus Platform applications is very simple compared to, for example, three-tiered Web/Java/SQL/SOA application clusters, explains Max J. Pucher, Chief Architect at ISIS Papyrus.

User complaints about a ‘slow application’ without any measurable details do not really help, yet have to be carefully considered. Users are often unaware of different processing requirements for documents looking rather similarly. The document might be simple for the user but the back-end process can be fairly complex and proactive monitoring is advised, which Papyrus Platform provides with easy-to-use dashboards and summary reports.

Scalability is not only about tuning or maintaining an acceptable response time for a growing number of users. It is unreasonable to expect that the system will handle growth in users and transactions automatically. No system does. Papyrus has many load balancing and tuning options and many are set either by default or by the system. Document applications are a complicated conglomerate of GUI, process, and rule execution threads that read and write data from a number of service interfaces or databases. The performance of the SOA back-end service interfaces or the database is much more relevant to the scalability than the user front-end. Using common database or transaction measurements the Papyrus Platform executes millions of transactions per hour and provides substantially simplified systems management and tuning without neglecting the user experience.

Papyrus Application Scalability

In scalability, solution, system management on July 7, 2009 at 4:08 am

There are now over 200 installations of the Papyrus Platform. Half of those serve hundreds to thousands of users. The others manage high-volume production systems. Most installations handle between 10,000 and 100,000 inbound or outbound document tasks per day in either straight-through processing or user-interactive mode. All these installations continue to grow and thus application scalability is becoming a common theme. Adding new applications is so easy that users tend to forget that possibly more HW resources are necessary to handle those processing needs. We propose a pro-active monitoring approach using our integrated monitoring and reporting facilities.

The Papyrus Platform offers unlimited scalability but applications have to be properly defined taking such scalability into account or they have to be accordingly updated as the application grows. Often restricted networks or other limited resources require tuning measures to ensure acceptable user response times.

There are two discussion posts available for your further reading:

Welcome to the Real World: Overhead: Java Application Scalability

Chief Architects Blog: Papyrus Application Scalability