Technical architecture - AbsoluteAstronomy.com

Technical architecture is one of several architecture domain

Architecture domain

An architecture domain in enterprise architecture is a broad view of an enterprise or system. It is a partial representation of a whole system that addresses several concerns of several stakeholders...

s that form the pillars of an enterprise architecture

Enterprise architecture

An enterprise architecture is a rigorous description of the structure of an enterprise, which comprises enterprise components , the externally visible properties of those components, and the relationships between them...

or solution architecture

Solution architecture

Solution architecture in enterprise architecture is a kind of architecture domain, that aims to address specific problems and requirements, usually through the design of specific information systems or applications.Solution architecture is either:...

. 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.

Although technical architecture is sometimes used as a synonym of system architecture, they are actually different architecture domains. While system architecture, applied specifically within the context of information systems, encompasses both the application architecture and data assets, and their logical interrelations to the business processes they support; the technical architecture describes in detail the software and hardware capabilities to fully enable such application and data services.

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..

Steps

The following steps may be involved 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.

Specification

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, and on what the system does or will do, without delving into how it does it (such as 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 case scenario
A programming example
Exceptions
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. Some systems may require a horizontal prototype to showcase the range of functions, while others need the clarification that a vertical prototype can bring.

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

Skunkworks project

A skunkworks project is one typically developed by a small and loosely structured group of people who research and develop a project primarily for the sake of radical innovation. The term typically refers to technology projects, and originated with Skunk Works, an official alias for the Lockheed...

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 from 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.