What is Technical Architecture?

Technical Architecture is one of those concepts that can be difficult to define, primarily because it is a recursive and multi-faceted concept. It is recursive because architecture is an abstraction of a system which shows its structure; well designed complex systems are composed of subsystems, which may further be composed of subsystems. At each level of detail, there can be an architecture or a micro-architecture. It is multi-faceted because an architecture highlights those aspects of a design which are significant to a high level understanding of the system structure. The significance of these details depends on the viewpoint of the observer. In other words, systems people trying to understand the application may be more interested in what hardware the system runs on, and what the network topology looks like. Application people would be more interested in how the code is structured. A comprehensive technical architecture will be an intersection of all these views and allow its exploration at various levels of detail. Physical Hardware Operating Systems Network Topology Middleware DBMS Logical System Architecture Subsystem Partitioning Subsystem Interfaces Layering (Presentation, Business Services, Persistence, etc...) Common Services

How is Architecture different from Design?

In some ways they are synonymous. Design is a general term which means the description of how something works. Architecture is a description of a design, highlighting how the details fit together. Much like a design pattern, identifying how a particular design fits into an architecture is a good way to communicate the salient points of a design, its pros and cons, as well as its general fit for the problem it is attempting to solve. A good architecture will lend itself to a quick identification via familiar patterns, e.g. client-server, pipes and filters, model view controller, N-tier. All these words quickly evoke an understanding of the system for an experienced architect.

Finding a good architect

An architect is the hub of the development project. Therefore he or she needs to be skilled in the diverse disciplines of the development cycle. Business Requirements - the architect needs to understand which requirements drive out the architecture. Like most things, 20 percent of requirements can drive 80 percent of an architecture. Likewise these requirements need to be correlated to the technical risks when fleshing out an architecture Project Planning - these days everyone is bashing the waterfall lifecycle. However, when it comes to designing a project plan, many project managers don't know how to effectively plan an iterative project. An architect needs to provide critical input to ensure that the architecture drives the project plan. Development - an architect needs to be intimately familiar with the technologies used on the project. This means hands on involvement in code and database, and systems issues. Ultimately, what you need in an architect is someone who understands balance. The ancient Greeks had it right with the Golden Mean. An architect needs to mediate between all the parties on the project pulling in different directions. An architect needs to know when to compromise and when to hold their ground. Finally, an architect needs to take responsibility for the whole system.