Gartner Blog Network


Should Security Architecture remain separate from other Architecture disciplines?

by James McGovern  |  April 19, 2017  |  4 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…

 

Category: enterprise-architecture  solution-architecture  

James McGovern
Research Director
1 years at Gartner
28 years IT Industry

James McGovern is a Research Director responsible for conducting research in the Enterprise Architecture and Technology Innovation areas. James is specifically focused on how organizations can use business-outcome-driven EA to respond to disruptive trends and leverage technology to deliver successful business outcomes. Read Full Bio


Thoughts on Should Security Architecture remain separate from other Architecture disciplines?


  1. 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.

  2. 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.

  3. AS says:

    Hope these couple of blogposts will help:
    – how to see together security, risk, and architecture – http://improving-bpm-systems.blogspot.ch/2017/03/enterprise-patterns-sram.html
    – security at the classic business layer – http://improving-bpm-systems.blogspot.ch/2014/04/ideas-for-bpmshift-delenda-est-vendor.html

    Thanks,
    AS

  4. 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: https://www.linkedin.com/pulse/ready-data-privacy-friendly-hello-gdpr-mohammed-brueckner?published=t



Leave a Reply

Your email address will not be published. Required fields are marked *

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.