Optical Image Technology, Inc.

content management, BPM, and workflow software

Your ECM system can connect with databases and other sources to extract documents and data for tasks, measurement, and management. Or it can disconnect you from all that. Connect or disconnect? Choose Wisely.

Enterprise-Scale Application Development

Today’s corporate world has seen an escalating need for pervasive and responsive computing power. Simple, straightforward computer applications that were useful for “keeping the books” have long since become overwhelmed by the demands of a constantly increasing scale. These increases in scale have, in turn, produced generation after generation of ever more sophisticated software and hardware systems.

Enterprise-scale system environments place unique demands on software that mandate precise design. The simple task of saving customer information to a data file becomes very complex when dealing with the possibility that five (or 5000) users are all trying to read and write to that same file simultaneously.

Scalability

The scalability of a software design is a description of its ability to handle ever-growing use and demand. There are three metrics of primary concern: throughput, capacity, and response time.

Throughput is a measure of how many units of work can be accomplished by the software/hardware system within a set unit of time. For example: a company’s Web portal might handle 10,000 user page requests each minute.

Capacity is a measure of how much data the software/hardware system can contain and use. For example: a data storage center might provide storage and retrieval for three terabytes of documents.

Response Time is a measure of how long a user (or interacting system) must wait for the software/hardware system to respond to a request. For example: a customer might request their latest bank statement from a Web portal and it might take the system three seconds to retrieve and display it.

The processing demands of thousands of users simultaneously hitting a system require the system to make use of machine clusters combining their power. As the user base grows and the system requires more speed, memory or bandwidth, usually the only realistic option is to add hardware to the system, often in the form of additional servers. To facilitate this, the software must be able to work in clustered environments; load balance work between machines; and have failover capability so that if one machine goes down, the others will compensate to share the workload without disruption.

Ideal scalability in enterprise software/hardware system design means three things:

  • System throughput can be increased without limit simply by adding hardware resources.
  • System capacity can be increased without limit simply by adding hardware resources.
  • System response time remains constant as throughput and capacity increase. In other words, returning a Web page to the browser takes the same amount of time whether 5 people are using the system or 5000.

There is a law of diminishing returns that affects enterprise-scale systems where a system gets less of a performance increase with each addition of hardware resources. This happens in real-world systems due to all system components communicating and organizing their efforts. As the number of components increases, so, too, does the percentage of effort that is devoted to this communication. Fortunately, the pace of hardware and software development has been such that very few enterprises experience problems with diminishing returns and the scalability limits that result.

Reliability

The scale of work being done on enterprise systems means that money is lost very quickly if the system suffers disruptions or outages. Workers standing idle for hours while a system problem is addressed can result in millions of dollars being lost in the form of salaries and productivity.

The need for constant availability has led some companies to adopt a “Rule of 3” approach to deploying servers. In such a scheme, two servers are deployed as a mini-cluster so if one fails, the other will immediately compensate, while a third server is kept in reserve. Having a dedicated reserve server allows the company to swap servers around (for upgrade and repair purposes) without losing the security of the clustered pair.

Responsible administration of enterprise-scale systems requires redundant backups, crash recovery without data loss, and back-out plans (to an alternate system of work) in case the system becomes completely unrecoverable.

Beyond system administration, developing applications for enterprise systems introduces challenges for software engineers, who must plan and execute enterprise software to more exacting standards than for stand-alone applications. Blame this on the weight of probabilities: an individual action that has only a one in a million chance of failing is a problem with such a small probability of occurrence that it might be tolerated on a low-use system. But at enterprise-scale levels, the same action might be performed by tens of thousands of users in the space of a minute, guaranteeing failure several times each day.

Software designers cannot make the assumption that something is so unlikely they do not need to worry about it. They must assume that anything that is remotely possible will actually occur in an enterprise system, and not just once. Impossibilities need to be addressed with precise and logical proofs.

Maintainability

Maintaining an enterprise-scale system has its own special concerns, and it’s important to keep two perspectives in mind when it comes to the maintainability of enterprise applications: customer needs and vendor needs.

Customer Needs

Enterprise environments have many machines generally being maintained by a much smaller number of people. Under these circumstances, it isn’t practical to require IT staff to install or upgrade software on individual machines on a regular basis. Installation/upgrade programs need to be easy to use and, if at all possible, allow the customer to install the system in one place and have the rest of the enterprise updated to match automatically. This is usually done in one of two ways: The IT staff may make an image of the client machines and use special software to push that image out to all client machines whenever a change is made; or the enterprise application is developed in the first place as a web application which is installed centrally on web servers and does not require installation on client machines.

Vendor Needs

Software used at the enterprise level is rarely retired. Applications written to a specific purpose decades ago have likely undergone years of adaptation as business needs changed. Vendors rarely are in a position to redesign and rewrite an application. Therefore, applications need to be architected and written with the expectation of future modification. The architecture must be open to expansion, with a coherent strategy for adding custom features as part of the initial design. Code must be written clearly and cleanly, and must be well documented so that future staff can understand it years later.

For more information or to schedule a demonstration, please Contact DocFinity now.

Take Five Newsletter
Subscribe Now!

/news-a-events/docfinity-articles/33-doc-mgt-basics/140-enterprise-scale-application-development