Jump to content

Applications architecture: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Manishpk (talk | contribs)
No edit summary
Manishpk (talk | contribs)
No edit summary
Line 3: Line 3:
The application architecture is specified on the basis of business requirements. This involves defining the interaction between application packages, databases, and middle ware 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.
The application architecture is specified on the basis of business requirements. This involves defining the interaction between application packages, databases, and middle ware 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.


Application Architecture means managing how multiple applications are poised to work together. It is different from Software Architecture which deals with deigns concerns of one application.


== Application Architecture Strategy ==
== Application Architecture Strategy ==
Line 62: Line 63:
Application Architecture is the science and art of ensuring the suite of applications being used by an organization to create the composite application is scalable, reliable, available and manageable.
Application Architecture is the science and art of ensuring the suite of applications being used by an organization to create the composite application is scalable, reliable, available and manageable.
One not only needs to understand and manage the dynamics of the functionalities the composite application 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.
One not only needs to understand and manage the dynamics of the functionalities the composite application 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.






Revision as of 17:40, 20 May 2008

Definition

The application architecture is specified on the basis of business requirements. This involves defining the interaction between application packages, databases, and middle ware 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.

Application Architecture means managing how multiple applications are poised to work together. It is different from Software Architecture which deals with deigns concerns of one application.

Application Architecture Strategy

Strategy by definition is a stance and does not involve any action

Application Architecture Strategy involves ensuring the applications and the integrations align with the growth strategy of the Organization. If an organization is a manufacturing organization with fast growth plans through acquisitions, the application architecture should be nimble enough to encompass inherited legacy systems as well as other large competing applications.


Application Architecture Patterns

Applications can be classified in various types depending on the Application 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, that can be utilized to create certain functionality. 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

All applications follow one of the following industry-standard Application Architecture Patterns

  • Client-Proxy Server: Acts as a concentrator for many low-speed links to access a server.
  • Customer Support: Supports complex customer contact across multiple organizations.
  • Reactor: Decouples an event from its processing.
  • Replicated Servers: Replicates servers to reduce burden on central server.
  • Layered Architecture: A decomposition of services such that most interactions occur only between neighboring layers.
  • Pipe and Filter Architecture: Transforms information in a series of incremental steps or processes.
  • Subsystem Interface: Manages the dependencies between cohesive groups of functions (subsystems).
  • Service: Users accessing transactions on a 24x7 basis (a.k.a. user-to-business)
  • Collaboration: Users working with one another to share data and information (a.k.a. user-to-user)
  • Information Aggregation: Data from multiple sources aggregated and presented across multiple channels (a.k.a. user-to-data)
  • Extended Enterprise: Integrating data and processes across enterprise boundaries (a.k.a. business-to-business)

The right application pattern depends on the organizations 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


Tasks of an Application Architect

An Application Architect is a master of everything applications in an organization.

Understand Application Suite

An Application Architect provides strategic guidelines to the Application Maintenance teams by understanding all the applications from the following perspectives

  • Gartner Magic Quadrant
  • Interoperability capability
  • Performance and Scalability
  • Reliability and Availability
  • Application Lifecycle stage
  • Technological Risks
  • Number of instances

The above analysis will point out applications that need 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

Functionality Footprint

Understand the System Process Flow of the primary business processes. It gives a clear picture of the functionality map and the Application Footprint of various applications across the map.

Many organizations do not have documentation discipline and hence lack detailed business process floes and system process flows. One may have to start an initiative to put those in place first.

Create Solution Architecture Guidelines

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.

Summary

Application Architecture is the science and art of ensuring the suite of applications being used by an organization to create the composite application is scalable, reliable, available and manageable. One not only needs to understand and manage the dynamics of the functionalities the composite application 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.


Manishpk (talk) 23:06, 19 May 2008 (UTC)