About 3 years into my career, I was promoted to the coveted “Application Architect” at a manufacturing software subsidiary of a Fortune 500. At the time I was a force of youth and passion – but I hadn’t developed the skills necessary to really shine in the position. I was successful in many ways, but I also lost many opportunities that are crystal clear looking back at that early period of my career.

I served as an Architect in several positions after that, but it wasn’t until I started working for Catapult as a consultant that I learned the soft skills necessary to really be effective. In my 9 years of consulting I’ve had the benefit of working alongside architects at clients that were both great and in need of some help. Though the industry still has no standard definition for what an Architect should do (don’t believe what those certifications try to tell you), there are a few considerations that lend themselves to great outcomes in the position.

Catching Process Breakdowns

Any architect who has worked with a team to deliver a product or service will have stories to tell about what makes a great process for delivering software, and what doesn’t. When talking to a potential Architect, I look for how they used technology to prevent low quality deliverables from getting further down the release pipeline.

We’ve probably all worked on a project where the team established a process for testing, code reviews, and managing configuration changes in each of the environments the product gets deployed to before customer eyes see it. It all sounded dandy until someone realized team members weren’t following the process – but that was too late. How does the individual use technology to cause deliverables to fail fast if they aren’t acceptable?

A Realistic Estimation Mindset

One of the hardest things about being a developer is estimating. The more experience we have with a technology, and the better we understand what constitutes acceptable deliverables, the more accurate the estimate. Most projects allow some user stories to be given to the team with too much uncertainty in the technology or holes in acceptance criteria – how does the individual deal with this? A common response to this situation is to get clarification from the product owner – but what happens when there is still significant risk? I like to hear how individuals communicate timeboxes for research or prototyping of an aspect of the unfamiliar technology and how they would determine when too much time is spent on it.

Sharing Pattern Decisions

We’ve probably all worked with a technical “leader” of some sort who has to be the person to set the pattern that will be used for error handling, validation, messages on a service bus, or a host of other common needs in modern applications. Architects are called to lead – otherwise you end up with the “rockstar” personality who can’t scale and becomes a bottleneck, poorly utilizing the whole team. While a good Architect will show the team patterns during decisions and help them think through problems they might see with them, a great Architect inspires team members to propose patterns themselves and then helps them champion these, giving full credit to the team members.

Mastery of CRUD

The vast majority of modern applications are heavily backed by data; and an application with a poorly designed data model can exhibit poor performance, high cost to introduce new features, and excessive business logic. Great Architects can understand requirements of products as they emerge and help the team to make sound decisions about how to model relationships between data and modify it. They also understand REST not as a technology, but as a principal. I run across a surprising number of Architects that have not developed this skill.

Making Time for the Team

An experienced and effective Architect will not allow themselves to be assigned too much work to support their team. They know that quality deliverables require support and that this has a cost – and will argue it to the folks approving budget with appropriate vigor. As a leader of one or more teams, an Architect cannot be effective if they are annoyed by questions from more junior team members. Rather, some of the best Architects I’ve worked with love to teach and know that by building up the value of their subordinates they can improve the velocity of the team more than focusing on themselves.

Expert Communicator and Facilitator

Almost any Architect can create a PowerPoint presentation or write a blog post, but is what they convey at the appropriate level of detail for their audience? Ask an Architect questions about how they explained an aspect of their implementation of a product to customers and other non-technical personnel. How did they get consensus when stakeholders disagreed?

Evaluate their face-to-face communication style – many architects have a hard time listening because they are already trying to design what’s coming out in the conversation. A great Architect takes notes during conversations and strikes a balance between too much detail and not enough. Evaluating this during an interview or conversation is difficult, but most Architects who know how to do this will mention it when the topic is approached.

Patterns as Necessary

The ivory castles Architects build can become wonders of intellectual masturbation at times and lead the rest of the team to ruin with abuse of the single responsibility principal to an excessive level. I look for Architects who know how to select the simplest possible way to meet the requirements while introducing new patterns only when absolutely necessary. I’ve run across one too many projects where the Architect is the only one following a pattern they set. When I talk to other team members, they just don’t understand the pattern, and don’t have time to follow it. If an Architect cannot write a simple Wiki topic and communicate the value of an aspect of the architecture, chances are it may be unnecessary.

Courage to be Honest

The pressure to agree to deadlines, estimates, and functionality from the business on most Architects is incredibly high. While the best Architects I’ve worked with have an affinity for the business and immense respect for the company’s business model, they aren’t “yes men”. Saying yes to an unreasonable ask simply to avoid confrontation is not only irresponsible but also earns you a reputation for being out of touch with the true effort to complete work. The best Architects set appropriate expectations for sustainable paces of work – and spend the time necessary to argue why their methods are important for the better of the products. They help explain why they cannot make progress on a task in terms the business understands.

Hopefully some of these topics will help you when evaluating your next hire or partner who will be architecting one or more of your applications. What other key traits make individuals successful in this position? Share your comments below! Thanks for reading.


Also published on Medium.