The description of a software architect varies significantly in the IT (Internet Technology) industry. You may hear a colleague introduce themselves with a title like systems architect, senior architect, or even chief architect and you wonder to yourself what does that title mean and do I want it?
You are not alone !!
Many business leaders, human resource departments, even technical management share this job title confusion. There are seldom commonalities in how different company's define the software architect's role let alone how software architects are actually utilized within those organizations.
We get so accustomed to the busyness and pandemonium of our daily work, trying to keep up to date with new or updated technologies or projects which are behind schedule that there is seldom a moment of downtime. We never have an opportunity to stop and think about what the role of a software architect should mean in the broad landscape of software development?
Most professions have distinct role definitions and/or education paths. For example an electrical engineer is different than an electrician, a structural architect is different than a builder, a medical assistant is different than a doctor.
Why is there so much confusion in the IT profession architecture role and responsibilities?
To answer this question you have to realize that we are the PIONEERS of this field of study!!! The IT profession is in it's infancy at only 50 years old. Computer science became a program of study around the year 1960. Electrical engineering, on the other hand, started in the 1880s and structural architecture was established circa 2100 BC.
The earliest of software architects would create detailed UML (Unified Modeling Language) diagrams including detailed class definitions. Typically these diagrams were passed to a development team for implementation. This process worked well for hardware or software that was manufactured or created and delivered on a CD, but changes would either require a new product or a new packaged delivery. The process was slow and methodical, typically following "waterfall-like" project methodologies.
In contrast, the onset of the internet allows for cheap delivery and quick updates to software including software that can be used in a web browser without the need for installation. Software can be developed and deployed so quickly that development teams can tackle small bug and feature releases simultaneously. Agile project methodologies paved the way for quick feedback cycles and smaller chunks of work. Creating concise UML diagrams was no longer necessary and nearly impossible to keep up to date with these small changes. Tools like Enterprise Architect by Sparx Systems were developed to automatically synchronize code and diagrams, but in most cases these types of diagrams were just not needed anymore.
So where does the software architect fit in now? Are architects still needed?
At the 2015 SATURN (Software Engineering Institute (SEI) Architecture Technology User Network Conference). Keynote speaker Gregor Hohpe stated "There is always an architecture; if you don't choose then one is assigned." He also mentioned that if you do not plan the architecture before embarking on the solution then the architecture you get will most likely not be the one you want.
Today we find that there is confusion about what differentiates an architect from a lead developer as the architect in many cases is either eliminated as a position or integrated with the development team as a lead developer. We have fallen into a pattern where most projects lack a plan (diagram) of the overall architecture that can be used to communicate choices in development. Developers many times focus only on the task(s) at hand (or in sprint) with little thought about how the task(s) fit into the big picture of what is being developed.
We still need software architects!! We just need to rediscover how the software architect fits into project teams and organizations.
While in the "agile" world the desire to create highly functional teams that are empowered to influence the project there is still a need to create a high level technical roadmap in order to communicate progress throughout our project teams. Without it we run the risk of creating a reputation of recommending work or technologies that executives may not fully understand. In those cases teams get pushback because to them it sounds like it might be work that is not necessary.
We need our software architects integrated with the development team where they can evaluate and adjust to changes in business concerns throughout the process. The architect should be involved early in the process to put together a few meaningful (high level) diagrams which can be used for communication both to management teams as well as development teams.
The size of the project, team, and organization all play factors in how the architecture will be created and maintained. Large organizations are starting to restructure to utilize architecture practices that keep a cohesive technical vision for the company which is then used to advise and unify development teams. Small businesses or projects might not have the capacity to create a separate architecture group so the team may include an architect or conduct mindful architecture sessions throughout the development cycle to create and maintain the architecture.
Traits of a Good Architect
Due to the fact that most architecture roles do not presently have college programs and tools (like CAD for structural architects) we must utilize individuals who have deep experiences and expertise with software development such as the following:
Experienced in Computer Programming - A good architect has been through the good and bad implementations and can use this information to plan out decisions based on experience.
Possess an Analytical Nature - A good architect never stops learning. Technology advances so quickly that in order for an architect to be effective they must keep up with the possibilities.
A Good Communicator - Architects generally need to be able to communicate with both technical and non-technical individuals both verbally and visually through diagrams.
Good at Estimation - Architects should be able to scope out and estimate a project typically before implementation has started.
Both a Leader & a Team player - Most of the planning is done up front. An architect needs to be able to allow the team to influence the choices during implementation and be decisive at times.
Technical Facilitator - During the implementation of a project an architect must remain involved and typically will facilitate communication between the development team, project management, and product owners so that everyone can understand the state of the project.
Publications & Research
To truly advance the profession of software architecture we need to find ways to convey both successful and ineffective solutions for the common problems we solve.
Currently there are hundreds if not thousands of projects in progress who are re-creating solutions that have been successful on other projects, perhaps even experiencing the same failed ideas along the way. If we spend our time re-doing the same work over and over rather than sharing our efforts we will advance very slowly indeed.
At this point you may ask "What can I do about it?" and I say to you ...
- Start blogging,
- Start mentoring,
- Share your knowledge however possible.
Publish articles or share patterns if you are not able to publish proprietary code.
References:
Top comments (0)