Enterprise Architecture and Cyber Defence Ontology

Having not had the opportunity to continue this blog and the theme of using semantics to develop the evidence based enterprise these last few years i am going to begin again with a new area of focus. The focus will be a series of posts and models covering Cyber Defence and Enterprise Architecture, an area i have been working in these last four years. I am going to start with some basic principles to cover what i will exploring:

  • Enterprise Architecture patterns (including conceptual models, building blocks etc) represent the basis for evidence based EA
  • A pattern should have a specification and qualification, at a minimum a metamodel or an ontology to provide that specification and qualification
  • Evidence, broadly construed, is anything presented in support of an assertion. This support may be strong or weak. The strongest type of evidence is that which provides direct proof of the truth of an assertion. (Wikipedia Definition)
  • Evidence should be derived from domains within the organisation through recorded instances and lessons and classified through domain ontologies.
  • EA patterns qualified by ontological models creates an evidential design process

So i am going to use an Enterprise Architecture Ontology, a Cyber Defence Ontology, a Security Ontology and an ITIL Service Management Ontology to provide the qualification and the guidelines for evidence within architectural patterns. So an ontology in the context of an architectural guideline or pattern representation is a specification of conceptualizations (from enterprise architecture and security domains) that constitutes evidence-based architectural practice. The evidence would be drawn from security frameworks or security operations demonstrating where weak or vulnerable architectural solutions have failed to prevent a cyber attack.  For example, an architectural guideline or pattern would define a set of key concepts,  decisions and actions (also concepts), as well as a set of rules (relationships) that relate the evaluation of a security decision criterion to further reasoning steps or to its associated actions. Thus enabling security restrictions or policies to enhance an architectural pattern (through Architectural and Solution Building Blocks) and improve the security aspects of a physical deployment of the future solution.

I have attached to this post a series of high level images of the Ontologies and SKOS models i will be using. The service technology model is an example the integration between the Cyber Defence Ontology, the Enterprise Architecture Ontology and the ITIL Ontology. At a high level it shows the relationships between the controls of the enterprise technology architecture, which defines the product, supplier management with a supporting actor of Security Operations, SOC supplier management and the deployed product used by Security Operations. At a further level of detail the three ontologies are able to show the interfaces between the three distinct business units (Service Management, Security Operations and Enterprise Architecture) thus providing an operating pattern for their interaction, collaboration and in particular the incident and change management processes necessary for in-life support.

Cyber SKOS

ITIL Ontology

Enterprise Architecture Ontology

Srvice Technology Model

Security Framework Ontology

Cyber Defence Ontology Model

Zachman Enterprise Ontology

It was interesting to read today that the Zachman website has now published the Zachman Framework Version 3 and refers to it as an enterprise ontology. Here is a quote from the website:

The Zachman Framework™ is an ontology – a theory of the existence of a structured set of essential components of an object for which explicit expressions is necessary and perhaps even mandatory for creating, operating, and changing the object (the object being an Enterprise, a department, a value chain, a “sliver,” a solution, a project, an airplane, a building, a product, a profession or whatever or whatever).

The Zachman Framework™ IS NOT a methodology for creating the implementation (an instantiation) of the object. The Framework IS the ontology for describing the Enterprise. The Framework(ontology) is a STRUCTURE whereas a methodology is a PROCESS. A Structure is NOT a Process. A Structure establishes definition whereas a Process provides Transformation.

Processes based on ontological structure will be predictable and produce repeatable results (for example, Chemistry, based on the Periodic Table).

It is quite an announcement to make that the framework is an ontology and i hope a formal OWL or Frames based model will follow. For more information visit Zachman.com

Article – evidence based management and productivity

Here is an interesting article on how evidence based management can boost productivity.


What i like about this article is the fact that the research team found that those companies, using data driven decision making, had output and productivity that was 5-6% more than expected. There is also a link to the full report.

An evidence based enterprise

Is the enterprise of the future an evidence based enterprise? It is an interesting question and as the number of business functions exploring an evidence based approach grows, then perhaps there will be a tipping point towards its acceptance.

Every organisation has a different view of how technology can influence how they do business. Perhaps this is best explained using the old term from the late 90s when enterprises were either Bricks and Mortar or Dot Coms. Whilst this does not mean that one is more or less likely to adopt evidence based practice a smaller more agile organisation should have the advantage because their thinking may be more progressive.

I think the adoption will depend upon the type of organisation and the culture it instills. Technology has the ability now to communicate with every single person in an enterprise, no matter how large it is, via email or the internet. Thus, it has the ability to deliver information to every person so that they can use it to perform the activities they do. Therefore technology is able to put evidence in the hands of everyone that makes a decision. So a culture that exists with the belief that evidence is important combined with a pioneering view of using technology in the workplace, like the dot coms, should be better placed to leverage information and technology to make better decisions.

The method behind evidence research

Conducting research is an undertaking to find answers and evidence to a question, problem, change or goal. It should be considered as a formal process that is support by some business rules but more importantly applies both qualitative and quantitative methods to provide valid, reliable and accurate findings. The findings should be unbiased and objective and presented in a away to allow consultation and verification by others.

Research has it application in several parts of enterprise architecture. Firstly and probably most importantly is the finding of evidence to support the strategic vision and goals for architectural development. Secondly as a means to endorse each stage of the development method by providing evidence to underpin target architectures and finally in the development of opportunities and solutions.

A method for research needs to be formal enough to qualify the findings but not to encumber the architect. There are however certain activities that should be followed to give validity to the research work.

  • Controls should be applied to provide boundaries and focus the effort.
  • A systematic process that breaks the effort down into precise stages.
  • A consultation process to allow critical reviews of the findings.
  • The means to provide an empirical conclusion in the form of a structured report that disseminates the information appropriately.

Research fundermentals

Perhaps a question i need to answer first is, why should an Enterprise Architect conduct research? And the simplest response is that they need to carry out research to find answers to problems, find answers to build strategies and to examine critically the challenges and changes they are faced with. They need the answers and the evidence to build better, more efficient and more effective organisations for the future.

As a skill, research should be a an important part of an Enterprise Architect’s way of working. It is a way of thinking, observing and examine things critically and using the evidence to be sure that the designs and decisions made are  valid. Research can take many forms and in this case I  am not talking about the kind of research on a specific topic in academia that may take many years to evolve. I am talking about taking the fundamentals of research and applying them to work within the key constraints of most organisations, time, resource  and money, to be as effectual and beneficial as possible. This means seeing part of the development of an architecture for an enterprise as perhaps a research project itself.