Skip to content

So, You Want to Be an Architect?

The opinions in this article are my own and formulated from a lifetime in the software industry.

You’re a dev, maybe a few years into your career, and you’re working on a project for which some architecture consultants have been brought in to review your solution. They make a few recommendations, collect some money for their efforts, and wander off. You think to yourself: “Those guys and girls are cool. They seem to know what they’re talking about, they get to tell everyone what to do, and I bet they make a lot of money… I want to be an Architect.”

In this article, I share my thoughts on an architect’s primary duties and what their focus should be, outline what I think it takes to become a Software Architect, and identify Architect Anti-Patterns I’ve seen in my career.

What is a Software Architect?

Firstly, no universally recognized engineering guild or licensing authority exists to hand out Software Architect licenses. One may argue that there should be such an authority, another may say that there shouldn’t be. Either way, a licensing authority does not exist. However, Software Architect is a well-known and well-used job title, and there is a general understanding of the position’s role, responsibilities, and requirements.

Key skills of a Software Architect include:

  • Technical expertise and experience
  • Leadership, communication, and collaboration
  • Business awareness or acumen

An architect’s roles and responsibilities will typically include:

  • Setting technical strategy and direction for the organization
    • Driving a cloud strategy
    • Approach to software development and delivery (DevOps)
    • Technical platform selections or recommendations
  • Designing software solutions
    • Understand requirements, both functional: what the system is going to do, and non-functional: how the system needs to behave (which can include security, performance, and scalability)
    • Identify software platforms and related frameworks based on a set of requirements
  • Educate team members
    • Provide technology “expertise” in a variety of areas
    • Prepare and present seminars for solution specific technology to help get a team up to speed
  • Collaborate with business
    • Collaborate with business leadership to ensure the technical strategy will support the business strategy
    • Collaborate with team members at a more detailed level

Some key skills of an architect include excellent time management, an ability to see ahead a bit, and being self-directed and independent enough to leverage a technical vision. They are a lifelong learner who can set aside time to research and learn new technologies.

Technical Expertise

It’s not enough to know a particular language or framework. An architect must also know how to build solutions for simple and complex problems. An architect should be skilled and confident enough in a language or framework to be able to teach it to others and guide them in effective usage.

In our current world, a good understanding of how AI can be utilized to assist either in building solutions or leveraging AI in a solution is critical.

An architect should be familiar with concepts such as Domain Driven Design, Micro Services Architecture, DevOps, and Enterprise Integration.

They should also have a firm grasp of Entity Relationship modeling: understanding what an entity is, its attributes, and how entities relate to each other.

Experience

While we’ve just been discussing expertise, nothing can replace hands-on experience in developing and delivering solutions. Experience should include a healthy mix of implementing business logic, managing data, designing interfaces, and integrating systems.

Look for opportunities to build solutions on different technical platforms. Some examples include the .NET C# ecosystem, Node, JavaScript/client side, and Java.

You may end up specializing in a given area, but being well-rounded still applies. For example, a DevOps architect should have a good grasp of technology generally while also knowing the specifics of DevOps very well. An Integration Architect may have most of their experience integrating technologies but can still build an application if needed. Meanwhile, a Data Architect would be expected to have experience designing data systems and implementing Business Intelligence solutions. An architect with narrow experience may miss out on better solutions for problems because they resort to the limited solutions they are familiar with.

Keep in mind that sometimes, the best lessons an architect will learn are by doing things the wrong way or making an incorrect choice. One must be humble and self-aware enough to learn from their mistakes to minimize the chance of making them in the future.

Business Awareness

While an MBA is not required to become an architect, knowledge of business practices and operations is required. Technical direction needs to align with the business model, and an architect will be in the best position to do that by understanding how a business operates.

  • Cost benefit analysis: Estimate how much a solution will cost and define benefits to the business of investing in a solution. Benefits might be direct cost savings achieved through efficiency, or benefits might be opening up markets.
  • Risk analysis: What is possible? What is likely? What is the likely impact of an adverse event? Work with business stakeholders to understand the risk so they can make an informed decision on what risks to mitigate (i.e., spend time and money on).
  • Business models: How a company makes money, where the highest costs are, the total cost of implementation, and ongoing operation or ownership.

Career Pathways

We’ve defined a bit of what an architect is above but have not addressed how you get there.

At IntelliTect, we are defining career paths for our team members that can result in a Software Architect role. We start with Software Engineer Associate, then Software Engineer at the entry, intermediate, and advanced levels, followed by Senior Software Engineer, and then Architect. The employee gains experience, knowledge, expertise, and independence along the way.

Your career path should go from understanding a library or two to frameworks to participating in building a framework to creating a framework or library.

Other steps include participating in working through complex architecture with a seasoned veteran. This will likely mean taking notes, making slides, and contributing to discussions. Exposure and practice are critical to each step of the way. At each step, additional technical and team collaboration attributes are gained and demonstrated in duties before moving to the next level.

The best milestones are completed projects or initiatives such as gaining a relevant certification, writing blogs on a particular topic, or giving a talk at a meetup or conference.

Explore New Technologies

As you progress in your career, continue to educate yourself. It’s not enough to just know the technology of your current project; you should strive to be as technically knowledgeable about the project’s technology as anyone on your various teams

Look for or create opportunities to present technology. Introducing a technology to your team for evaluation is a good sign of a future architect. This should come with a reason why or benefit description. “It’s the latest hotness” is not good enough. “This will save us hours every iteration” and “This tech will allow us to implement features X and Y” are good enough reasons to at least have a discussion. Have an idea of how this technology will positively and negatively impact the customer and team.

Estimating Projects

Get good at estimating projects. You will likely be responsible for determining how long it will take to build a solution and how much the solution will cost. In the days of agile, we care less about specifics and more about larger effort estimates. For example: a few weeks of effort, a multi-month effort, a multi-year effort.

Increasing scope of responsibility:

  • Responsible for your own solutions or part of a solution
  • Responsible for what (and how) a team builds a solution
  • Responsible for what an entire enterprise builds

Expand what you know:

  • Development platforms: .NET, Java, Go
  • Design patterns (Gang of 4 evolved)
  • Solution patterns

Manage:

  • Costs (including Total Cost of Ownership)
  • Risks
  • Reliability

Architect Anti-Patterns

Unfortunately (or maybe fortunately), I’ve been around long enough to see a few common attitudes or anti-patterns develop among architects I’ve known, especially in large organizations. While we’re talking about what makes an architect, I’d like to point out some behaviors that don’t make an architect, illustrated in the voice of the anti-architect:

  • “I’m keeping our organization safe by not upgrading to released versions right away, waiting for them to be fully vetted before adoption.”
  • “Aligning all teams on the same technology platform is best for our organization.”
  • “I haven’t actually built anything for years, but I’m smart enough to know what’s good anyway.”
  • “I don’t need to discuss technical direction with the developers. I can make unilateral decisions without input from the developers doing the work.”
  • “Just use the platform/framework/library I specify. You don’t need to know why I think that platform/framework/library is the best.”

These anti-patterns illustrate a way of thinking or approach that can seem positive but doesn’t help an organization achieve objectives in the long term. An architect should be assisting teams to deliver with speed, efficiency, and safety. Keeping technology current is really the only safe way to operate for example.

Beware the Ivory Tower Architect: Politically connected but not connected to teams doing the work and hasn’t built or delivered anything beyond architecture specifications in years.

Want More?

There’s no shortage of information available on software architecture. A few of my current favorite references are below.

Does Your Organization Need a Custom Solution?

Let’s chat about how we can help you achieve excellence on your next project!

Let’s Chat