The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them.
The term also refers to documentation of a system’s software architecture. Documenting software architecture facilitates communication between stakeholders, documents early decisions about high-level design, and allows reuse of design components and patterns between projects
Software architecture is commonly organized in views, which are analogous to the different types of blueprints made in building architecture. Within the ontology established by ANSI/IEEE 1471-2000, views are instances of viewpoints, where a viewpoint exists to describe the architecture in question from the perspective of a given set of stakeholders and their concerns.
Some possible views (actually, viewpoints in the 1471 ontology) are:
- Functional/logic view
- Code/module view
- Development/structural view
- Concurrency/process/thread view
- Physical/deployment view
- User action/feedback view
- Data view
Examples of Architectural Styles / Patterns
There are many common ways of designing computer software modules and their communications, among them:
- Client-server (2-tier, n-tier, peer-to-peer, Cloud Computing all use this model)
- Database-centric architecture (broad division can be made for programs which have database at its center and applications which do’t have to rely on databases, E.g. desktop application programs, utility programs etc.)
- Distributed computing
- Event Driven Architecture
- Front-end and back-end
- Implicit invocation
- Monolithic application
- Pipes and filters
- Representational State Transfer
- Rule evaluation
- Search-oriented architecture (A pure SOA implements a service for every data access point)
- Service-oriented architecture
- Shared nothing architecture
- Software componentry (strictly module-based, usually object-oriented programming within modules, slightly less monolithic)
- Space based architecture
- Structured (module-based but usually monolithic within modules)
- Three-tier model (An architecture with Presentation, Business Logic and Database tiers)
Different type of architectures
Activities such as software architecture, network architecture, database architecture may be seen as partial contributions to a solution architecture.
The term enterprise architecture refers to many things. Like architecture in general, it can refer to a description, a process or a profession.
To some, "enterprise architecture" refers either to the structure of a business, or the documents and diagrams that describe that structure. To others, "enterprise architecture" refers to the business methods that seek to understand and document that structure. A third use of "enterprise architecture" is a reference to a business team that uses EA methods to produce architectural descriptions of the structure of an enterprise.
A formal definition of the structure of an enterprise comes from the MIT Center for Information Systems Research:
Enterprise Architecture is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s operating model.
Enterprise Architecture describes enterprise applications and systems with their relationships to enterprise business goals.
Another comprehensive definition of enterprise architecture is provided by the IFEAD (Institute for Enterprise Architecture Developments) as:
Enterprise Architecture is a complete expression of the enterprise; a master plan which “acts as a collaboration force” between aspects of business planning such as goals, visions, strategies and governance principles; aspects of business operations such as business terms, organization structures, processes and data; aspects of automation such as information systems and databases; and the enabling technological infrastructure of the business such as computers, operating systems and networks.
Many enterprise architecture frameworks break down the practice of developing artifacts into four practice areas. This allows the enterprise to be described from four important viewpoints. By taking this approach, enterprise architects can assure their business stakeholders that they have provided sufficient information for effective decision making.
Enterprise Architecture Areas of Practice
These practice areas are
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:
- Documentation describing the structure and behaviour of a solution to a problem, or
- A process for describing a solution and the work to deliver it.
The documentation is typically divided into a broad views, each known as an architecture domain.
Solution architecture is related to enterprise architecture. The solution described may be all or part of what an enterprise architect’s migration plan delivers. The solution might be unrelated to any such plan. Solution architecture often leads to software architecture work and technical architecture work, and often contains elements of those.
A Solutions Architect is often but not always focused on technical architecture and the meeting of non-functional requirements, often in the context of deploying specific applications.