Defining The Architect Role, Part 3: Titles

August 17, 2022

Welcome Back,

I hope part 2 was helpful. I discussed three basic categories of architectural thought and output to establish an ontological view.

In part 2, I aim to leverage this foundational view to compare and contrast an architect with an engineer to elucidate the differences so we can establish a bird’s eye view of accountability across technological quanta.

This is a scenic tour. It is hard to understand how a role fits in the greater organism of a business without understanding or questioning the organism. There are easter eggs, and I’m going to try to do my best to make sure there are links to all of them. I’d love for this to be a reference, but if it’s just a fun ride through the country with the windows rolled down on a breezy afternoon of the dog days of summer, that’s a worthy consolation!

Recap of the Ontology:

Architects generate three categories of artifacts:

  1. Process
  2. Autonomous Artifact
  3. Assembly Artifact

Process Artifacts

A process can be something built from scratch, but more often than not we are talking about change or optimization. I used the term change agent to describe an architect whose role is wholly defined by a change effort. I also discussed how many architects, through leadership and collaboration help approach change with broader strokes.

Autonomous Artifacts

We discussed definitions of artifact and the nature of newness in order to expose some of the challenges of ambiguity by defining roles only by the scope of what they generate. I also discussed the notion of the three I’s (Invention, Iteration, Innovation) to outline a deeper perspective into how architecture technologists may approach the artifacts that they create. This ties back to the concept of process.

I also discussed The Autonomous Artifact Test as a means for defining what an autonomous artifact is. This was defined in order to help foreshadow the third category of architect. I also discussed the compositional nature of technology, to help provide a clear demonstration of the manner in which problems might be approached depending on the characteristics of an organization and those problems they intend to solve.

Assembly Artifacts

The third category was defined as a form of constructing output based on opaque components, where the value isn’t from the creation of something new, but rather the aggregate output of those components.

Recap of Role Definitions

