|
|
Software Architecture Demystified
Posted On June 2, 2007 by Raja Kishore Reddy filed under Miscellaneous
Software development has evolved over time. Not long ago, software development seemed to be a straightforward process unlike most scenarios today. Software development has become increasingly more challenging as the complexity of business problems that it now tries to solve has also increased, along with technological changes taking place at a blistering pace. Some of the major changes that have taken place in software development are listed in the table below.
Table: The software development paradigm
Architecture has become an integral part of the software development process owing to the above paradigm shift in the software landscape.
The authors strive to describe what architecture is, where to concentrate, what it is not and what needs to be done to design architecture for software.
Introduction
Considering the points mentioned in the table, the success of any software in the present paradigm is best achieved by utilizing an architecture-centric development approach. Since there are so many different software development approaches, it would make sense to first address what software architecture is.
What is software architecture?
Often, in the context of software products or software development projects, the questions generally asked by various stakeholders are:
· Have you developed the software architecture?
· Where is the software architecture?
· Have you designed (means architecture) the software, etc?
Although software architecture is a well-defined discipline, many individuals within the Information Technology sector do not share the same views on this subject nor have the same understanding. In general, people take design as architecture and architecture as design. However, the maxim is “architecture is design but not all design is architecture”. Since architecture is about issues that have a high impact and broader scope, it provides a framework for designing the software. System requirements are implemented into one architecture and architecture can be implemented into multiple designs.
With respect to software development, software architecture branch is still under development (as compared with other disciplines). Much still needs to be done to be on par with other fields. It does not mean that software architecture is new; it has existed for many decades. There were a number of complex banking and stock market trading systems created on the mainframe over 20-30 years ago. The difference today is that there are many more technology choices and the systems today can address many more business problems.
Though software architecture discipline is a well-defined branch of software development, there is no industry accepted standard definition for software architecture. And at the same time, there is no shortage of definitions either (Definitions of software architecture are provided at http://www.sei.cmu.edu/architecture/definitions.html).
What is it and what it is not?
Architecture is a blueprint of the software solution to be built. It is a high-level solution abstraction, viewed as a whole as well as the partitioning of the whole into parts with specific relationships among them. As different stakeholders have different concerns, they try to understand the system as per their perspectives, which can be addressed by different architectural views, or models, of the software system.
Architecture is an abstract level of the problem statement with the Quality of Service (QoS) it requires to provide. Abstraction is generally based on the Critical Use Case (Use Cases which are important for the success of the software) and the QoS, required to be provided by the system. QoS includes all the non-functional requirements of the system, such as usability, performance, operational, availability, maintainability, security, etc.
Notable aspects of software architecture are that it provides a design plan (blueprint of a system) and it is an abstraction to help manage the complexity of a system. And it is architecture that makes a set of parts working together as a successful whole.
These parts can be derived based on the type of service/s the software must provide. Some of the typical software services, or layers, include user service, business service and data service. These services are generally classified according to the functionality.
Need for Architecture
It is quite important that for complex business problems an architectural blueprint is developed prior to committal of resources for full-scale development. Architecture provides a plan for how the system will be constructed. Noteworthy, every system has architecture – even if it was not developed. Communication of the software architecture to all stakeholders is essential at early stages of the software development life cycle to help with identification of any shortfalls or issues. Just having architecture is different from having architecture known to everyone.
Generally, issues found in later stages of the development life cycle are much more costly to address. Some of the reasons that necessitate architecture include:
- Requirement:
· Since architecture enhances understanding of the prerequisites, any requirement defects can be eliminated early in the project life cycle; and
· Architecture helps understand the system as a whole.
· Component Management:
· Organizing and providing direction for development;
· Identifying components of the software and how they interconnect with each other, thus separating complex things out; and
· Breaking big into small and manageable chunks and communication between them.
- Planning:
· It is a way of planning in advance before any effort to explore the different phases of software development life cycle is spent; and
· Understanding and capturing of all the facts early help in making better decisions.
- Communication:
· Communication tool among development team and stakeholders.
- Risk Management:
· Discovering risks early so that risks are reduced to a minimum;
· Anticipating any hindrances beforehand; and
· Mitigating risk before actual commitment of development.
- Quality:
· Maintaining the software quality.
· Estimation:
· Software architecture component decomposition helps in providing better estimates for software development life cycle.
Where to concentrate?
There are various factors that need to be taken into consideration while defining the software architecture (figure 1).
Once the software requirement specifications or problem statements take shape, they can be grouped into the following categories:
1. Impact:
· High Impact (High Priorities, Important for business); and
· Low Impact.
2. Scope:
· Broad Scope; and
· Narrow Scope.
Based on the above categories, an architect can concentrate on the area of “High Impact” and “Broad Scope” as this area will cover the major chunk of requirements as shown in figure 2.
Architecture should always be developed to focus those requirements that concentrate in the areas of both High Priorities and Broad Scope.
Architecture Issues
The main factors that impact the architecture of software are:
· Functional requirements are not well-defined or functional analysis has not been properly performed;
· Non-functional requirements are not defined/specified adequately. Non-functional requirements should be specific in nature, e.g. the response time should be three seconds, up-time should be 99.99%, etc.;
· System boundary (scope) is not defined before proceeding towards conceptualizing the software architecture; and
· If two or more factors are not balanced and have high influence, then they should be prioritized or balanced.
School of Thoughts
There are several major schools of thought that try to explain software architecture:
· Zachman Framework;
· 4+1 View Model; and
· RM-ODP.
The aim of all of these is the same, i.e. to provide a robust blueprint for the software. However, the approach for developing the blueprint varies (figure 3).
Furthermore, the terminology used to address software architecture approaches also vary greatly, thereby leading to more confusion among the users of these architectural frameworks or models.
Although there are differences between the various schools of thought, they are similar when it comes to how they communicate/define software architecture: Architecture Views. For example, Zachman Frameworks has 36 views while 4+1 View Model has only five (Use Case, Logical, Process, Development and Deployment) and some others have four views (Conceptual, Module, Execution, and Code). These approaches do not limit the views but rather encourage including other views as needed to emphasize certain critical aspects of the software architecture.
These views are arranged based on the importance given to different engineering problems and stakeholders. And these views are generally loosely coupled but not disjoint.
Conclusion
Architecture is a macro level planning based on requirements, taking critical Use Cases and the Quality of Services into consideration before committing resources in full for the development.
Architecture maximizes the probability of delivering a defined product on time within budget with the desired quality. However, it does not necessarily guarantee the successful development of the product.
Above all, stakeholders should understand that “No user is going to pay for a pretty picture, what user wants is the software that executes”.
References:
1. Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Robert Nord, Judith Stafford, “Documenting Software Architecture Views and Beyond”; Addison-Wesley
2. Raphael Malveau, Thomas J Mowbray “Software Architecture Bootcamp”; Pearson Education
3. Jim Conallen, “Building Web Applications with UML”; Pearson Education
4. Christine Hofmeister, Robert Nord, Dilip Soni, “Applied Software Architecture”; Addison-Wesley
5. Suzanne Robertson, James Robertson, “Mastering the Requirements Process”; Addision-Wesly
6. Ivar Jacobson, Grady Booch, James Rumbaugh, “The Unified Software Development Process”; Pearson Education
7. http://www.sei.cmu.edu/architecture/definitions.html
8. Ruth Malan and Dana Bredemeyer “Software Architecture: Central Concern, Key decisions”, white paper published on Resources for Software Architects web site, http://www.bredemeyer.com
The authors can be reached at sanjeevyadav@yahoo.com and rawat_anil@yahoo.com.