In part 1 we outlined that Architecture as a discipline is on the wane, replaced by the approach of doing ‘things’ that are roughly targeted in the right direction.

When studying TOGAF some years ago, I was always a little surprised with the phrase and phase “request for work”. This always made me imagine a somewhat remote group of architects who would be brought in to address a problem. At the time, this didn’t align with my experience of fully engaged architects driving progress in development projects. Experience has taught me that’s not how it always is. 

In Part 1, I outlined a conversation with a colleague focused on the three layers of architecture/engineering and how they go wrong, so lets explore that. Here goes with some brutally abridged descriptions.

• Enterprise Architecture – tasked with trying to get the organisation to “build the right thing”
• Solution Architecture – tasked with getting the development organisation to “build the thing right”
• Engineering/Development “build, integrate and test and deploy the thing”.

The diagram above doesnt account for the size of the function; ideally you want a pyramid of numbers, but with potentially an inverted pyramid of influence and accountability. When this is upset, it leads to problems.

Lets explore some of those different models, as I have experienced during my 20+ years in UK IT. I’m going to use some terminology around strong or weak – as thats what actually matters rather than the size. Size is likely to lead to dominance, but not always.

Scenario One: Dominant Enterprise Architecture, Weak Solution Architecture and Engineering function – lots of strategy, chasing and waiting for the next big thing. Also leads to so-called cargo culting.

Scenario Two: Weak Enterprise Architecture, Dominant Solution Architecture, Weak Engineering function – lots of Powerpoint/Visio of potential options and solutions, but precious little the Engineering organisation can actually build from. Also no alignment to the corporate goals, just delivering outcomes for who has some budget (who shouted loudest in that years budget settlement).

Scenario Three: Weak Enterprise and Solution Architecture, Dominant Engineering function – believe that any problem can be tackled by more code, proliferation of in house developed tools with a standing army looking after them. Often leads to lots of small systems which developers have built a career on and an organisation spending huge amounts on ageing apps.

This is an over-simplification, though like most things, its about balance ultimately having some degree of pyramid structure, and governance that irons out the disagreements and rough edges between the layers/functions.

When it comes to how this matters to a security architect, there are two consideration points:

Security Solutions: Building security solutions for the benefit of the company – this tends to thrive with the ideal that more tools = more capability = more security. Logically reasonable, practically challenging

Security of Business Solutions: business solutions, which require security within them. This requires that the baseline tooling is in place, but that somebody has thought through the design/integration and interaction points and business processes to see where the vulnerabilities may be.

This means you need to be reasonably competent at all of those levels*

In Part 3, I’ll put a few thoughts down on some architecture specialisms.

*I’ve consciously skipped over the role of the Enterprise Security Architect.