Demystifying Enterprise Applications

Many of the applications we build are considered "enterprise", but what does the term really mean?
Gavin Davies

What are enterprise applications?

What does the phrase “Enterprise Application” mean to you? – a few responses from Twitter:

  • @candroo software for star trek
  • @BenjaminDavies Java, DB2, Websphere
  • @librophile85 Enterprise application: Starfleet entrance exam, surely?
  • @sgsabbage An application meant for use by medium to large businesses. Maybe even small ones, depending on the app.

We often hear the term “Enterprise” thrown around, and as web developers many of the applications we build are considered enterprise applications, but what does the term really mean?

Here I take a look at what enterprise applications are and what challenges they pose.


There are negative connotations to this term in some circles, but what does it really mean? ‘Enterprise application’ is a loose term for a type of software that solves fairly big problems. Martin Fowler describes it as:

the name I give to a certain class of software systems: the data intensive software systems on which so many businesses run. Another, and perhaps better, name for them is Information Systems since these are systems that process and manipulate information.

Enterprise Not enterprise

CRM software

Issue tracking


Stock tracking system

Single player videogame

Static website

Flash movie

Email client

Some examples of what is an isn’t generally considered an enterprise application

Capterra, a company specialising in recommending enterprise software, broadly defines the term in the following manner:

  • Targets any / all types of organizations – corporations, partnerships, sole proprietorships, nonprofits, government agencies – but not consumers.
  • Targets any / all industries.
  • Targets any / all sizes of organizations – Fortune 500 to Mom and Pop.
  • Includes function-specific (Accounting, HR, Supply Chain, etc.) and industry-specific (Manufacturing, Retail, Healthcare, etc.) solutions.

So, generally but not exclusively, we’ll define enterprise applications as business-facing rather than customer facing.

Enterprise challenges

Enterprise applications are generally complex and expensive to build due to their scale and complex requirements. The technical challenges involved in producing Enterprise software may include:

  • Data throughput – most enterprise applications needs to be able to churn through a lot of data, serving large demanding userbases. They therefore need to perform and scale well.
  • Complex business rules – businesses can have very complex rules that must be modelled in the enterprise application. Capturing these requirements can be incredibly challenging.
  • Persistent data and Data integrity – Enterprise applications usually deal with vital data that must be treated with care. 
  • Concurrent users – An Enterprise application often has to serve many concurrent users
  • Security – similar to Data Integrity. Enterprise applications must be particularly secure as they may have large userbases, amongst whom exploits can spread quickly. A medical record system is a good example of an enterprise application in which security is paramount.
  • Being robust – an enterprise application must have extremely high availability. It may have to survive network issues, intrusion attempts, and process complex business logic whilst remaining available. Should it fail, it must fail gracefully; it is not acceptable for an enterprise level application to simply crash. It should report errors and give the user a reasonable explanation.
  • Lots of user interface functionality – there will usually be a large amount of user interaction so the system must be engineered for usability.

There are also business challenges in producing and maintaining enterprise level applications, as large teams of developers and QA staff often need to be co-ordinated.

“Is it ready for the enterprise?”

This question basically means: can this technology or product cut it dealing with the challenges in the types of systems we’ve outlined here? This can be a bit of a loaded term thrown around defensively by people who aren’t really sure what Enterprise actually means, and “enterprise” can even be used as a dirty word to imply excessive complexity. It can also be a valid question, asking “does this software meet the needs of a large organisation?” Some technologies are not mature and stable enough to be robust in an enterprise application.

When we as application developers create an enterprise level application, we have to very carefully examine our technologies to see if they are able to deal with these challenges. We cannot just pick the current “flavour of the month”.

For many software houses, the default go-to languages for enterprise application development are currently Java and .Net: they are robust, fully enterprise platforms ready with transactions, web services, security, versioning features built in or available. This isn’t the end of the story, however: other languages are increasingly stepping into the enterprise application market. PHP, for example, is a language that is being used in several systems that could be classed as Enterprise Applications (e.g. Facebook). In a future blog post, we will examine whether PHP meets the criteria for being Enterprise Ready.

“Enterprise Application” may be a loaded term for some, but it does have meaning. We can consider it to mean software that deals problems faced by enterprises as opposed to individuals and small businesses. Enterprise Applications have a set of identifiable challenges and it is important to choose the correct tools and processes to address them.


Add a comment

  • 16 Aug 2011 19:42

    This is an interesting point for our side of the business regarding this…

    Electronically sharing health information is coming. For those of us in addictions treatment this has great implications. State and federal initiatives promoting electronic interoperability of health information affect us directly. This is especially true for those of us providing addiction treatment where privacy and confidentiality for covered programs is regulated by a federal law known as 42 CFR Part 2.
    Addiction treatment providers need to participate because sharing patient information will improve health outcomes. (, Behavioral Health Software)
    By Dr. John Leipold, Executive Vice President / COO, Valley Hope Association

Add your comment

If provided, we will link to this from your name