Blog post

Should Security Architecture remain separate from other Architecture disciplines?

By James McGovern | April 19, 2017 | 5 Comments

In my travels, I have come to observe that many organizations separate out security architecture from other architectures. Does this make sense? Large organizations often have governance practices such as an Architecture Review Board (ARB) yet defer the system quality attribute of security to another entity. Does this beg the question of whether security professionals should have a seat on Architecture Review Boards?

Screen Shot 2017-01-26 at 11.10.46

Various architecture “frameworks” also exhibit a similar level of thinking. Security has its own architecture framework called SABSA (Sherwood Applied Business Security Architecture) that seems to move independent of TOGAF, Zachmman, etc. So, if I am an EA using one of the more popular “frameworks” that remain disconnected from the world of security, does that make it easier for me to forget that a secure ecosystem might also be a desirable business outcome?

Should we believe that having a culture of separation where security feels they need to own all thing security is goodness? What if we could revisit our thinking on security architecture. Would we conclude:

  • Security is a component of everything and not the responsibility of any single organizational entity?
  • Security Architecture in its historical definition is the same as QA/QC but focused on a specific type of error/bug?
  • If we wanted to “build security in” as part of our SDLC, that security practitioners should be consulting as part of that SDLC and not solely focused on operational considerations?

We have a knowledge crisis when it comes to security architecture as part of enterprise solutioning. Care to guess how many solution architects when documenting their solution reference bolt-on security technologies to satisfy the needs of ARB checklists instead of integrating security throughout the entire architecture?

Are we bold enough to acknowledge that both Enterprise Architecture and Information Security are in the business of managing risk yet they never appear unified in their thinking, approach, solutioning, governance, etc? Information security professionals have a “duty to protect” yet many of their recommendations often overstate risk and increase costs to the enterprise.

I have been noodling how to help information security professionals to think more like enterprise architects and to not just think about their duty to protect but also embrace the notion of delivering better business-outcome driven security architecture. I would love to know your thoughts on this topic…


The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.

Leave a Comment


  • MK says:

    I totally agree with you that Securiry Architect need to think like EAs. Specially as Devops and CICD adoption increase this will become even more important. Security is everyone’s role, but oversight must be centralized. It needs to be a key performance goal. Also, I’ve been contemplating if Securiry Achitects should do strategy and consulting or fill the role of solution architects or taking ideas from paper to production implementation. Ent Architects should not just use security as talking point, but actually build value driven security and not look at short cuts to buy pass security. For whatever reason, people are still having trouble building-in security. Even security practioner don’t use solid threat modeling to inject sound security. Either it’s too much or too little. We need a solid, next gen playbook/guidance on this.

  • Bill Pelletier says:

    The first requirement is that the InfoSec professional *must* learn what their respective Business is – and does. Without those two fundamental basics, it does not matter whether or not they are separate from or part of EA. Enterprise Architects by training and experience must strive to weave Security into their Architectures. Security Architects who rose up the ranks in InfoSec – must (not just strive to) become Enterprise Architects. This is the only way in which the term “bolt on” can be effectively mitigated. We’ll never remove it – but we can fix most of it… Maybe.

  • AS says:

    Hope these couple of blogposts will help:
    – how to see together security, risk, and architecture –
    – security at the classic business layer –


  • IT Security is more like an additional dimension to whatever type of architecture to be validated and an inherent concern. Issues with security/data privacy arise exactly where an inherent concern like Security is “outsourced” to other departments or even worse other 3rd party players. Eventually, IT Security is a corner stone as well for data privacy. I have just posted about that:

  • Alvin Fong says:

    Security will continue to be a bolt on until the next generation of Enterprise architects “come out of school” with security embedded into their architecture frameworks. The knowledge base and codified practices also need maturing. For example, threat modeling practices such as ones by OWASP are only now beginning to be mainstream ( yet don’t have a place in any Enterprise architecture frameworks. SABSA does its best to merge the two diciplines but I contend there is no EA framework that provides a standard way for design and assurance of positive security outcomes. Many architects are still stuck in a security=access control way of thinking, which the daily news cycle of data breaches should be proving, is a wholly inadequate mindset.