A basic question we're frequently asked is: What is the difference between architecting and designing or, alternately, between architecture and engineering? Most people who ask this question have conflict in their organizations regarding which IT role does what, and it often comes down to which project artifact is whose responsibility.

For most organizations, the ambiguity between the responsibilities of the project-related architect (which Forrester refers to as a “solution architect” — see Leverage Solution Architects To Drive EA Results) and a senior engineer is largely an academic issue. For most organizations what matters most is identifying and sourcing the individuals with the appropriate knowledge and skills and making them available to mission-critical projects. The availability of senior technicians on the projects is what often determines the level of detail in the design supplied by the solution architect.

The exceptions to the “most organizations” mentioned in above are the large-to-very-large engineering shops, such as the largestUS federal government civilian and DoD agencies, and large private sector organizations that do major engineering projects such as Boeing. Organizations that have over 1000 individuals in the development environment and launch multi-year $100M+ IT projects have closely defined project roles and do what is necessary — including extensive external contracting — to source the appropriately skilled individuals. In these environments the “it depends” argument is not sufficient and a clean delineation of role tasks and deliverables becomes necessary.

In general, the role of the architect is to look beyond the scope of a single project (or program) to look after the architectural concerns that will enable (or constrain) the ability to meet service level requirements over time, taking into consideration future growth, evolution of the technology platform, etc. Essentially, an architect’s charter is to look to the future and look enterprise-wide, while the engineer’s role is to attend to the project. So the project-focused architect is responsible for the aspects of a project that are of strategic impact and have impact beyond the specific area addressed by the project.

I asked members of Forrester’s EA and App Dev/Program Management research teams for their takes on this issue and for help putting the list below together. Here’s how Forrester analyst Jeffrey Hammond described which role should produce which artifact:

Architect: Artifacts that by their existence will improve system resilience (the “_ilities”) and flexibility/ability to change (blueprints, extensibility strategy, reuse strategy, OSS strategy)

Engineer: Artifacts that will result in system delivery (code, tests), or improve the ability to deliver said system (burn down charts, task lists).

I also ran this by the folks I usually discuss things with on Twitter and got general agreement about there being two areas of responsibility with a fuzzy area in the middle. Todd Biske said “Project architects need to define the big boxes and the lines between them. Engineers should dig inside the boxes. But there are no clean handoffs, it's a continuum,” while perennial wise guy Aleks Buterman quipped “[The] granularity of [an] architect's involvement in project artifacts is inversely proportional to depth of context.”

In our list, we focused on areas that we felt were likely to be in the gray area between the solution architects’ and the lead engineers’ tasks and deliverables. Thanks to John Rymer, Jeff Scott, Randy Heffner, Henry Peyret, Jeffrey Hammond, Mike Gilpin, Mike Gualtieri, Dave West, and Jost Hoppermann for contributions to this list. Please comment — we'd love to hear feedback from you all!

Primary areas of project-related responsibility for architects vs engineers