Application Architecture - Revision history

User at 17:38, 7 March 2024

2024-03-07T17:38:55Z

User at 19:26, 21 November 2022

2022-11-21T19:26:03Z

User at 15:28, 21 November 2022

2022-11-21T15:28:43Z

User at 15:25, 21 November 2022

2022-11-21T15:25:51Z

User at 15:21, 21 November 2022

2022-11-21T15:21:33Z

Show changes

User at 14:12, 27 September 2022

2022-09-27T14:12:48Z

User at 12:53, 8 September 2022

2022-09-08T12:53:10Z

User at 19:54, 15 June 2022

2022-06-15T19:54:38Z

User: The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

2021-02-06T13:44:22Z

The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

Show changes

User at 16:02, 29 May 2020

2020-05-29T16:02:21Z

← Older revision		Revision as of 17:38, 7 March 2024
Line 72:		Line 72:
	Several common patterns represent application deployment structures found in most solutions. When it comes to determining the best deployment solution for your application, it helps to first identify the common patterns. Once you have a good understanding of the different patterns, you then consider scenarios, requirements, and security constraints to choose the most appropriate pattern.		Several common patterns represent application deployment structures found in most solutions. When it comes to determining the best deployment solution for your application, it helps to first identify the common patterns. Once you have a good understanding of the different patterns, you then consider scenarios, requirements, and security constraints to choose the most appropriate pattern.

−	*Client-Server Deployment: This pattern represents a basic structure with two main components: a client and a server. In this scenario, the client and server will usually be located on two separate tiers. Figure 3 represents a common Web application scenario where the client interacts with a Web server. Consider the client/server pattern if you are developing a client that will access an application server or a stand-alone client that will access a separate database server.	+	*[[Client Server Architecture\|Client-Server Deployment]]: This pattern represents a basic structure with two main components: a client and a server. In this scenario, the client and server will usually be located on two separate tiers. Figure 3 represents a common Web application scenario where the client interacts with a Web server. Consider the client/server pattern if you are developing a client that will access an application server or a stand-alone client that will access a separate database server.

← Older revision		Revision as of 19:26, 21 November 2022
Line 169:		Line 169:
	*Functionality footprint: 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.		*Functionality footprint: 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.

−	*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.	+	*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.

