Software Architecture

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

Views

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:

• Blackboard
• 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
• Peer-to-peer
• Pipes and filters
• Plugin
• 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.

Enterprise 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

1. Business:
   1. Strategy maps, goals, corporate policies, Operating Model
   2. Functional decompositions (e.g. IDEF0, SADT), capabilities and organizational models
   3. Business processes
   4. Organization cycles, periods and timing
   5. Suppliers of hardware, software, and services
2. Information:
   1. Metadata – data that describes your enterprise data elements
   2. Data models: conceptual, logical, and physical
3. Applications:
   1. Application software inventories and diagrams
   2. Interfaces between applications – that is: events, messages and data flows
   3. Intranet, Extranet, Internet, eCommerce, EDI links with parties within and outside of the organization
4. Technology:
   1. Hardware, platforms, and hosting: servers, and where they are kept (know more about it at sites like tvit.net/hardware-procurement/)
   2. Local and wide area networks, Internet connectivity diagrams
   3. Operating System
   4. Infrastructure software: Application servers, DBMS
   5. Programming Languages, etc..

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:

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

References: http://en.wikipedia.org/wiki/Software_architecture