Drivers, Goals, Objectives, Constraints and Concerns

All strategies should start with a vision set out either by a necessity or visionary inspiration. Whether the trigger behind the vision is based upon a new senior role, restructuring, repositioning or survival the vision needs to be qualified through the drivers, goals, objectives and any opposing aspects such as issues, constraints or concerns. A vision needs balance and cross examination before it moves to any further formality. A cyber security strategy is no different however it has one further aspect to challenge it and that is the threat which is faced. That threat needs to be broken down into its many parts and actors to fully understand the magnitude, diversity and expertise behind it. A threat assessment needs to cover enough to meet the size and scale of the vision and is also there to make sure that the drivers and goals set out the right means to mitigate and manage the threat in the future, as that will generally unknown until some event or evidence appears to define it.

To compliment the threat assessment it is also necessary to conduct more general business assessments of capability, architecture and operations to build an up to date view of what, where and how the organisation is functioning. The larger the organisation the bigger the assessment view will be and the level of detail is questionable as that will depend upon resources and budget available. The business assessment should be in proportion to the size and scale of the strategy and vision. There are also a number of general standards and practices in an organisation that either have produced or must produce assessments to meet legal or regulatory requirements and these should be a starting point.


Cyber Security Strategy Drivers, Goals & Objectives
Cyber Security Strategy Stage 1 – Drivers, Goals & Objectives…

Preparation for a cyber security strategy

A second important aspect of business design and modeling for a cyber security strategy is the extension capability within TOGAF metamodel and the extend feature of UML use cases. Both allow supplementary relationships to be built around the primary concepts and building blocks. This is very important as cyber security strategy development is unlike a normal business strategy. Yes there are many common features but due to the complexity and often unknown threat and risk, the strategy has to be designed to adapt and evolve where the risk and threat is greatest. So engineering the right capabilities is crucial to ensure people, process and technology coverage is sufficient. Too often the common mistake is to identify technologies up front before it is clear what is required and how they need to operate. Generally this is the reason why historically a lot of SIEM or security technology deployments have been so problematic. A SIEM and other security technologies are selected before the right business and operational capabilities are in place to govern and manage them correctly. On top of that many SIEMs have been deployed without the right due diligence and assessment of security controls or architecture and IT operations. If you don’t know the environment your SIEM is going to protect then it is unlikely you will know the right data architecture and data collection needed.

Over the next few articles i will explore each stage of a cyber security strategy and will begin with the most important part – the threat and risk assessment. Know your enemy, their motives and why they are targeting your organisation and at the same time get to know your organisation, its architecture and vulnerabilities. The AsIs and current operating model is fundamental before you begin to define your targets.


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.

What the evidence ontology should support.

In a nutshell an enterprise architecture is a collection of facts about the organisation’s current architecture, a development methodology supported by a collection of artefacts and a model of the organisation’s future architecture. On top of that there are the capabilities of the people, processes and technologies that make up the organisation that defines what it is and what it does. An evidence based approach to enterprise architecture requires evidence in a variety of types and to varying degrees of detail to support all of the above.

The current architecture is primarily a collection of facts that have been built up, depending upon how recently the organisation has adopted enterprise architecture, under varying amounts of decision making and control. Information can and should exist about how the current architecture is operating and performing and to what level of satisfaction and success. This information can be formulated to represent existing evidence and therefore provide support for future decisions about change.

The future model of the organisation is a set of concepts that offers a new view of the organisation depending upon the scenarios it envisages. The model and concepts will evolve and impact on that evolution. The degree of possible change will depend upon how far in the future the model is set, the maturity of the strategies and organisational decisions. there will also be unexpected impacts on the organisation and on the strategic direction. This future model is dependent upon an architectural development method to deliver the new version of the organisation as well as the capabilities and tools to support it. So it is important that the evidence ontology is able to support the following principles:

  • The evidence ontology needs to be able to support the internal content behind new views and scenarios as well as incorporate evidence from external sources.
  • The evidence ontology needs to be able to bring together a variety of research to strengthen hypotheses and recommendations in the artefacts and methods used in the architecture development method.
  • Finally the evidence ontology needs to be able to support the formation of an evidence knowledge base that is flexible to help the engineering of future organisation models.

Enterprise architecture development method – principle 2

Each architectural framework (TOGAF, MODAF, DODAF, FEA) has its own development method that describes how to construct and deliver an architecture of the organisation from their prescribed artefacts. Perhaps it is just taken for granted that architects will research and use evidence where appropriate to justify their views and recommendations.  Yet  those methods i have used and have researched (i am not knowledgeable on all architecture methods) do not factor the concept of evidence application in their approach. So for principle 2 i am recommending that by adopting evidence based enterprise architecture it requires an addition to the governance and methodology to include activities that encourages research and application of evidence to support decisions, hypotheses and recommendations.

