What “Requirements” look like

In my last post I covered the EA process as a whole: today I want to give an example of one key document, the Requirements.

One of the things I love about the Gartner approach is that you can use it to architect almost anything: it can be a heavyweight programme design or a lightweight heuristic for for simple problems. I apply it here to the issue of enterprise security because that’s what I’m doing – and so, without further preamble, here is a summary of our (draft) Security Requirements Vision.

The security programme must:

1. Provide a secure infrastructure to staff, partners and the general public

2. Provide a security SOA layer

3. Enable secure collaboration between staff, partners and public

4. Enforce secure access to buildings, systems, and information

5. Build trust with the public, staff and partners that their information is safeguarded

6. Design and build proactive security management systems

7. Enable strategic governance of security

8. Enable the management of information as a corporate asset

9. Secure consolidated information to deliver a Single view of the customer

10. Define and communicate agreed protocols to share information

11. Promote clear, effective and regularly used channels of communication

12. Implement training standards for all staff

So how did we get to this point? Well, these requirements have been adapted from the Common Requirements and Solutions Vision created by our EA programme. These were, in turn, created by basically going out and talking to the business about where it wanted to go and mixing that with input about Environmental trends and looking at existing business strategies. (Note: The Security requirements have yet to be signed off by the business, they are just here as an illustration and may well change over the coming weeks as we talk to key stakeholders about them.)

These sound a bit like motherhood and apple pie: they are very high level and people tend to look at requirements and think “well, that’s obvious”. That is absolutely the right thing in my view as they are a tool for ensuring that all the work to come is grounded in stuff that everyone agrees on. Architecture development can get quite esoteric, especially on the technical side – this ensures that we all remember why we’re doing it.

The next step after that is to create a set of draft security principles, models (think ISO 27001/2) and move towards defining the future state – where we want to go.