@@ Line 1: / Line 1: @@
 == Definition of Application Architecture<ref>[https://www.orbussoftware.com/application-architecture/what-is-application-architecture/ Defining Application Architecture]</ref> ==
-'''Application Architecture''' is the process of defining the framework of an organization’s application solutions against business requirements. It involves the definition of the application landscape, aiming to optimize this landscape against the ideal blueprint. The Open Group’s architectural framework, TOGAF, defines the objective of application architecture as “defining the major kinds of application systems necessary to process the data and support the business”.<ref>[https://www.orbussoftware.com/application-architecture/what-is-application-architecture/ Defining Application Architecture]</ref>
+'''Application Architecture''' is the process of defining the framework of an organization’s application solutions against business requirements. It involves the definition of the application landscape, aiming to optimize this landscape against the ideal blueprint. The Open Group’s architectural framework, TOGAF, defines the objective of application architecture as “defining the major kinds of application systems necessary to process the data and support the business”.
@@ Line 49: / Line 49: @@
-== Application Architecture - Physical Tiers and Deployment<ref>Physical Tiers and Deployment of Application Architecture [https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ee658120%28v%3dpandp.10%29 Microsoft]</ref> ==
+== Application Architecture - Physical Tiers and Deployment<ref>[https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ee658120%28v%3dpandp.10%29 Physical Tiers and Deployment of Application Architecture]</ref> ==
 Application architecture designs exist as models, documents, and scenarios. However, applications must be deployed into a physical environment where infrastructure limitations may negate some of the architectural decisions. By considering the possible deployment scenarios for your application as part of the design process, you prevent a situation where the application cannot be deployed successfully, or fails to perform to its design requirements because of technical infrastructure limitations. Choosing a deployment strategy requires design tradeoffs. For example, there might be protocol or port restrictions, or specific deployment topologies not supported in your target environment. When creating your deployment strategy, first determine if you will use a distributed or a non-distributed deployment model. If you are building a simple intranet application for your organization, which will be accessed by a finite set of users, consider nondistributed deployment. If you are building a more complex application, which you must optimize for scalability and maintainability, consider a distributed deployment.
@@ Line 102: / Line 102: @@
-== Application Architecture Archetypes<ref>Application Architecture Archetypes [https://www.satter.org/2008/01/microsoft-mobil.html Satter]</ref> ==
+== Application Architecture Archetypes<ref>[https://www.satter.org/2008/01/microsoft-mobil.html Application Architecture Archetypes]</ref> ==
 Application architecture whether it is for mobile, server, or desktop applications can be broken into 3 major archetypes - standalone, connected, and occasionally connected.
-*Standalone Applications: Standalone applications are exactly an application that can run on the device without any other requirements or resources. The classic example would be a "Hello World" application. In the early days of network technology to enable this standalone application access to network resources, OS developers made network resources look local. So early versions of Microsoft Word could save to the network because the shared network location looked like a local drive. So while Word at that point is technically no longer standalone, it is not exactly network or connected aware. With the .Net and Compact Framework, you can build standalone applications. These applications can be as simple or complex as you like.
+*Stand alone Applications: Standalone applications are exactly an application that can run on the device without any other requirements or resources. The classic example would be a "Hello World" application. In the early days of network technology to enable this standalone application access to network resources, OS developers made network resources look local. So early versions of Microsoft Word could save to the network because the shared network location looked like a local drive. So while Word at that point is technically no longer standalone, it is not exactly network or connected aware. With the .Net and Compact Framework, you can build standalone applications. These applications can be as simple or complex as you like.
 **The benefit
 ***Can run anywhere and anytime by its user as long as the device can operate.
@@ Line 149: / Line 149: @@
-== Application Architect<ref>Application Architect [https://en.wikipedia.org/wiki/Applications_architecture Wikipedia] ==
+== Application Architect<ref>[https://en.wikipedia.org/wiki/Applications_architecture Application Architect] ==
 The Application architect is a lead or technical manager in the computer programming team who is specialized in the application built and the technologies used.

@@ Line 1: / Line 1: @@
-== Definition of Application Architecture<ref>Defining Application Architecture [https://www.orbussoftware.com/application-architecture/what-is-application-architecture/ Obus Software]</ref> ==
+== Definition of Application Architecture<ref>[https://www.orbussoftware.com/application-architecture/what-is-application-architecture/ Defining Application Architecture]</ref> ==
 '''Application Architecture''' is the process of defining the framework of an organization’s application solutions against business requirements. It involves the definition of the application landscape, aiming to optimize this landscape against the ideal blueprint. The Open Group’s architectural framework, TOGAF, defines the objective of application architecture as “defining the major kinds of application systems necessary to process the data and support the business”.<ref>[https://www.orbussoftware.com/application-architecture/what-is-application-architecture/ Defining Application Architecture]</ref>
-== Application Architecture Layers<ref>Layers of Application Architecture [http://www.guidanceshare.com/wiki/Application_Architecture_Guide_-_Chapter_9_-_Layers_and_Tiers Guidance Share]</ref> ==
+== Application Architecture Layers<ref>[http://www.guidanceshare.com/wiki/Application_Architecture_Guide_-_Chapter_9_-_Layers_and_Tiers Layers of Application Architecture]</ref> ==
 Layers are the logical groupings of the software components that make up the application or service. They help to differentiate between the different kinds of tasks performed by the components, making it easier to create a design that supports the reusability of components. Each logical layer contains a number of discrete component types grouped into sublayers, with each sublayer performing a specific type of task. By identifying the generic types of components that exist in most solutions, you can construct a meaningful map of an application or service, and then use this map as a blueprint for your design. Splitting an application into separate layers that have distinct roles and functionalities helps you to maximize the maintainability of the code, optimize the way that the application works when deployed in different ways, and provide a clear delineation between locations where certain technology or design decisions must be made. At the highest and most abstract level, the logical architecture view of any system can be considered to be a set of cooperating services grouped into the following layers, as shown in Figure 1. below.
@@ Line 52: / Line 52: @@
 Application architecture designs exist as models, documents, and scenarios. However, applications must be deployed into a physical environment where infrastructure limitations may negate some of the architectural decisions. By considering the possible deployment scenarios for your application as part of the design process, you prevent a situation where the application cannot be deployed successfully, or fails to perform to its design requirements because of technical infrastructure limitations. Choosing a deployment strategy requires design tradeoffs. For example, there might be protocol or port restrictions, or specific deployment topologies not supported in your target environment. When creating your deployment strategy, first determine if you will use a distributed or a non-distributed deployment model. If you are building a simple intranet application for your organization, which will be accessed by a finite set of users, consider nondistributed deployment. If you are building a more complex application, which you must optimize for scalability and maintainability, consider a distributed deployment.
-*Nondistributed Deployment
+*Nondistributed Deployment: In a nondistributed deployment, all of the functionality and layers reside on a single server except for data storage functionality, as shown in the example in Figure 3.
 [[File:Application_Architecture_Non-Distributed_Deployment.png|300px|Application Architecture Non-Distributed Deployment]]<br />
@@ Line 60: / Line 59: @@
 This approach has the advantage of simplicity and minimizes the number of physical servers required. It also minimizes the performance impact inherent when communication between layers must cross physical boundaries between servers or server clusters. Keep in mind that by using a single server, even though you minimize communication performance overhead, you can hamper performance in other ways. Because all of your layers share resources, one layer can negatively affect all of the other layers when it is under heavy utilization. In addition, the servers must be generically configured and designed around the strictest of operational requirements and must support the peak usage of the largest consumers of system resources. The use of a single tier reduces your overall scalability and maintainability because all the layers share the same physical hardware.
-*Distributed Deployment
+*Distributed Deployment: In a distributed deployment, the layers of the application reside on separate physical tiers. Tiered distribution organizes the system infrastructure into a set of physical tiers to provide specific server environments optimized for specific operational requirements and system resource usage. It allows you to separate the layers of an application on different physical tiers, as shown in the example in Figure 4.
@@ Line 112: / Line 110: @@
 ***The application can be written with little regard to its environment i.e. it can assume that it is the only thing running, and does not need to manage fragile network connections.
 ***Rich user interface.
-***Overtime the application can approach near zero defect since the application is self-contained. In addition, the most probable source of error is a combination of user input or a sequence of interactions that developers had not been foreseen.
+*** Over time the application can approach near zero defect since the application is self-contained. In addition, the most probable source of error is a combination of user input or a sequence of interactions that developers had not been foreseen.
 **The negatives
 *** Self contained the user has limited interaction with network resources. A good example is Car Navigation systems. To update the map or show newer locations require an update of its map which can be complex for example my wife's navigation is about 6 years out of date and requires the dealer to replace the DVD since it is not easily accessible. This typically means that data is stale to some degree.
@@ Line 161: / Line 159: @@
 *Tasks: 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:
-**[[Interoperability]] capability
+**Interoperability capability
 **Performance and scalability
 **Reliability and availability

@@ Line 1: / Line 1: @@
 == Definition of Application Architecture<ref>Defining Application Architecture [https://www.orbussoftware.com/application-architecture/what-is-application-architecture/ Obus Software]</ref> ==
-'''Application Architecture''' is the process of defining the framework of an organization’s application solutions against [[Business Requirements|business requirements]]. It involves the definition of the application landscape, aiming to optimize this landscape against the ideal [[Blueprint|blueprint]]. The Open Group’s architectural framework, [[The Open Group Architecture Framework (TOGAF)|TOGAF]], defines the [[objective]] of application architecture as “defining the major kinds of application systems necessary to process the [[Data|data]] and support the [[Business|business]]”.<ref>Defining Application Architecture [https://www.orbussoftware.com/application-architecture/what-is-application-architecture/ Obus Software]</ref>
+'''Application Architecture''' is the process of defining the framework of an organization’s application solutions against [[Business Requirements|business requirements]]. It involves the definition of the application landscape, aiming to optimize this landscape against the ideal [[Blueprint|blueprint]]. The Open Group’s architectural framework, [[The Open Group Architecture Framework (TOGAF)|TOGAF]], defines the [[objective]] of application [[Architecture|architecture]] as “defining the major kinds of application systems necessary to process the [[Data|data]] and support the [[Business|business]]”.<ref>Defining Application Architecture [https://www.orbussoftware.com/application-architecture/what-is-application-architecture/ Obus Software]</ref>
 __TOC__

@@ Line 155: / Line 155: @@
 **Application modeling: Employs modeling as a framework for the development of new or enhanced applications, uses modeling to find problems, reduce [[risk]], improve predictability, reduce cost and time-to-[[market]], tests various [[product]] scenarios, incorporating clients' needs/requirements, adds test design decisions to the development process as necessary, evaluates product design problems.
 **Competitive intelligence, business modeling, strategic analysis: Understanding of the global marketplace, consumers, industries and competition, and how global business models, strategies, finances, operations and structures interrelate. Understanding of the competitive environment, including current trend in the market, [[industry]], competition and regulatory environment, as well as understanding of how the components of business model (i.e. strategy, finances, operations) interrelate to make organization competitive in the marketplace. Understanding of organization's business processes, systems, tools, regulations and structure and how they interrelate to provide products and services that create [[value]] for customers, consumers and key stakeholders. Understanding of how the value create for customers, consumers and key stakeholders aligns with organization's [[vision]], business, culture, value proposition, [[brand]] promise and strategic imperatives. Understanding of organization's past and present achievements and shortcomings to assess strengths, weaknesses, opportunities and risks in relation to the competitive environment.
-**Technology: Understanding of [[IT strategy]], development lifecycle and application/infrastructure maintenance; Understanding of IT service and support processes to promote competitive advantage, create efficiencies and add value to the business.
+**Technology: Understanding of [[IT Strategy (Information Technology Strategy)|IT Strategy]], development lifecycle and application/infrastructure maintenance; Understanding of IT service and support processes to promote competitive advantage, create efficiencies and add value to the business.
 **Technology standards: Demonstrates a thorough understanding of the key technologies which form the infrastructure necessary to effectively support existing and future business requirements, ensures that all hardware and software comply with [[baseline]] requirements and standards before being integrated into the business environment, understands and is able to develop technical standards and procedures to facilitate the use of new technologies, develops useful guidelines for using and applying new technologies.

← Older revision		Revision as of 16:02, 29 May 2020
Line 1:		Line 1:
	== Definition of Application Architecture<ref>Defining Application Architecture [https://www.orbussoftware.com/application-architecture/what-is-application-architecture/ Obus Software]</ref> ==		== Definition of Application Architecture<ref>Defining Application Architecture [https://www.orbussoftware.com/application-architecture/what-is-application-architecture/ Obus Software]</ref> ==
	'''Application Architecture''' is the process of defining the framework of an [[Organization\|organization’s]] application solutions against [[Business Requirements\|business requirements]]. It involves the definition of the application landscape, aiming to optimize this landscape against the ideal [[Blueprint\|blueprint]]. The Open Group’s architectural framework, [[The Open Group Architecture Framework (TOGAF)\|TOGAF]], defines the objective of application architecture as “defining the major kinds of application systems necessary to process the [[Data\|data]] and support the [[Business\|business]]”.<ref>Defining Application Architecture [https://www.orbussoftware.com/application-architecture/what-is-application-architecture/ Obus Software]</ref>		'''Application Architecture''' is the process of defining the framework of an [[Organization\|organization’s]] application solutions against [[Business Requirements\|business requirements]]. It involves the definition of the application landscape, aiming to optimize this landscape against the ideal [[Blueprint\|blueprint]]. The Open Group’s architectural framework, [[The Open Group Architecture Framework (TOGAF)\|TOGAF]], defines the objective of application architecture as “defining the major kinds of application systems necessary to process the [[Data\|data]] and support the [[Business\|business]]”.<ref>Defining Application Architecture [https://www.orbussoftware.com/application-architecture/what-is-application-architecture/ Obus Software]</ref>
		+
		+	__TOC__