Principles of evidence based practice

Before i expand on the principles of evidence based enterprise architecture it is important to highlight the work behind evidence based practice and in particular the wikipedia page on the subject. Evidence based enterprise architecture is just another evidence based practice and as such it shares all the common features and benefits. Evidence based practices now cover a wide range of subjects such as health, education, management and design. The wikipedia page offers insights into methods and strategies as well as background information. I want to cite three sections from the wikipedia article as i think they set out a good foundation and I will then adapt these to fit the context of EBEA.

Source: Wikipedia Evidence Based Design


In the first instance EBD methodology could be divided in four subsequent steps:

  • reviewing existing research literature to select significant findings and recommendations;
  • matching referenced findings with data gathered from site visits, surveys results, subject matter experts;
  • prediciting the outcomes of design decisions;
  • tracking the positive outcomes for design implementation.

Meta-analysis template

In his book “Evidence-based Policy: A Realistic Perspective”, Ray Pawson (2006) suggests a meta-analysis template that may be applicable for EBD. By using such a protocol the field will be able to provide designers with a credible source for evidence-based design. Systematic review process should follow six essential steps:

1. Formulating the review question
2. Identifying and collecting evidence
3. Appraising the quality of the evidence
4. Extracting and processing the data
5. Systematizing the data
6. Disseminating the findings

Conceptual model for the application of Evidence Based Design

Hamilton (“Four Levels of Evidence-Based Practice”, The AIA Journal of Architecture, 2006

  • Level 1
    • analysing the literature in the field in order to follow the related environmental researches
    • reading the meaning of the evidence in the relationships to the project
  • Level 2
    • foreshadowing the expected outcomes of design decisions upon the general readings
    • measuring the results through the analysis of the implications, the construction of a chain of logic connection from decision and future outcome, in order to reduce arbitrary decisions
  • Level 3
    • reporting the results publicly, writing or speaking about results, and moving in this way information beyond design team
    • subjecting methods and results to others who may or may not agree with the findings
  • Level 4
    • publishing the findings in reviewed journals
    • collaborating with academic or social scientists

I think it is very clear from the quotations above that evidence based practice can be applied to a range of activities within enterprise architecture using these core principles as a guide.

Supporting alternative decisions

The alternative options are often dependent upon the type of goal an organisation is aiming to reach as well as the situation the decision maker is in. Here perhaps is an important area for evidence either to prove that the original decision is the best choice or show that an alternative is better. Alternative decisions in enterprise architecture often centre around technology choices, which product is the best fit and stands out from the others that have been considered. Product evaluation can be a lengthy process and can primarily be based upon a set of requirements issued to each vendor. The vendor which best meets the requirements and provides a cost within budget is most likely to be the winning contender. Yet does the evidence show that the product and the vendor is the best choice.

The evidence framework to support the decision making process behind this type of decision should depend upon the size and impact of the strategy or goal. If the goal is to introduce a new organisation wide application then the evidence framework needs to be broad enough to enable detailed questioning of key capabilities and situations. Using the example of a important goal of purchasing a new organisation wide application, which will impact a large number of employees and departments, then evidence should be gathered on the following:

  • The current situation of the vendor; its financial position; company size and number of clients; expertise of key staff or board members; company locations – nationally and internationally; history of the vendor and its relationships with other organisations, partners, standards bodies and associations.
  • The vendor’s product and its position within its product portfolio; history of the product; awards; key clients, case studies and reviews by organisations such as Gartner, Ovum or Forrester.
  • How has the product been received by other customers; the trade press and internet forums.
  • The development process behind the product; who are the key designers and innovators behind the product; the vendor’s product position at trade conferences – how often and at which conferences does the vendor exhibit and make presentations?
  • Product capability and technical requirements; documentation and training programmes
  • Product support and service management capability; field staff numbers and support lead times.

This list is just a set of examples of topics that should be gathered as an evidence framework for each vendor and then compared against the enterprise architecture and at each architectural level. This is to determine how each alternative product will fit within the architecture and its impact on existing structure. This may seem like a lot of effort to gather all of this information but this type of evidence gathering my highlight that an alternative vendor to the main contender is a better fit for the organisation even if it means a higher initial cost. A decision based on requirement fit and cost alone may turn out to be a bad decision in the long term.