You may have never heard of a software architect, that is ok, no one in our industry can decide on any job titles. What is the difference between a Coder, Programmer, Software Engineer, Software Developer, Front End Developer, Web Developer or Full Stack Developer? Depending on the position requirements and company culture all of these job titles might have the same job duties but be labeled differently at different companies.
Same with Software Architects.
Wikipedia defines a Software Architect as:
A software architect is a software expert who makes high-level design choices and dictates technical standards, including software coding standards, tools, and platforms.
~Wikipedia
They use the term as a broad umbrella and define different types of IT or Software Architects within the same article: enterprise architect, application architect, solution architect, system architect, cloud architect.
Unfortunately most of the difference in the job titles and what these positions actually do ARE ONLY OF A CONCERN FOR PEOPLE IN THE INDUSTRY.
In other words, jargon for people who care about jargon. Just another way to exclude others from understanding your field.
Why Should We Care?
We shouldn’t care about the labels, we should care about what the role ideally does within your team (even if it is a team of one, it is still a hat you wear when creating a software project).
The problem is that most decision makers within small enterprise still think of software teams as being comprised of four roles: designer, developer, project manager and systems administrator. Oftentimes the “Team” is one person and they wear all these hats. Just because you have fewer resources, doesn’t mean the roles magically go away.
Understanding how the smaller the team is, the more roles each individual must take on is key to avoiding a major project pitfall: decisions by inaction. This concept is really a longer topic for another time. Back to the why…
I want to change the way you think about who is creating your software.
If you even think about your project team as having more than one role you are probably still missing what I consider a key component and concept of software development: the Software Architect. When this concept is clear to you, you will be able to make better, clearer decisions; without understanding it you are spinning your wheels and might not even know it until too late.
Why is this so important?
Your Software Architect role is the role that provides the project road map to the rest of the roles on your team. They make sure the project goals are front and center and decide on the standards and rules of how to implement the project. All the other roles need to be taking their ques from the architect.
Without this concept clearly defined, the team plays the “who is driving the bus?” game. Sometimes the developer makes the key decisions, sometimes the project manager or designer or sysadmin do, but none of them are using the same playbook or necessarily where they are ultimately going. Not knowing how they are getting from point A (start of the project) to point B (successful delivery of the project) creates underlying tension and manifests itself as extra time and overhead.
This is why I want to train you to think like the architect: to create the map to guide your team to successfully create the software you need. By following the recipes and techniques I’m going to outline, you will start thinking this way and when you implement like an architect your projects will become less expensive and easier to understand and complete. Saving you time, money and emotional dollars.
