Technical architecture

Technical architecture is one of several architecture domains that form the pillars of an enterprise architecture or solution architecture. It describes the structure and behaviour of the technology infrastructure of an enterprise, solution or system. It covers the client and server nodes of the hardware configuration, the infrastructure applications that run on them, the infrastructure services they offer to applications, the protocols and networks that connect applications and nodes. It addresses issues such as performance and resilience, storage and backup.

Alternatively, technical architecture is a synonym of system architecture, or is the process for defining one, with a focus on the users' and sponsors' view of the system.

Alternatively, technical architecture is considered part of software architecture. The remainder of this entry takes this last view point.

Introduction

Technical architecture is a part of software architecture, which focuses on how to deal with certain aspects of the software engineering process. It allows us to design better systems by:
*Meeting system requirements and objectives: Both functional and non-functional requirements can be prioritized as "must have", "should have" or "want", where "must have" identifies properties that the system must have in order to be acceptable. An architecture allows us to evaluate and make tradeoffs among requirements of differing priority. Though system qualities (also known as non-functional requirements) can be compromised later in the development process, many will not be met if not explicitly taken into account at the architectural level.
*Enabling flexible partitioning of the system: A good architecture enables flexible distribution of the system by allowing the system and its constituent applications to be partitioned among processors in many different ways without having to redesign the distributable component parts. This requires careful attention to the distribution potential of components early in the architectural design process.
*Reducing cost of maintenance and evolution: Architecture can help minimize the costs of maintaining and evolving a given system over its entire lifetime by anticipating the main kinds of changes that will occur in the system, ensuring that the system's overall design will facilitate such changes, and localizing as far as possible the effects of such changes on design documents, code, and other system work products. This can be achieved by the minimization and control of subsystem interdependencies.
*Increasing reuse and integration with legacy and third party software: An architecture may be designed to enable and facilitate the (re)use of certain existing components, frameworks, class libraries, legacy or third-party applications, etc..

teps

The following steps are defined in the discipline of technical architecture:
* Forming a team structure
* Create a skeletal system
* Exploit patterns in an architecture
* Ensure conformance to an architecture
* Building domain-specific languages

Processes

There are two important processes defined in technical architecture. These processes will be clarified in the underlying text.

Technical process

Technical Process is to be defined unambiguously. The main deliverable for a software architect is the architecture documentation, motivating and describing the structure of the system through various views. However, though system structuring forms a basis for the architectural design process, it is just one of several activities critical to the creation of a good architecture. In order to make such a deliverable to be able to instruct software developers, the following model can be used.

First architectural requirements are needed to focus the structuring activities. These requirements are then input to produce Architecture specifications. At the end, a validation phase provides early indicators and opportunities to resolve problems with the architecture. The model contains an iterative part, indicating that the Architecture validation can be input for new requirements.

Requirements

Architectural requirements are a subset of the system requirements, determined by architectural relevance. The business objectives for the system, and the architecture in particular, are important to ensure that the architecture is aligned with the business agenda. The system context helps determine what is in scope and what is out of scope, what the system interface is, and what factors impinge on the architecture. The system value proposition helps establish how the system will fit the users’ agenda and top-level, high-priority goals. These goals are translated into a set of use cases, which are used to document functional requirements. The system structure fails if it does not support the services or functionality that users value, or if the qualities associated with this functionality inhibit user performance or are otherwise unsatisfactory. System qualities that have architectural significance (e.g., performance and security, but not usability at the user interface level) are therefore also important in directing architectural choices during structuring.

Requirements may already have been collected by product teams. In that case, the architecture team needs to review those requirements for architectural relevance and completeness (especially with respect to non-functional requirements), and be concerned with requirements for future products that the architecture will need to support.

For the architecture of a product line or family, architectural requirements that are unique to each product and those that are common across the product set need to be distinguished so that the structure can be designed to support both the commonality and the uniqueness in each product.

pecification

The architecture is created and documented in the system structuring phase. This is decomposed into sub-phases, see therefore also the software architecture views:

Meta-Architecture

First, the architectural vision is formulated, to act as a beacon guiding decisions during the rest of system structuring. It is a good practice to explicitly allocate time for research in documented architectural styles, patterns, dominant designs and reference architectures, other architectures your organization, competitors, partners, or suppliers have created or you find documented in the literature, etc. Based on this study, and your and the team’s past experience, the meta-architecture is formulated. This includes the architectural style, concepts, mechanisms and principles that will guide the architecture team during the next steps of structuring.

Conceptual Architecture

The system is decomposed into components and the responsibilities of each component, and interconnections between components are identified. The intent of the conceptual architecture is to direct attention at an appropriate decomposition of the system without delving into the details of interface specification and type information. Moreover, it provides a useful vehicle for communicating the architecture to non-technical audiences, such as management, marketing, and many users.

Logical Architecture

The conceptual architecture forms the starting point for the logical architecture, and is likely to be modified as well as refined during the course of the creation of the logical architecture. Modeling the dynamic behavior of the system at the architectural level is a useful way to think through and refine the responsibilities and interfaces of the components. Component specifications including the following make the architecture concrete.
*A summary description of services the component provides
*The component owner’s name
*ID and version names
*Message signatures
*A description of the operations
*Constraints or pre-post conditions for each operation
*The concurrency model
*Constraints on component composition
*A lifecycle model
*How the component is instantiated
*How it is named
*A typical use scenario
*A programming example
*Exceptionsllll
*A test or performance suite

