In information systems, applications architecture or application architecture is one of several architecture domains that form the pillars of an enterprise architecture (EA).[1] [2]
An applications architecture describes the behavior of applications used in a business, focused on how they interact with each other and with users. It is focused on the data consumed and produced by applications rather than their internal structure.
By example, in application portfolio management, applications are mapped to business functions and processes as well as costs, functional quality and technical quality in order to assess the value provided.
The applications architecture is specified on the basis of business and functional requirements. This involves defining the interaction between application packages, databases, and middleware systems in terms of functional coverage. This helps identify any integration problems or gaps in functional coverage.
A migration plan can then be drawn up for systems which are at the end of the software life cycle or which have inherent technological risks, a potential to disrupt the business as a consequence of a technological failure.
Applications architecture tries to ensure the suite of applications being used by an organization to create the composite architecture is scalable, reliable, available and manageable.
Applications architecture defines how multiple applications are poised to work together. It is different from software architecture, which deals with technical designs of how a system is built.
One not only needs to understand and manage the dynamics of the functionalities the composite architecture is implementing but also help formulate the deployment strategy and keep an eye out for technological risks that could jeopardize the growth and/or operations of the organization.
Applications architecture strategy involves ensuring the applications and the integration align with the growth strategy of the organization.
If an organization is a manufacturing organization with fast growth plans through acquisitions, the applications architecture should be nimble enough to encompass inherited legacy systems as well as other large competing systems.
See main article: Architectural pattern.
See also: Software design patterns. Applications can be classified in various types depending on the applications architecture pattern they follow.
A "pattern" has been defined as:
"an idea that has been useful in one practical context and will probably be useful in others”.
To create patterns, one needs building blocks. Building blocks are components of software, mostly reusable, which can be utilized to create certain functions. Patterns are a way of putting building blocks into context and describe how to use the building blocks to address one or multiple architectural concerns.
An application is a compilation of various functionalities, all typically following the same pattern. This pattern defines the application's pattern.
Application patterns can describe structural (deployment/distribution-related) or behavioural (process flow or interaction/integration-related) characteristics and an application architecture may leverage one or a mix of patterns.
The idea of patterns has been around almost since the beginning of computer science, but it was most famously popularized by the "Gang of Four" (GoF) though many of their patterns are "software architecture" patterns rather than "application architecture" patterns.
In addition to the GoF, Thomas Erl is a well-known author of various types of patterns, and most of the large software tools vendors, such as Microsoft, have published extensive pattern libraries.
Despite the plethora of patterns that have been published, there are relatively few patterns that can be thought of as "industry standard". Some of the best-known of these include:
The right applications pattern depends on the organization's industry and use of the component applications.
An organization could have a mix of multiple patterns if it has grown both organically and through acquisitions.
TOGAF describes both the skills and the role expectations of an Application architect. These skills include an understanding of application modularization/distribution, integration, high availability, and scalability patterns, technology and trends. Increasingly, an understanding of application containers, serverless computing, storage, data and analytics, and other cloud-related technology and services are required application architect skills. While a software background is a great foundation for an application architect, programming and software design are not skills required of an application architect (these are actually skills for a Software Architect, who is a leader on the computer programming team).
An applications architect is a master of everything application-specific in an organization.An applications architect provides strategic guidelines to the applications maintenance teams by understanding all the applications from the following perspectives:
The above analysis will point out applications that need a range of changes – from change in deployment strategy for fragmented applications to a total replacement for applications at the end of their technology or functionality lifecycle.
Understand the system process flow of the primary business processes. It gives a clear picture of the functionality map and the applications footprint of various applications across the map.
Many organizations do not have documentation discipline and hence lack detailed business process flows and system process flows. One may have to start an initiative to put those in place first.
Every organization has a core set of applications that are used across multiple divisions either as a single instance or a different instance per division. Create a solution architecture template for all the core applications so that all the projects have a common starting ground for designing implementations.
The standards in architecture world are defined in TOGAF, The Open Group Architecture Framework describes the four components of EA as BDAT (Business architecture, Data architecture, Application Architecture and Technical architecture,
There are also other standards to consider, depending on the level of complexity of the organization: