Architects versus Engineers

As a child in the 60's and 70's, on the east coast of Florida and around the Space Center, I dreamed of being an Architectural Engineer. My childhood vision was to design the first under water communities off the continental shelf. With an understanding of architectural engineering and marine biology, we could apply living under water to space stations and planetary living.

Later in the 70's, going to school with a major in Architectural Engineering with minor in Marine Biology, and with the economy at that time, it became too much to handle and my interest switched to Business and Finance. Funding such dreams became my next challenge.

After school, I went to work for a friend of my father, Sol Price. He had a vision of building a Membership Warehouse Club, which was called Price Club. You now know this as Costco.

With my passion still in Architecture Design, I started using my experience with Computer Aided Design (CAD) as a side benefit in our Business's Operations. I was able to build the finance and Business Models needed for such operations, as well as design the facilities where the operations would take place.

Retiring at a young age in the 90's and in the dot com era, I gravitated towards my passion in Computer Science and the internet boom was the perfect time. In 2000 I went to work in the world's largest Telecom Company where I recently retired after 20+ years. I am now passing my knowledge and experience to the next generation, and I must share my knowledge and experience as an "Architect" and an "Engineer". Unfortunately, the industry seems to be confused as there are major differences between the two, especially in hiring the right people IMHO.

Differences?

Let's just pick "Software" as our basis. The main difference between a software architect and a software engineer is that the former focuses on the technical aspects and feasibility of the outcome and delivery. In contrast, the latter focuses on building the technical solutions that make the software operational.

When I joined the last company I worked for, people seemed to have the wrong titles. Their title didn't match either their role or their capabilities. They had a role called "Solution Architect", but also had  role called "Enterprise Architect". I had no major concerns as Solution Architects focus on designing solutions for specific projects, whereas Enterprise Architects have a broader responsibility, aligning IT strategies with overall business objectives across the entire organization. The problem was when the Enterprise Architect starting playing the role of Solution Architect. To make matters more conflicting the had a role called Application Architect. Where were the Engineers?

In contrast to Software Architects are more like Solution Architects and Software Engineers are more like Application Engineers. Software Architect is more concerned with the overall system architecture, strategic decisions, and long-term planning, whereas a Software Engineer is more focused on the implementation of specific features and coding tasks. The roles are complementary, and effective collaboration between architects and engineers is essential for successful software development projects. Later in years, they attempted to rebrand Architects to Engineers, and I had to ask, "Where were the Architects? 😜

See the Problem?

So...WHO DOES WHAT? 

If you’re familiar with the idea of left-brain and right-brain dominant people, you already have a good grasp on the fundamental difference between the characteristics and responsibilities of architects vs. engineers. The left brain is associated with heavy thinking, analytical processing, math, logic, and science. Right brain is more feeling, creative, artistic, and free flowing. Of course, no one is entirely one or the other, and exceptions exist, but architects tend to be more right-brained while engineers are more likely to be left-brained. While the responsibilities of engineers and architects often overlap, both are accountable to you as their client. 

THE ARCHITECT’S RIGHT-BRAIN VISION 

An architect begins by meeting with the client, understanding their needs, goals, and ideas. The architect then grows this into a large and artistic vision addressing the client’s needs while integrating form and function in a hopefully impressive way. This vision is typically expressed in the form of a full set of architectural models or perspective drawings comprised of floor plans, roof plans, elevations, sections, and more.  

This, of course, requires a good amount of left brain work as well. They must design within regulatory, local codes, and other limits, while being aware of privacy, safety, and remain current on both technical innovations and various rules and laws. To facilitate the collaborative design process, architects also need capable people skills, as well as both written and oral communication skills.  

So, the architect has dreamed up a stunning, and fully functional system or building. Just because it looks okay on paper, doesn’t mean it’s constructible. This is where engineers come in. Ideally, architects provide the following for an engineer’s review: 

• High level Design and overall System Architecture
• High level of abstraction
• Strategic Decisions about System architecture
• While thinking of Code, focus on design, architecture, and ensuring software aligns with business goals and requirements
• Responsibility of the entire system architecture
• Collaboration with various stakeholders to ensure alignment and convey vision
• Long Term Goals and evolution of software over time
• Established coding standards and best practices for development teams

THE ENGINEER’S LEFT-BRAIN REALITY 

Engineers tend to be the left-brained type, using math, science, logic, and visualization to fully understand the constructability and feasibility of an Architect’s Solution and Design. Using the Architect’s preliminary models and the information listed above, an Engineer designs and validates the structure to support the Structural capabilities.  

The Engineer ensures the design is safe, meeting all appropriate Laws, Regulatory, and human concerns, while specifying not only the structural components, but details such as power, security, localization, internationalization, and geo concerns. On larger enterprise projects, each of these might have their own Engineer assigned. 

Just as the Architect provided information to the Engineer, the Engineer in turn provides the Architect with crucial information: 

• Code Standards and Technologies
• OSI Concerns (all 7 layers)
• Lower level abstraction dealing with components, modules, and features
• Software Features relevant to Systems
• Collaborates closely with team members, other engineers, testers, and project managers
• Focus on short term goals, feature implementation, and quality issues (bug fixing)
• Adhering to coding standards
• Structural deployments in Data Centers  
• Size and locations of system assets and components 
• Locations and types of performance gaps 
• Possibilities for improving efficiencies in deployment

The Theory Is

The theory of right brain vs. left brain can help explain this.

In the 1960s, neuropsychologist and Nobel Prize winner Roger W. Sperry studied epilepsy patients who had their left and right brains physically severed for therapeutic reasons. From his research, he concluded that different hemispheres of the brain have different functions, thus giving rise to the theory that there are right-brain vs. left-brain people:

Right Brain;		Left Brain
Feelings	Intuition	Thinking in Words	Mathematics
Visualization	Rhythm	Sequencing	Facts
Imagination	Arts	Linear Thinking	Logic

This has held true in previous companies and projects I have worked on.

Conclusion

While Software Architect's and Engineer's responsibilities overlap, there are distinct differences in their roles, focus, and level of involvement. Problems in delivery for most large companies start with leadership and delegation or assignment. An Architect cannot do Code Design if they do not understand how to code. An Engineer cannot do strategic roadmap architecture if they do not understand all of the systems supporting the company.

I know that saying "cannot" seems harsh, but as a Software Developer and Development Team Lead, we suffered when an Enterprise Architect try to tell us how our code worked or applied the wrong thinking to its implementation. On the other side, a Software Engineer, or what my last company call as an Application Architect doing system architecture for applications or systems they didn't understand, just led to failure and/or long delays.

Sure, it would be great to find someone that could wear both hats, but we are few and far between. And to find someone that could also where a Business, Marketing, and Finance hat? Well, I'm retied and hope to pass on my knowledge and experience 😎

I am starting a Video Series and always looking for other views. Join us on UML Operator Channel and follow to keep up. Don't agree with me? Cool, I look forward to learning together!