In the SOA world, what does the word ‘application’ mean?


Back when I was in college, there wasn't a lot of debate about what a 'program' was.  It was pretty clear.  As time went on, however, our 'programs' became much more about systems of programs that met a business need, so we started using the term 'application.' 


Now, in the age of Service Oriented Architecture, we are faced with dual challenges.  We want to increase the agility of the organization to meet ever-changing business needs, while reducing the overall complexity of the application portfolio.  Deep under all of this, is the portfolio itself... the list of the applications.


An application is the most basic unit.  It is what we build in our projects, and deploy into production.  It is what we track, secure, manage, maintain, and retire.  It is the unit that we use when calculating roll-up statistics like average size, average cost, and average complexity.  We even talk about things like "reducing the number of applications" or "reducing the average application complexity" because they appear to capture the intent of reducing the total cost of ownership.


And there's the rub.  If we change the definition of 'application,' then we change the list.  Our data has to be recalculated.  Our cost of ownership calculations need to be recalibrated.  Our understanding of complexity has to be challenged, validated, and re-applied. 


On the other hand, most of the definitions of an application come from the days when we spoke with ease of a system that had its own database and its own user interface.  We didn't have layers like collaboration or messaging.  We didn't consider integration to be part of the basic application architecture, but rather placed integration as "that thing done on the outside edge."  Not any more.  The old definitions don't work now.


I'm not sure that an application still needs to be our most basic unit.  Just as scientists once considered an 'atom' to be the smallest component of matter, only to have smaller and smaller particles described and understood, perhaps an application becomes a term that we keep around, but we no longer use in calculating the statistics of IT management.  Instead, we'd need to understand the number of connected components in the infrastructure, and the complexity of them.  (pick you word du jour)


On the other hand, perhaps it is more difficult to reeducate everyone to explain why "reducing the number of applications" doesn't mean very much.  It is hard to fight against the marketing coming out of articles in CIO and InformationWeek and various vendor presentations if they keep talking about 'applications' as the smallest unit of measure.


So, here's the question:



Do we redefine 'application' so that it remains the smallest unit of measure, or do we redefine it so that an application contains smaller units of measure, units that replace it in calculating the cost and complexity of our portfolios?


If you believe you have the answer, please let me know.

Comments (3)

  1. Kevin Spencer says:

    I don’t think I’d redefine "application" as the smallest unit of measure. It still has a meaning within the expanded scope, which is basically the same meaning that it always was. For many years, applications have shared "components" such as DLLs, services, and resources. SOA simply extends the idea of component architecture to a larger scale.

    Therefore, I would go with the second option, the redefinition of "application" as containing smaller units of measure. The word "component" has been in use for many years as representing a component piece of a system, and an application is a system.

    We have to think ahead after all. Where are things going? For example, we divide our physical brain into regions which perform various specialized functions. However, that division is an abstraction. We know that in fact, the entire human body is a single unit, and that at the molecular level (and higher in some cases) the divisions are much more difficult to identify.

    In fact, the brain is one large mass of neurons, highly organized, but interdependent as well. An interesting capability of the brain, which we can likely expect to appear in software systems in the future (our software emulates the way our brains work, after all), is the ability of one portion of the brain to take over the functionality of another in the event of catastrophic damage. When software does this, how will we discriminate between one "application" and another?

    I would posit that in fact, perhaps the word "application" should be extended to indicate a specific (aggregated) type of "component," just as a Node can "contain" other nodes in a tree structure.

  2. In a prior post, I asked the question: should we redefine the word ‘Application’ now that our definitions…

  3. Nick,

    As you, I think that the big issue in current IT "science" comes from the concept of "application".

    Currently, enterprise information systems largely fail to deliver in time and are a big threat to business adaptability. Enterprise information systems are made of a very large number of applications, which are connected in different ways. Today, IT organizations spend most of their time and money tying all these applications together in order to build an integrated information system.

    I think that the problem comes from the nature of the application itself. Applications are built to help businesses realize their objectives. Therefore, business people expect things from an information system from their specific point of view. In fact, an application is an automated system which embodies a specific point of view on business objects and executes a process from the narrow viewpoint of a small number of business users. An application is just an implementation of a business process, and the business objects they need. As a result, an application embodies a narrow ontology of the enterprise ontology. With time, you have different representations within your information system. The information system integration task is to connect all these different narrow ontologies to build a global ontology from the point of view of the enterprise.

    If we want to have an integrated information system, we have to stop building applications that are specific to a small class of business users, and instead build a system that is aligned with the needs of the business itself, being treated as a first class citizen. A firm is an organization that takes things or services as input and combines or transforms them to build new things or services. Therefore, their first class citizens are these things or services they use and the way they use them in order to build other things or services. Things or services are called business objects and the way firms use them is called business processes.

    I think that if we build enterprise information systems from the viewpoint of the business, we will never have all these problems of ontology integration, because processes will be integrated right from the design phase. I believe that the reason why the ERP has been successful at integrating global information systems is because it was built in an integrated manner. Of course, it comes with its own drawbacks, especially its rigidity. But at least we know that an integrated enterprise information system is possible. IT organizations have to go beyond being the owners of applications and become the owners of business objects and business processes. And because accountability cannot really be shared, any business object and business process must have a clearly identified owner.

    I try to explain my views on my blog. It’s in French though 😉

Skip to main content