Software Architecture is considered to be one of the overused terminologies in our industry. Typically, any contemporary software project team, depending on its size, consists of a team of one or more architects that is responsible for providing a sound architecture for the proposed software system. Contemporary projects that involve cross-functional solutions based on multiple technologies, platforms and user groups require a dedicated team of architects in addition to a typical design team as compared to traditional projects. The characteristics of software architects and their role have evolved over a period of time.
Traditional waterfall approach comprises of Requirement Analysis, Design, Construction (Coding, Unit Testing), Documentation, and System Testing and this provides for an intensive design activity during the design phase. The term ‘Software Architecture’, though originated long ago, is being focused upon in the industry during the last couple of decades and this coincides with the evolution of new technologies (such as Web Technologies) and evolutionary methodologies (such as Rational Unified Process and Agile Software Development) in IT industry.
Architecture is a software engineering activity in software projects and a civil engineering activity in civil engineering projects. The myth about the term ‘Architect’ in both Software Engineering and Civil Engineering is that an architect is an individual who brings just a good amount of technical experience in the respective engineering discipline. Though this is the fundamental requirement, an architect needs more than the technical skills specific to the project he has been hired for. The definition of ‘Software Architecture’ would help us identify the desired characteristics of ‘Software Architects’ – the not-so-new but evolving breed of software professionals.
Software Architecture has been defined by various organizations and professionals and a definition that consolidates many such definitions is
“Software Architecture is based on strong architectural principles and guidelines. It provides the blue print of the proposed software system and such a blue print consists of all necessary views of the software system, its components, their interaction and addresses the requirements (both functional and non-functional). Besides, it exploits the available technology with a clear strategy in order to reduce the impact on existing systems in an enterprise, stands cost-effective and delights the stake holders.”
Thus, it is not enough if software architecture addresses the functional and non-functional requirements. The architecture itself has to be based on strong principles, guidelines and it must address the long-term requirements related to the structure of the software itself. The long-term requirements related to the structure of the software are derivable from the best case requirements, long-term focus of the IT organization, reuse considerations, technology preference, proposed budget, wish-lists and other up-coming technologies that could benefit the organization.
This makes it clear that all user requirements mapped into an excellent set of use cases is just one of the inputs to the architect to produce a sound architecture. An architect need not wait until all detailed requirements are documented and use cases are identified. The architect can start his activity with initial requirements, high-level use cases, based on a set of organizational standard (or project specific) architecture goals, principles (typically a set of Dos and Don’ts) and guidelines, keeping in mind the clear picture of the customer’s IT infrastructure, mission and vision. Unless the architecture is aligned to customer’s IT infrastructure, mission and vision, it would prove itself to be fruitless and evolve as a major risk for the project as well as the IT organization as a whole.
A software project, depending on its size, may require a team of one or more architects to accomplish this vital task of identifying, consolidating, documenting, reviewing, finalizing and maintaining the architecture of the software system through out the project’s lifecycle. Such a requirement essentially focuses on a professional who is not only broadly technical but also very good at soft skills especially in the areas of business communication, conflict resolution, self-expression, emotional intelligence, and team skills. Often, a highly respected technical professional in an organization fails to be a good architect because of his lack of soft skills in getting things done on time with a team of professionals. When a team of technical architects meets the project team to propose an architecture there could be conflicting issues and interests among the architecture team as well as the project management team as a whole. It is the architect who needs to posses strong skills in putting his architecture across by means of presentations or discussions. He has to be open-minded to encourage, understand and appreciate the suggestions or conflicting opinions. Meanwhile, he must be time-bound and decisive to make his team as well as his stakeholders understand the rational behind the proposed or renewed architecture. And he must carry the right level of self-esteem and feel proud of the final decision and exhibit ownership throughout the product life cycle.
In summary, software architects need to be experienced in various areas including core technologies, peripheral technologies, application development & implementation and variety of soft skills. Software architects need to hone their skills and build knowledge to research and understand emerging technologies, technology trends, client’s IT infrastructure, mission and vision. Finally, they need to have necessary expertise in identifying and using necessary software processes, tools and techniques to architect the software system, document the architecture with required granularity (with APIs and code samples), communicate it to the project team and be a mentor for the team to implement the system. With these qualities, this new breed of software professionals can definitely be identified and admired as visionaries for the software project and team they are working with!
Bibliography:
- A framework for information systems architecture – J.A.Zachman, IBM Systems Journal, Vol26, NO 3, 1987
- Extending and formalizing the framework for information systems architecture – J.F.Sowa, J.A.Zachman
- Architectural Blueprints – The “4+1” View Model of Software Architecture – Phillippe Kruchten, Rational Software Corp., 1995
- The Role of the Architect – Dana Bredemeyer and Ruth Malan, Bredemeyer Consulting
- Design Patterns – Elements of Reusable Object-Oriented Software – Eric Gamma, Richard Helm, Ralph Johnson, John Vlissides
- Software Architecture: a Roadmap – David Garlan, School of Computer Science, Carnegie Mellon University
- Functional Requirements and Use Cases – Ruth Malan and Dana Bredemeyer, Bredemeyer Consulting
- How Do You Define Software Architecture? (http://www.sei.cmu.edu/architecture/definitions.html)
