Battle of the Architectures: Enterprise vs Security!

As an adventurous learner my eye is always on the horizon for the next big thing to learn. This week I dove into TOGAF and its ADM. I like that it seems to be more clear in its process steps and what is expected from each step than SABSA. But it brought me back to a discussion I’ve had with various people in the community. How do we relate Enterprise Architecture (EA) and Enterprise Security Architecture (ESA)? And how useful is it for me to become an ‘expert’ in Enterprise Architecture?

So, let’s set the scene:

• Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. This definition was brought to you by Gartner, to avoid showing any not-expert-yetness on my behalf. It moves from business architecture to information architecture (data & applications) to technology architecture.
• In a previous article I defined Security Architecture as a discipline (methodologies, reference frameworks, processes, technologies, organization and communication) that produces and maintains architectural artefacts providing structured direction and control to coherent decisions about security in (complex) business and IT landscapes. If we use a framework like SABSA we move from the business and its drivers for security, to what security to do and supporting technologies.

When I start work for a new client, oftentimes I encounter their Enterprise Architects. Some will tell me there is no need for separate Security Architecture, as it’s all part of their Enterprise Architecture. I agree that this is the way it should be — why create a separate architecture? It should be fully incorporated. I struggle with notion in practice because of two reasons:

1. Upon inspection, security is often not represented a lot (or at all!) in Enterprise Architecture. I get it — it is one of various types of risk, and one of the many things EAs need to cover beyond risk. To prove my case: for my exam paper I use the ArchiMetal case study produced by The Open Group. The reason it’s a great basis for my exam is because it presents a full business and technology case study, but never mention the word ‘security’. This case study is 54 pages long! So yes, even though it should be part of EA, I find that it is underrepresented. I do realize security professionals feel everything should be about security (while it isn’t). The truth on how much security should be in an architecture is probably somewhere in the middle. I am also willing to accept the argument in reverse. Many security architects don’t architect business and technology enough, and focus too much on security.
2. I spent my entire career trying to learn as much as I can about security. The development speed and width of the industry means that I can’t know it all (but I still try). For me this means that, except for some very talented ones, there is no way the average Enterprise Architect can ‘casually’ do security on the side. No way. So that is why they should be involve security SMEs (or Security Architects) to build that part of their architecture. And I don’t see that happening very often.

Now let’s stop complaining and look at some solutions. An interesting road forward is the work that has been done on combining EA and ESA in theory:

• There’s a white paper published by The Open Group on the integration of TOGAF and SABSA. This talks about how you can incorporate various SABSA steps and deliverables into the TOGAF ADM. It can be downloaded from both The Open Group and The SABSA Institute’s website.
• There is a The Open Group whitepaper on “Integrating Risk and Security within a TOGAF® Enterprise Architecture”. It is named the TOGAF Security Guide by practitioners. But you ought to have more than 42 pages to do security justice.
• The Open Group has also published the O-ESA framework (Open Enterprise Security Architecture). I haven’t read it in full yet, but at least it has a lot more pages. The subtitle refers to ‘policy-driven security’, which sounds like it goes back to the good old days of ‘Compliance is King’. But maybe I’m wrong.
• The Open Group (these people are busy pffffff!) also published the O-ISM3, a framework for an ISMS (Information Security Management System). I wouldn’t consider this core to good security architecture, but assuming it’s well-aligned with TOGAF it’s worth giving a spin.

At this point you probably think I’m sponsored by The Open Group (not true, alas). So let me include some interesting EA + ESA resources from others parties:

• NATO publication STO-EN-IST-143 is about Security by Design in an Enterprise Architecture Framework.
• A paper from the Journal of Computer Science titled Enterprise Architecture Security Assessment Framework (EASAF).
• A 100-page publication of the Australian government with information security principles for Enterprise Architecture.

It is great that there’s a strong theoretical body of knowledge. Fact remains I have seen few organizations that have an Enterprise Architecture that integrates Security Architecture well. So apparently these resources are not used by all (I hope this article can change that, even if only a little bit). I do believe that we should not want Security Architecture to be a stand-alone product. So, for real change in our work:

• We need Security Architects to get out of our security cocoon and learn much more about business and technology architecture. Our primary aim should be to integrate our security with the Enterprise Architecture. So, let’s be less self-important. Simply be good at what you do.

• We need Enterprise Architects to learn about cybersecurity, but be humble enough to call in the security experts. And it’s like DevSecOps — please involve us in the architecture process, rather than calling us at the end! Me telling you you need to re-do 75% of your work because you missed a critical risk is not a great start to a working relationship.
• We need Management to understand cybersecurity is a complex field. They can’t expect EAs to do that next to the million things they’re already doing. So CEOs/CIOs/CFOs/CROs/CISOs of the world, don’t be stingy with your budget and get a security expert or Security Architect to support.
• We need both Enterprise and Security Architects to study up on each other Architecture languages. In practice I find we use different terms, artefacts and deliverables, making it more difficult to collaborate. If we remediate this, working together becomes a much more pleasant experience.

If we succeed in integrating EA and Security Architecture, we set the Architecture function up for success as a whole. This article is based on my personal experiences at various clients in the Netherlands. That might present quite a biased view. If you know of great E(S)A collaborations in your part of the world, please do let me know what their key to success is in the comments below!

Originally published at https://www.linkedin.com.