Comparison of Architect and Engineering roles (Vectorization of roles)

  • Depth/Vertical Skill Sets
  • Breadth/Horizontal Skill Sets
  • Time (Tech in 3D

Task/Action Categories

  • Tactical, Delivery-focused
  • Strategy, Vision

A Note on Architecture Frameworks…

I debated the approach on this section far more tirelessly than I should have. There are a plethora of formal definitions for architect roles contained with the pages and chapters of TOGAF, Zachman, et al.

Criticism A: Modern Relevance

This series is ultimately targeting hiring managers and recruiters, so I’m very much interested in the verbiage that ends up on job descriptions. Enterprise frameworks are still well-represented for architect positions in a statistically significant way. However, in practice, the use of the entire scope of such frameworks decreases non-linearly with time.

More often than not, these frameworks are being unofficially trimmed down to concepts that favor ubiquity in organizations.

The highly detailed parameters and protocols are discarded in favor of flexibility and agility, leaving behind collections of symbols and communicative tools.

I recognize that my position might not be popular, but I fully believe that it is past time for a renaissance of sorts to formalize an architectural framework that copacetically adopts practices in line with modern engineering practices.

I would argue that this has begun:

Criticism B: Lack of Inclusion

Certification and accessibility to many of the resources presented by some of the organizations that back existing frameworks are unacceptably restricted.

TOGAF, for example, is not available for individual membership. Membership is restricted to organizations willing to pay the fees, which are quite high. While there are materials that are available for out of pocket expense, there is something unsettling about such constraints dictated by an organization called ‘The Open Group’.

These types of constraints are a bit tone deaf to underprivileged, marginalized populations.

Additionally, the enterprise price tag excludes non-profit organizations, start ups, open source projects, etc.


Given these criticisms, I’ve decided to weight the focus of this final article on a truly open perspective. While I understand some job descriptions do represent the hierarchies and taxonomies derived from pre-existing architectural frameworks, I’m going to extract the descriptions specifically in terms of the tools that were constructed for this series.

The ontology, and division of labor discussed in parts 1 and 2 was constructed with this motivation as a fore thought.

Let’s get to work!

Each section is going to discuss a high level architectural category, outlining some of the titles corresponding to that category.

Transformation Architects

Arguably, every class of architect could be called transformational under the right circumstances. Looking back at strategy vs. tactical, as well as artifacts as process, many of these elements inside an organization require a heavy, front loaded lift in order to install that new concept into the organization. Once the architect has cleared the hurdles related to onboarding the organization into the new process or circumstances, their efforts dovetail towards preservation, curation and inevitably optimization and acceleration.

This process is arduous.

Change can’t be forced nor can the pace be dictated. One of the most egregious mistakes I’ve seen across any transformative effort (but especially in the adoption of Agile) is handing verbose, exhaustively comprehensive tomes of agile characteristics and processes to the doe-eyed teams on the other end.

This is a sign that the transformation architect is not truly in sync with the governing dynamics of agile. Just like physical flexibility, most of us don’t gain it all at once, but by inching forward bit by bit every day.

The reduction of batch size in work isn’t just about writing code in smaller amounts. This concept of ‘smallness’ is pervasive across any structured set of tasks. It’s about decomposing big ideas into little thoughts, so that they can be understood. Most books stop here, but it’s more than just a cursory understanding. It is about developing a commanding knowledge of the concept so that it becomes a natural part of your day-to-day language.

Start small. Hand teams one bite-sized idea, and let them savor the flavor. Let them build confidence. Go slowly. As their confidence grows, so will their enthusiasm and excitement for the next step. Rather than the abatement of fear and resistance, we will replace it with something else by nurturing achievable milestones.

Agile Architects/Agile Coaches

I’ve actually seen Agile Architects listed. Interestingly enough, most of the skills on these job descriptions are based on a background in project management.

Agile as an SDLC (Software Development Life Cycle) has roots from Agile Software Engineering. It is very much worth splitting hairs between the two, because they aren’t quite the same things.

Agile Software Engineering is just a collection of 12 principles that industry leaders codified in the manifesto linked above. These principles are suggestive, but not mandatory. Like any architectural concept, there may be trade-offs or circumstances that reduce the principles from absolutisms into good practices.

Agile SDLC on the other hand is a collection of ceremonies and processes that help organize teams, vision and delivery to those aforementioned principles.

Agile Coaches/Architects are change agents with a good understanding of both. They understand not only the mechanical components of agile, but why each is used, and how to evaluate the trade-offs in order to improve the value of the organization they are attempting to transform.

DevOps Architects

This is a term that I feel is quite tragic. John Allspaw and Paul Hammond kicked this trend off over a decade ago. Their presentation was ultimately a master class in successfully answering the ‘Why can’t we all get along?’ question posed to operations and development organizations. Since then, it has been overloaded manipulated and ultimately decimated by a clear lack of due diligence across the industry as a whole.

DevOps is a process, and a system of thought. The most common error to date is the prescription of technologies onto DevOps, freezing it into an immutable state. Tomorrow, if we find a way to make carrier pigeons the most effective (and safe) means for deploying software, it will replace CI/CD.

Most technologists love technology. We love applying it, implementing it and playing with it. It is akin to playing with a toy. Wolfgang Ketterle, a professor at MIT (and an expert in laser cooling), suggests that we are driven by the desire to tinker.

However, if we get lost in the tools, the lifetime of our relevance is tightly coupled to the tool. If we let ourselves become the tool, through understanding of process and concept, we become flexible (or agile!) enough to maneuver and learn continuously throughout the entropic, squiggly-line path of innovation in nature.

DevOps is just about finding ways to circumvent the challenges of collaborating between two segments of organizations with missions that are diametrically opposed. It is about finding and embracing gray amongst the black and white, with the context of handing value to the end users of whatever it is the organization creates or delivers.

Today, that means cross-cutting concerns, integration and deployment of software artifacts (whether they be autonomous or assembled), automation to reduce error, scanning for vulnerabilities to increase safety, as well as the orchestration or coordination of these efforts to provide fast feedback, high visibility and the best end-user experience while at the same time creating the least stress for those who participate in this process.

Very much like Agile coaches, a DevOps architect is often inserted into an organization as a change agent. Unfortunately, the purpose is slightly harder to lock down. If the intention is pure, related to the founding principles of the DevOps movement, then the nature of the role is typically a referee of sorts. They will help introduce the tenets of DevOps, while providing technical solutions to the friction between operations and development.

If the intention is more mechanical, then the role is typically just an operations focus under the guise of collaboration. More often than not, in these cases, the role is going to be associated with popular technologies identified at any given time as being associated with DevOps. I strongly recommend evaluating these roles carefully. In complex, multi-year transformations it isn’t unthinkable that certain technologies will become stale or even obsolete before the transition is complete. Flexibility provides adaptability, and in all but extreme cases is likely to result in better outcomes for the employee and both sets of stakeholders (internal and external).

This might be a tangent. Or it might be intentionally ‘squiggly’ to present a facsimile of the nature of the role over what is ultimately a very short period of time.

I don’t believe in ‘DevOps’ as a role. I view it as a culture. That said, I think that DevOps Architect might be one of the few role titles that makes sense, if the description’s intent is transformational in nature.

This also brights to light some characteristic sub-roles that a job like this has to take on: mediator, counselor, judge, arbitrator.

The Business Architect (Part I)

This is another interesting title. As I mentioned in the preface to this category, many architects can fall under this category. A business architect is one of the more classic examples, especially in the past 5 - 10 years. Business Architects are defined in a number of architectural frameworks, specifically around business strategy. However, given the vast number of transformative efforts currently underway, the job descriptions of this particular flavor have begun to shift in order to represent transformation.

Strategy is a generic concept. In the non-transformative sense, it can be explained loosely as planning ahead. It can be thought of as connective tissue amongst other aspects of technical architecture, binding technological assets to business rules. In the transformative sense the role has to take on the scope of ensuring that the business rules are flexible enough to endure the changes to the business. The role might take on a defensive nature, extending to make sure transitions from one way of working to the other is performed in a step wise fashion so as to not interrupt the business in a manner that jeopardizes revenue or other matters of operational concern. (During my research, I even encountered a variation of this title referred to as a BRP Architect.)

The only reason I mentioned this role in this classification is due to some of the interviews I held with hiring managers. As I investigated the titles, I found that many of the organizations hiring for this position were actually staffing it in pairs:

  • One Business Architect was focused on working with transformative stakeholders to ensure smooth transition of the business.
  • One Business Architect was focused on standard day-to-day strategy, constructing business rules and working to ensure alignment between key performance indicators and other areas of the business.

Organizational Architects

These architects are primarily concerned with tasks and categories of work that ensure the functional operation of the organization as it relates to technology.

We could classify this as operations, enterprise or just IT. I found job descriptions and titles for each:

  • Enterprise Architect
  • IT Architect
  • Operations Architect

I had a hard time defining this, because these titles are almost exclusively derived from enterprise architect frameworks.

Eventually, I decided to scrape one thousand job postings with these titles and put on my data engineering hat. I ran through a dozen or so analytical exercises to determine what words were the most prominent given different relationships.

To my surprise, the word that popped out was ‘organization’. I started to look at other popular words, and it became very clear that the ulterior motive of these types of roles was in support of the organization. This probably should have been more obvious to me initially, but I think I was so ‘head down’ during my research that I simply forgot to step back to get a broader view.

Some of these roles are indistinguishable from software or technology architects in their responsibilities. Some organizations like to build their support infrastructure themselves. Others like to pull Customer Off The Shelf (COTS) products.

Build vs. Buy decisions are outside of the scope of this series. The justification for these decisions is what differentiates this category from others. Operations and internally directed IT have been classically defined as cost centers. They don’t directly generate revenue, so the focus on ‘keeping the lights on’ has traditionally been an effort of cost reduction.

The DevOps culture attempts to define operations as a revenue generator. This is somewhat misleading. The tenets of DevOps have a side effect of reducing cost as well as inserting operations into the product focused value stream. Truthfully, these circumstances existed before DevOps was thought up. Product IT departments were operating in a similar manner before DevOps caught on. The difference is that DevOps has codified and quantified them in a systematic way to make it an easier argument to defend.

Operations / IT Architects

(and occasionally an Application Architect)

For the most part, the job descriptions I found for these titles were nearly identical. They were somewhat generic in responsibilities, but they were ultimately focused on integrating COTS or open source software solutions into an organizations IT systems.

These roles appeared somewhat junior to an Enterprise Architect, focused on some subset of the enterprise systems as opposed to an end to end holistic view.

Leveling varied to a single application up to managing the assets for an entire business unit.

Responsibilities included a heavy focus on governance, security, cost reduction and traits that provided value through automation and reusable capabilities.

Technical Architect

In organizational context, a technical architect might just be a synonym for Operations/IT/Application. However, there are a sizable number of descriptions that point to a technical architect being a software architect focused on organizational assets.

These roles would ultimately be no different than a software architect working in a product context outside of the end purpose of the technology being designed. Organizational technologists are focused on providing tools, assets and applications for internal stakeholders.

Data/Information Architect

Another special type of technical architect, typically associated with the organization, is the Data/Information architect. These architects tend to be focused on the governance and governance maturity models associated with an organization’s information assets.

One of the interesting aspects of this role is when an organization is managing or hosting customer data. This tends to fall into the same scope as a product architect, however, the focus is still heavily influenced by the manner in which the storage system is defined and defended.

Some of the organizations that do this will have two separate sets of staff for managing enterprise data and customer or client data, while others design the client-facing systems in such a manner that they can be administered and operated by the same staff.

The Enterprise Architect

(Sometimes a Chief Architect)

A quick note on the term ‘Chief Architect’. This title has omitted its middle name. You might peruse through job descriptions and find some that are part of the product value stream and others that seem more aligned to the enterprise. I believe that ultimately there is such a thing as a Chief Enterprise Architect and a Chief Software Architect. They are very different roles.

Chief, being used as an adjective, is ultimately a leveling modifier that helps distinguish between the ‘most senior categorical technologist’ in a larger organization of which there may be many enterprise architects or software architects.

The enterprise architect is the person responsible for designing the architecture of the enterprise. (Naming isn’t as hard as we thought!) This ultimately means that they are responsible for the design of all of the technology systems and assets that keep the organization operating.

They have a holistic high level view. In larger organizations there are probably various IT/Operations/Applications Architects and operations teams working to realize that vision. The smaller an organization is, the fewer heads the enterprise architect has to work with. Thus, they are likely to be closer to the nuts and bolts of the systems proportional to the size of the organization and the complexity of the systems.

The Business Architect (Part II)

We covered the transformational classification of a Business Architect earlier. In addition to transformational efforts, business architects are strategists. This role is defined by a number of Enterprise Architecture Frameworks, however I found it to be fairly uncommon on job boards.

This role has similar responsibilities as a Business Analyst or Project Manager, specifically focused on an internalized value stream.

Product Architects

Product architects are those architects who are direct participants in the value stream. Their roles and responsibilities are focused on the delivery of the organization’s proposed value to external stakeholders.

Product Architect

aka The Business Architect (Part III)

A product architect might be a technical architect, but more often than not I found that the descriptions for this title were derived from product management skill sets. I also found this role defined as a Business Architect in a few cases.

This position is more about product strategy than anything else. Sometimes this role includes lightweight UX (User Experience) responsibilities, gathering requirements from customers, possibly managing a beta program, performing UAT etc. In larger organizations, or organizations in domains that operate with heavy user-facing requirements, the UX aspect is probably a dedicated position.

I’ve found this role interesting, because at first glance it seemed to be almost synonymous with a product management position. I looked at some of the organizations posting roles like this, and found that they had PM roles that coincided with the Product Architect roles. The role appeared to be more prevalent in organizations that had very large product teams.

I did reach out to a single source to discuss this. In their specific case, the Product Architects were focused on a single product, whereas product managers in the same organization were spread across multiple products. This role was designed to help extend the scope of the product manager, by obfuscating some level of detail away from them. Presumably these product managers were emphasizing stakeholder management skills.

Data/Information Architect

As mentioned in the organizational section, there is a category of technical architect focused on data and information. In a product-focused role, data and information architects are usually focused on designing schemas (or application constraints in so-called ‘schemaless’ systems). Sometimes, they are a hybrid application/data architect, focused on designing how applications (or larger systems) provide capabilities for managing data, caching data, persisting data, etc.

For companies that offer some form of managed services that deals with persistence (i.e. Database as a Service, or even Storage as a Service), it is likely that the data architects will play a role more synonymous with their organizational counterparts.

UX Architect

This is probably them most self-explanatory of any of the architect descriptions. UX Architects are focused entirely on user-experience. This often includes disciplines such as web content authoring, front end development, accessibility and lately even sustainability.

As mentioned above, this role is often a dedicated position for large organizations, or where customer interaction is extremely critical to the success of an application.

Mobile applications, interactive web applications and other scenarios that provide a user experience with requirements involving a high volume or quality of touchpoints is a generic example of an application that requires such focus.

Teams that don’t have a dedicated UX architect may push these responsibilities to the technical architect, the product owner or some distribution of the two.

Software Architects

This is easily the most common job title and description for an architect. A software architect is primarily focused on creating autonomous artifacts. However, given the scope of the organization, they might have transformational responsibilities. Likewise, given the scope of the technology, they might also product assembly artifacts.

Embedded Architects

Embedded systems is a technology discipline that (can) cover a number of software assets. This can include the device portion of IoT, personal assistants, robotics, autonomous vehicles, and even mobile development.

Additional disciplines that are often adjacent to this field are AI/ML, NLP, and computer vision.

Hardware Architects

This discipline is associated with the technology design of physical devices. The difference between a hardware architect and an embedded architect is that the hardware architect designs the device, while the embedded architect designs the software that is installed onto the device.

One area that can technically bridge both embedded and hardware is firmware. Technically, firmware is software embedded onto a system. In most cases, firmware is considered part of the hardware architecture.

Application Architects

An application architect is typically bound by the scope of a single application. The relationship of this scope to an organization depends on the portfolio. If the organization only produces a single application, then the application architect may be the only architect in the organization. However, for a large distributed system, or a multi-application portfolio, the scope may be subsidiary to other architects.

Systems/Distributed Systems Architects

Cloud Architects? Infrastructure Architects? Platform Architects?

Traditionally a Systems Architect was a senior Systems Engineer, often operational in nature. I do still see a few descriptions of this nature, but ‘Systems’ has come to be used more commonly as a shortened version of ‘Distributed Systems’.

These types of architects are often responsible for the holistic design and/or assembly of microservices, PaaS, IaaS, or other multi-component architectures.

The degree of responsibility and scope of technologies often depends on the technology strategy of an organization. In some organizations, distributed systems could be almost entirely constructed from cloud service providers or infrastructure technologies.

Infrastructure and Platform architect roles are often synonymous with this title.

There is actually a fair amount of controversy over these titles as Infrastructure and Platform are words that have become associated with operations or cloud engineering tasks. The context of the title isn’t misleading, despite the reputation they’ve endured. The context of the title is driven by the organization’s technology direction as mentioned above.

A company that is focused on doubling down on cloud computing, is likely to design these systems, infrastructure or platforms using as much of the cloud offerings as is feasible to solving their problems. Code, in whatever degree it is created, is likely to exist as connective tissue and the absolute bare minimum of business logic.

Conversely, a company that wants more control over their own solutions, will likely lean further into the ‘build’ portion of the build vs. buy dichotomy.

There are always tradeoffs. Cloud computing reduces staffing and headcount costs, but you are at the mercy of the cloud service provider with respect to the constraints and allowances of their offerings. Building your own infrastructure, is expensive but it gives you more control.

Good architectures will usually split the difference between the two. Write code for the things you want or need control over, or for the things that cloud service provider can’t meet your needs. Use the cloud judiciously in areas where it can provide you with what you need with safe boundaries for the architectural characteristics that matter.

Sales Architects (Solutions Architects)

Sales or solutions architects can have responsibilities in varying combinations from any of the previous examples. The only difference is that there is some form of sales, pre-sales or consulting included in the responsibilities.

There are two general categories of sales architects: consulting and internal.


Consultant architects are external employees, independent or part of a consulting firm, that are hired to help the business. This may be due to lack of an internal position or due to lack of internal perspective.

In the first case, the architect is often hired for their expertise and skill set because it doesn’t exist in the organization and they have been unsuccessful in hiring for it. This is a form of staff augmentation that could be focused on designing internal systems (like an organizational architect) or helping to design part of the product (like a product architect).

In the latter case, the architect’s role likely has a transformational element, such that they are bringing a new perspective to the team.

There is a stereotype that this is only for large, old, waterfall companies that fall into the ‘you can’t teach an old dog new tricks’ category. Yes, there is some truth in many stereotypes, however, the danger is that they often reduce circumstances to binary concepts inaccurately. Organizations of any size get stuck, there just happens to be more opportunity for deadlock and standstill the larger an organization grows.

Internal Pre-Sales

Internal sales architects are often referred to as Pre-Sales. It isn’t a very good name, because they are usually involved before, during and after the sale. Usually, these roles are focused on providing technical support to sales executives to help facilitate the sale while avoiding (hopefully) the circumstances where a salesperson oversells the product beyond its capabilities.

This latter scenario is important to understand, because it represents checks and balances. Selling something to a customer who inevitably can’t use it to solve their problem (either at all, or to a lesser degree that doesn’t meet their needs) represent a poor user experience. This jeopardizes the company’s reputation.

Sometimes, there are even legal obligations that could lead to financial damages or obligation to provide the promised functionality. This last case can have a cascading effect, as meeting the obligation to the customer could impact the existing roadmap and by extension, the customers who are relying on the timelines for promised features therein.

I mention this, because it outlines what kind of thought process is necessary for a pre-sales architect to possess in order to make good decisions during the sales process. Like any architect, there are trade-offs.

The role also extends beyond the sales engagement, often to help guide and shape delivery of a product. Large, complicated systems often require expertise, configuration, training, integration, and other efforts that are encapsulated inside internal professional services organizations with manage the post-sale responsibilities and obligations to delivery the product (and value) to a customers hands.


That does it for part three.

I hope this was helpful (or at the very least enjoyable). If you take away anything from this third installment, I hope that it is one of the following:

Be Fluid

Titles, Roles and responsibilities are fluid. Let them be. They aren’t just a piece of paper or set of words. They represent a contextual, organic component of an organization. Software, delivery, product, IT are all team sports. The role or position you play doesn’t just depend on the basic skills, it also depends on the skills of the rest of the team.

Architecture isn’t just Technology

I quite deliberately included sales, product and UX to demonstrate not just that architecture goes beyond technology, but that it is intertwined with it. We have a tendency to compartmentalize concepts when we classify them, however that’s not always the best course o f action. A marriage of two partners is about mixing and relating and collaborating. We can still be separately defined and accountable.

Thanks for reading, and as always, smile. It’s a ray of sunshine even on a cloudy, rainy day.

Profile picture

Written by Ed Mangini
A Technology Blog about useful stuff.