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.

So what does an “enterprise architecture” look like?

Hello! My name is Martin and my particular role in the team is to produce a security layer that will overlay the rest of the EA programme. To do this, of course, we need to know what the EA as a whole will look like. I also need to answer the question I now get asked most often: what does an Enterprise Architect do? So I want to take a short tour through the process of creating an architectural model.

I see EA as being a branch of strategy: a classical strategy formation process weighs the strengths and weaknesses of an organisation against threats and opportunities in its environment, and an EA effort is like a technology-enabled extension of this. I expect that most top-level strategy people aren’t necessarily totally up-to-date on the latest technology trends and what they might do for their businesses – EA can close this gap.

All strategic planning seems to entail the formulation of a vision that sets out where an organisation wants to be, where it is now, and a plan to get there.

formal strategic planning process

We are using the Gartner model: other models exist but they all seem to end up in the same place. This view captures environmental trends and existing business strategies to create a set of requirements stating what the business needs to achieve and – in a large and diverse organisation such as ours – focusing on the common factors of this across all parts of the business. As Sue has alluded to in her previous post, we have created this “Common Requirements Vision” document through conversations with some of the leading strategy people in our organisation.

The next step also parallels some strategic planning models in that it looks at Principles. This is analogous to a set of corporate values but in our case they focus on the use of technology. An example of a principle could be something like “secure information and systems to gain public trust” – something quite close to my heart – and we have about 10 principles at the moment, although this work is still ongoing.

The final piece in the jigsaw of the top layer of this process is to develop models. At this level the model describes two things: what is or is not included in the architecture effort (we generally want to include areas that are common to the whole organisation, such as authentication and collaboration systems, and exclude line of business systems) and how we might slice up the enterprise (for example into business, information, and technical views).

These three items – requirements, principles, and models – together form a vision of the future enterprise. In Gartner terminology, this is our “future state”.

The views developed in the models phase each have their own requirements, principles, and models, future and current states, making the whole architecture like an onion progressing to greater and greater levels of focused detail.

EA process