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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: