Wednesday, April 17, 2013

What is Software Architecture?

Today the architect in my team asked for my help in documenting the architecture of a new application. Since my experience of software architecture (or what I understood by that term) was so far restricted to participation in design discussions and creation of functional diagrams (System Overview) and technical diagrams (Database Design), I decided to understand what Software Architecture actually means. So I read some articles and blogs on the Web and noted down some of the interesting things they had to say (links embedded in this post, copyrights hereby acknowledged)

According to an article on MSDN, "Software application architecture is the process of defining a structured solution that meets all of the technical and operational requirements, while optimizing common quality attributes such as performance, security, and manageability. It involves a series of decisions based on a wide range of factors, and each of these decisions can have considerable impact on the quality, performance, maintainability, and overall success of the application."

In this definition of software architecture, Microsoft mentions both technical and operational requirements. But some authors, such as Patrick Kalkman in a Software Architecture Design article on CodeProject, aver that software architecture should focus on the non-functional requirements of the stakeholders, instead of being based on purely technical motives

An article on IBM developerWorks defines software architecture as per the IEEE Standard 1471-2000, the IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, commonly  referred to as IEEE 1471. Thus "Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution." [IEEE 1471]

As per the IBM article, the standard also defines the following terms related to this definition:
  • A system is a collection of components organized to accomplish a specific function or set of functions. The term system encompasses individual applications, systems in the traditional sense, subsystems, systems of systems, product lines, product families, whole enterprises, and other aggregations of interest. A system exists to fulfill one or more missions in its environment. [IEEE 1471]
  • The environment, or context, determines the setting and circumstances of developmental, operational, political, and other influences upon that system. [IEEE 1471]
  • A mission is a use or operation for which a system is intended by one or more stakeholders to meet some set of objectives. [IEEE 1471]
  • A stakeholder is an individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system. [IEEE 1471]

The IBM article further lists the core characteristics of software architecture as follows:
  • An architecture defines structure
  • An architecture defines behavior
  • An architecture focuses on significant elements
  • An architecture balances stakeholder needs
  • An architecture embodies decisions based on rationale
  • An architecture may conform to an architectural style
  • An architecture is influenced by its environment
  • An architecture influences team structure
  • An architecture is present in every system
  • An architecture has a particular scope

Finally, going back to the first line of this post, you may want to ask if the "architect" in my team is really one, or just a senior software developer who is more involved than other team members in the design process. An article by Simon Brown offers the answer to this question.

No comments:

Post a Comment