Are you an architect or an engineer?

If you share any of my professional background and work experiences, I am sure this question must have popped in your head a few times! The Zachman Framework clearly differentiates between the above two perspectives. As a matter of fact, the framework clearly distinguishes between six perspectives, namely; executive, business management, architect, engineer, technician and the enterprise.

I find the differentiation between the architect and engineer perspective the most interesting, probably because I started my professional life as a software engineer and then went onto play a range of architect roles (business, system, EA etc.) over the last 15 years.

I probably can recollect a dozen instances where these roles overlapped and can also recollect maybe another dozen when there was a gap between the two. That probably is more a comment on the operating model issues! Referring back to the Zachman Framework’s definitions, the two perspectives are defined as below:

Architect transforms the business concepts into business logical representation
Engineer transforms the logical representation into technology specifications

The architecture perspective is about business logic designers. People who manage this perspective, namely those with an architect role profile work closely with business managers to understand the key business concepts and then turn them into representations. Zachman actually names them as system entity and system relationship representations. The engineer perspective is about as Zachman calls it, business physics builders.

In other words, engineers work closely with architects to turn system representations into technology specifications. Zachman actually uses an example of technology entity relationship specifications.

TOGAF though defines architect roles well; it probably does not clearly differentiate between an architect and an engineer at a role profile level. But it does offer a good methodical (as you can expect from TOGAF) and well defined classification of view; namely, business architecture view, data architecture view, software engineering view, system engineering view and so on. In my opinion that works well too as with these views an organisation can then map roles and responsibilities of architects and engineers onto its operating model.

While many readers of this blog may or may not agree with precise definitions, I think this is still a good enough framework for us to start building operating model constructs around how best for architects to work with engineers (or vice versa!)

In some organisations they may be played by single role profile, in large environments it may be spread across say two or three role profiles. In an outsourced environment, architect roles may still be part of the retained IT staff and engineers (or engineering services) may be procured from suppliers. I suppose, individual organisational operating models will dictate the specifics on these.