What is Architecture?

Architecture serves as the blueprint for both the system and the project developing it, defining the work assignments that must be carried out by design and implementation teams. The architecture is the primary carrier of system qualities, such as performance, modifiability, and security, none of which can be achieved without a unifying architectural vision. Architecture is an artifact for early analysis to make sure that the design approach will yield an acceptable system. In short, architecture is the conceptual glue that holds every phase of the project together for all its many stakeholders.

Software Architecture Software application architecture is the process of defining a structured solution that meets all of the technical and operational requirements, while optimizing common quality attributes such as performance, security, and manageability.
The risks exposed by poor architecture include software that is unstable, is unable to support existing or future business requirements, or is difficult to deploy or manage in a production environment.

Systems should be designed with consideration for the user, the system (the IT infrastructure), and the business goals. For each of these areas, you should outline key scenarios and identify important quality attributes (for example, reliability or scalability) and key areas of satisfaction and dissatisfaction. Where possible, develop and consider metrics that measure success in each of these areas.

Tradeoffs are likely, and a balance must often be found between competing requirements across these three areas. For example, the overall user experience of the solution is very often a function of the business and the IT infrastructure, and changes in one or the other can significantly affect the resulting user experience. Similarly, changes in the user experience requirements can have significant impact on the business and IT infrastructure requirements. Performance might be a major user and business goal, but the system administrator may not be able to invest in the hardware required to meet that goal 100 percent of the time. A balance point might be to meet the goal only 80 percent of the time.

Architecture focuses on how the major elements and components within an application are used by, or interact with, other major elements and components within the application.
An architect must consider the overall effect of design decisions, the inherent tradeoffs between quality attributes (such as performance and security), and the tradeoffs required to address user, system, and business requirements.

Keep in mind that the architecture should:

Expose the structure of the system but hide the implementation details. Realize all of the use cases and scenarios. Try to address the requirements of various stakeholders. Handle both functional and quality requirements.

Architectural Style is set of principles that shape an application.

Architecture style
Client/Server

Description
Segregates the system into two applications, where the client makes requests to the server. In many cases, the server is a database with application logic represented as stored procedures.

Component-Based Architecture

Decomposes application design into reusable functional or logical components that expose well-defined communication interfaces.

Domain Driven Design An object-oriented architectural style focused on modeling a business domain and defining business objects based on entities within the business domain. N-Tier / 3-Tier Segregates functionality into separate segments in much the same way as the layered style, but with each segment being a tier located on a physically separate computer. Service-Oriented Architecture (SOA) Refers to applications that expose and consume functionality as a service using contracts and messages.

A loosely-coupled architecture designed to meet the business needs of the organization.

A SOA does not necessarily require the use of Web Services Web Services are, for most organizations, the simplest approach for implementing a loosely coupled architecture.

one organizations SOA may look like nothing more than a bunch of Web Services the key promise of SOA is to enable agile business processes via open, standards-based interoperability. While these standards are important we must remember that standards are not architecture and architectures are not implementations. At the end of the day it is the implementation of a well-designed architecture that will generate business benefits, not the architecture itself. SOA is an architectural approach to creating systems built from autonomous services. With SOA, integration becomes forethought rather than afterthought - the end solution is likely to be composed of services developed in different programming languages, hosted on disparate platforms with a variety of security models and business processes
http://www.soatutorial.net/soa-test-approach-the-purpose-and-how-to-do-it/

Testing activities such as design, analysis, planning and execution must happen throughout the entire SOA project life cycle.