Are you an architect or a designer or a developer?

Several months back, I came across an article in my LinkedIn news feed about the difference between an enterprise architect and a solution architect. Having served in both roles in consulting and as an employee, I can attest to the fact that these are two of the most poorly understood roles in an IT Department. I wish I could find it again, because it did a fantastic job of explaining the value of architecture, differentiating between the two roles, and explaining why they are simultaneously different and interdependent. My one complaint with the article (which I commented on) was that it didn’t go far enough because it didn’t extend the comparison from the solution architect to the software designer and the lead developer roles. This is a differentiation sorely needed given the number of job descriptions and resumes I see posted every day on Indeed, LinkedIn, and other job search sites that in appropriately use ‘architect’ in a job title.

To be clear: An architect is not a designer or a developer, no matter how senior or experienced or broad-reaching the knowledge of the persons in these roles are.

The enterprise architect is a planning role that describes what an organization needs to look like to accomplish its strategic plan. This role is responsible for assessing the current environment and determining what change is needed. The enterprise architect will work with the organization’s leadership to develop the roadmap on how to implement that change, which often requires a very delicate negotiation between cost, time, and scope.

The solution architect role is responsible for turning a concept, typically identified as a gap in the enterprise architecture or an initiative on a portfolio roadmap, into implementable plan for delivery. A person in this role establishes the business issues to be solved and evaluates the options to solve the issues. For the chosen option, the solution architect defines how this change will manifest in the environment – at the business, user, information, technology, infrastructure, security, and operational layers. The solution architect will then serve in an advisory and oversight role for one or more project teams tasked with implementing the solution to ensure that the delivered product matches the architected solution and to assist in resolving issues that arise during the process.

The designer is responsible for defining the detailed instructions on how the product will be built, and software designers often have specializations based on the area of the solution being addressed. This includes the placement of fields, widgets, menus, and buttons on a user interface (a task often called the ‘user experience’). It includes the database design and the mapping of the database fields to the user interface, reports, output files, and any other uses of the data in supporting the business requirements. A designer will also define the operational processes that the software will execute, including the business rules, formulas, workflow, notifications, and other elements that the product needs to function. Finally, a designer may layout the network, with its servers, routers, firewalls, and other features, and determine how it has to be configured to best meet the performance standards.

The developer (also called an engineer, depending on the subject matter) is the person who creates the product. This is the person who writes and packages code, configures hardware and software, installs the network, and other similar hands-on tasks. An experienced lead developer or engineer will lay out the structure of a software package so that the individual programs interoperate smoothly, will debug coding issues, and make decisions on where in the product functions should occur (i.e., application vs database, virtual vs physical, etc.).

As someone who has served successfully in roles as a software designer, a solution architect, and an enterprise architect for different organizations and in different industries, I can say with confidence that it is possible to be an architect without ever having written a line of code, installing software, or without having run cable in a data center. The role is not about programming, system or network administration, or project management. An architect role is about planning and change management, either at the strategic level (the enterprise architect) or the tactical/product level (the solution architect).

What is your perspective about these roles? Leave a comment and let us know!

Do good. Have fun. Add value.


2 thoughts on “Are you an architect or a designer or a developer?

  1. I would generally agree with this.

    Just one thing though, button and field placement thing, these days I don’t normally find as the role of an architect. You generally have the UI/CX designer who does that, and not to mention the service designer that comes up with the user journey which requires those buttons and fields.

    I have found that the software designer (aka Applications Architect) deals with designing the configuration maps, best practices, patterns, in application architecture etc. They also deal with security, and integration to/from their product. I have also often found the role requiring the ability to write out restful endpoints for their application conforming to a set standard/guideline, and then present those to the architecture council for approval to the standard.

    Furthermore, they deal with things like backup, data rention policies, business continuity plans specific to their platform. All of these feed up to the solutions architect, who documents the solution as a whole, and finally the enterprise architect to hand over resourcing and training requirements to the run team/continuos delivery team/whomever depending on your op model.

    Incidentally, we call them application’s architects as it avoids situations like UI/CX designers, aka guys who place boxes and draw pretty pictures applying for a technical role and being totally confused what they are doing in that interview.

    Thanks for the eloquent insights Carolyn.

Leave a Reply

Your email address will not be published. Required fields are marked *