Execution Architecture

AN execution architecture is created for distributed or concurrent systems. It is formed by mapping the components onto the processes of the physical system. Different possible configurations are evaluated against requirements such as performance and scaling.

Architecture Tradeoff Analysis

At each step in structuring, it is worthwhile challenging the team’s creativity to expand the solution set under consideration, and then evaluating the different architecture alternatives against the prioritized architectural requirements. This is known as architecture tradeoff analysis, and it recognizes that different approaches yield differing degrees of fit to the requirements. Selection of the best solution generally involves some compromise, but it is best to make this explicit.

Validation

During structuring, the architects obviously make their best effort to meet the requirements on the architecture. The architecture validation phase involves additional people from outside the architectural design team to help provide an objective assessment of the architecture. In addition to enhancing confidence that the architecture will meet the demands placed on it, including the right participants in this phase can help create buy-in to the architecture. Architecture assessment involves "thought experiments", modeling and walking-through scenarios that exemplify requirements, as well as assessment by experts who look for gaps and weaknesses in the architecture based on their experience. Another important part of validation is the development of prototypes or proofs-of-concept. Taking a skeletal version of the architecture all the way through to implementation, for example, is a really good way to prove out aspects of the architecture.

Organization Process

Overview

Architecture projects are susceptible to three major organizational sources of failure:
*the project is under-resourced or cancelled by an uncommitted management
*the project is stalled with infighting or a lack of leadership
*the architecture is ignored or resisted by project managers.

The organizational process helps address these pitfalls. Two phases—namely Init/Commit and Deployment—bookend the technical process. However, the principal activities in these phases, namely championing the architecture and leading/teaming in Init/Commit, and consulting in Deployment, also overlap with the technical process activities.

Initiate

The Initiate phase focuses on initiating the architecture project on a sound footing, and gaining strong commitment from upper management. The creation of the architecture vision is central both to aligning the architecture team and gaining management sponsorship. A communication plan is also helpful in sensitizing the team to the need for frequent communication with others in the organization. A heads-down, hidden skunkworks architecture project may make quick progress—as long as it is well-led and its members act as a team. However, not listening to the needs of the management, developers, marketing, manufacturing and user communities and not paying attention to gaining and sustaining sponsorship in the management and technical leadership of the organization, or buy-in from the developer community, will lead to failure. The communication plan places attention on balancing the need for communication and isolation, as well as planning what to communicate when, and to whom.

Deployment

The Deployment phase follows the technical process, and addresses the needs of the developers who are meant to use the architecture to design and implement products. These range from understanding the architecture and its rationale, to responding to the need for changes to the architecture. This entails consulting, and perhaps tutorials and demos, as well as the architects' involvement in design reviews.

Championing

It is important that at least the senior architect and the architecture project manager (if there is one) champion the architecture and gain the support of all levels of management affected by the architecture. Championing the architecture starts early, and continues throughout the life of the architecture, though attention to championing tapers off as the architecture comes to be embraced by the management and developer communities.

Leading/Teaming

For the architecture team to be successful, there must be a leader and the team members must collaborate to bring their creativity and experience to bear on creating an architecture that will best serve the organization. This would seem so obvious as to not warrant being said, but unfortunately this is easier said than done. Explicit attention to developing the designated lead architect’s leadership skills, in the same way one would attend to developing these skills in management, is a worthy investment. Likewise, investing in activities aimed at developing the team as a team also has great payoff in the team’s efficacy.

Communicating and Consulting

Consulting with and assisting the developer community in their use of the architecture is important in facilitating its successful adoption and appropriate use. These activities are most intense during deployment. However, earlier communication and consulting helps create buy-in the developer community through participation and understanding. This allows the architecture team to understand the developers’ needs and the developers to understand the architecture (and its rationale) as it evolves through the cycles of the technical process.

ee also

* Technical architecture, the technical definition of an engineered system
** Systems architecture, the representation of an engineered system
** Computer architecture, the systems architecture of a computer
** Information architecture, the systems architecture for structuring the information flows in a knowledge-based system
** Software architecture, the systems architecture of a software system
** Hardware architecture, the systems architecture of a hardware system

*Computer programming
*Software component
*Software development process
*Software engineering
*Enterprise Architecture
*Enterprise Information Security Architecture
*Service-Oriented Modeling Framework (SOMF)

References

*Len Bass, Paul Clements, Rick Kazman, "Software Architecture in Practice", Addison Wesley, 1998 ISBN 0-201-19930-0

* Tony Shan and Winnie Hua (2006). [http://doi.ieeecomputersociety.org/10.1109/EDOC.2006.54 "Solution Architecting Mechanism"] . Proceedings of the 10th IEEE International EDOC Enterprise Computing Conference (EDOC 2006), October 2006, p23-32.

*Barbacci, M. R., S. J. Carriere, P. H. Feiler, R. Kazman, M. H. Klein, H. F. Lipson, T. A. Longstaff, and C. B. Weinstock, "Steps in an Architecture Tradeoff Analysis Method: Quality Attribute Models and Analysis"

*Ogush, M., D. Coleman, and D. Beringer, "A Template for Documenting Software Architectures", March 2000.

*Youngs, R., D. Redmond-Pyle, P. Spaas, and E. Kahan, "A Standard for Architecture Description", IBM Systems Journal, Vol 38 No 1. http://www.research.ibm.com/journal/sj/381/youngs.html