Part 2 - The window seat
We come across the term ‘architecture’ in many situations. We have heard of application architecture, business architecture, cloud architecture, data architecture, enterprise architecture, fault tolerant architecture, hardware architecture, information architecture, knowledge architecture, network architecture, performance architecture, security architecture, software architecture, solution architecture, technical architecture, web architecture, and so on.
“The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. Architecture is concerned with the public side of interfaces; private details of elements—details having to do solely with internal implementation—are not architectural.”
Here is another definition by Grady Booch, Philippe Kruchten, Rich Reitman, and Kurt Bittner.
Software architecture encompasses the significant decisions about
- the organization of a software system,
- the selection of the structural elements and their interfaces by which the system is composed together with their behavior as specified in the collaboration among those elements,
- the composition of these elements into progressively larger subsystems, the architectural style that guides this organization, these elements and their interfaces, their collaborations, and their composition.
Which one have you worked with?
With this background, it worth discussing about software architects. Software architects come in different categories. There are software architects who limit their profession to architecture definition either by creating PowerPoint slide decks or short documents with block diagrams. There are software architects who leave the team before the development starts. They appear for a short duration, play their role with authority and move on to other projects. They belong to the second category and treat architecture as relay sport. The third category is architects who play part-time role in multiple projects. Architects in this category are not accessible to team members. Architects in the fourth category are the so called glorified coders - they get the title because of their perseverance on getting the title! They are passionate but lack necessary skills. The fifth category of architect consists of ‘tech savvy’ managers who are terrible in project management. Probably they were given this title because of their technical knowledge. Architects in this category no longer design or code - they live with the premise that they are too busy to code. However they know multiple technologies and solutions. They can talk in meetings and voice their opinion.
The next category is the ‘had been there and done that’ architects. They are experts. They nurture architecture and design competency in teams. They believe in empowerment. They stay with the team and participate in engineering activities such as coding, deployment, performance testing, etc. They are valuable and they are rare to find.
The window seat
The dream of tech savvy software engineers is to become an architect. They have seen architects with authority and power. They want to be one and perform that role in style. They are lost in this dream. They fantasize on occupying the ‘window seat’ and want to move very fast in each and every step of their career from getting on board to moving closer to that seat. In this rush they miss the opportunity to write beautiful code and appreciate good designs. They want to become architects. Is that going to work? Is this what we expect?
How do you connect with this discussion? What is your point of view?
<<<< Part 1 Software Architecture and Design in Agile World - Part 3
No comments:
Post a Comment