Had this question at Owasp Scotland this evening, and didn't get useful answers.

Is there too much specialisation in security now which means that enterprise architects can't know enough to delivery security as part of their day job?

3 Answers 3


My first observation is that security is everybody's responsibility. No one person is going to be able to police an entire organization's codebase. Security design and enterprise design are inherently different in purpose and goal, but the two should interact closely for best result. An enterprise architect's goal is to design a system that meets business needs and represents business processes accurately and come up with a consistent pattern for implementing such functionality. A security architects goal is to design a pattern of security and provide a consistent pattern for it's implementation and enforcement.

In a large environment, the mere scale of these two tasks might merit different people working on them and there could be a slight gain in relation to separation of responsibility between the business process and the security process, but in general I don't see any strong reason why someone with a cross over skill set couldn't do both. (I say this as an enterprise software architect with a background in security design.)


To post a contrary view to AJ's excellent answer:

At a large corporation, architecture may end up being the responsibility of multiple teams in different departments, countries, regions etc. in order to be performant for each region, whereas enterprise security is likely to be managed from a global perspective to reduce risk to the organisation as a whole.

So I tend to favour the idea of security architecture being a sub-discipline of either architecture or security, with practitioners working with enterprise architects in order to reach a best of both worlds (or compromise) solution.


First off, if you are talking about disciplines within Enterprise architecture, I assume you talk about these four:

  • Business architecture
  • Data architecture
  • Application architecture
  • Technology architecture

Of course, many sub-disciplines exist, but I think the one given above is the one that is used most often (also the one used by TOGAF).

Whereas security is a very important aspect, I think it provides a much too detailed view to be comprised as an extra discipline, next to the four given above. Enterprise architecture provides a view over the structure of the organization, comprised in its business processes, data (information) objects, applications, and infrastructure. All of these need to be secure, but they need to be much more, depending on the goals that the organization has set.

If the organization did not set security as a goal (meaning it never appears in the motivation column in the Zachman framework), then it should NOT be translated into a process, a data object, an application, or infrastructure. This is one of the core reasons why security architecture should not be considered a separate discipline within EA: Security is not part of the basic structure of an organization, rather security is a choice that can be made about the structure.

That's not to say that the security architecture is not important. As a comparison: a business process needs to be efficient. Why does it need to be efficient? Because it's obvious, although theoretically it should only be efficient if there is a motivation (Zachman, again) to make that process efficient. The same applies for security. An application should be secure, because it's obvious (for us). Theoretically however, a motivation to make the application (or business process, or data, or infrastructure, for that matter) secure should exist.

To end with a quote from the authors of TOGAF:

Security concerns are pervasive throughout the architecture domains and in all phases of the architecture development. Security is called out separately because it is infrastructure that is rarely visible to the business function. Its fundamental purpose is to protect the value of the systems and information assets of the enterprise.

A quote, which reminds us that security IS in fact important to enterprise architects and the corresponding frameworks. It's just not part of the general classification (business, data, application, technology). Of course, if your question was "Why doesn't an enterprise architecture care about security?" or "Why do EA-methodologies never talk about security?", I would have disagreed completely with you, because they (I) do care, and the methodologies do talk about security.

Now, while wrapping up this answer, I noted that I actually didn't answer your question directly. Therefore one last sentence: there are benefits to include security as a main concern during EA development, and enterprise architects should already know about these benefits. It is just one bridge too far to include it as a separate discipline next to the four well-know sub-disciplines of EA.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .