Privacy – Security Versus Practical Usage.

Privacy has been an on-going issue with the internet, and with the last few years it’s certainly started growing back into the public consciousness once more. But the one thing that does seem to be a key consideration that doesn’t always get recognised is the balance between the security needed to provide online privacy versus actual ease of use of online applications. To truly have privacy, you need security. You need secure connections, you need security to protect your computer’s identity, you need security to stop people reading your email and detecting your web usage. But, the more security methods you have between sitting down and using the internet, the less likely you are to do so on a whim.

Consider the way various email encryption programs have been hailed as a saviour of privacy over the last few decades, but then swiftly fizzle due to the complications of actually using them with minimal effort. People will say they want their privacy, but they also want to be able to just turn on their computer, open their email and send one. If suddenly they have to take another dozen steps to make sure the person they’re sending to can read it, while making it difficult for others to do the same… People crave ease of use.

So unless we can develop the security measures to work in the background or as part of one or two simple mouse-clicks, those measures will never survive a large percentage of the population using them. They’ll either be used infrequently, or have a short craze before people get tired of going through a dozen steps just to send an email.

Thus, we need to find that balance. Practical usage means security that works, but without seriously inconveniencing the average user. If you don’t consider that aspect, it’ll only end up as another good idea that never breached that threshold of awesome

Posted in Uncategorized | Leave a comment

The Nature of Control

During a conversation about LRA with some associates, one matter that came up was on the nature of control within the system. Running with those thoughts, it does seem to beg that a function of control can be to rebalance weak effects.

The more you understand and can control an effect, the weaker that effect could technically be.

To run with some metaphors; if you know the precise point of leverage, you don’t need to be insanely strong to shift an object, know the structural weak-point and you only need to take that out to bring down the entire wall, the precision driver can speed down an alleyway without hitting all the cardboard boxes or glass panes being moved while the miami vice driver with no control will still reach the end of the alley but will plow through everything on the way there…

Control - you don't always need a hammer...

Control – you don’t always need a hammer…

I’m sure you get my point.

So the question it calls into is whether Control should be a generic effect, or firmly linked to every effect.

Hm, or that that control can’t just be used to rebalance weak effects, but it can be used to reduce the amount of that effect that has to be reached to achieve the critical effect.

Which could be helpful for budgets when you can fine tune that you only need a few taps from a hammer to get the nail in, you don’t need a fully pneumatic sledgehammer to drive it home and that optical gaming mouse barely needs you to move your wrist to headshot the freak in that latest fps..

It’s one of those fun things in the world, speed without control is quite dangerous, strength without control can be just as bad. So in systems engineering and identifying all those critical effects, if you don’t have some control included on those effects, what will you have?


Posted in Uncategorized | Leave a comment

Requirements – what should they cover?

If there is one area which I feel I’ve become stronger in over the last two years it is requirements and requirements capture.Yet paradoxically I feel it is the least well handled in my experience.

You won't get this unless you play Borderlands 2. A lot.

A pony made of diamonds!

Concepts are often quite clear, and usually about as coherent as may be expected for any given system. Logical architectures have all sorts of standards. But requirements seem to be more about controlling risk than delivering good engineering value.

So, what then is the correct way to handle it? I understand good requirements as serving two stakeholders:

  1. The Senior Responsible Owner for the project
  2. The team responsible for the system’s logical architecture

These stakeholders have many needs, but two salient requirements for …er… for their requirements.

  1. The SRO must be able to negotiate, and this means doing trade-offs between requirements.
  2. The logical architecture team want to turn the requirements into a model of objects, procedures, and people, and the relationships between them. The more the requirements reflect these types of data the easier the job gets.


Posted in Uncategorized | Leave a comment

Systems engineering – the right way

Referencing yesterday’s post, what makes systems engineering the right way to conduct project management?

Well, my opinion is that SE delivers:

  • A project in discrete risk-controlling stages, with useful auditable outputs at each stage
  • Outputs are of recognisable (if not completely open) standards, protecting both client and contractor
  • Project stages are logically coherent. They follow on from each other in a sensible way (if you are laughing at this then you’ve probably not had to conduct a project for a large enterprise)
  • If each stage is completed successfully and to a high standard, then the subsequent stages become easier and lower risk

I’d like to think that in my own work I add an additional warning and beneficial outcome

  • Requirements (an early stage) are traceable from a strategic level within the client, and are not gathered piecemeal at operational or tactical levels

If requirements are not anchored at the strategic level, then their coherence can end up being very poor. This introduces serious risk to the success of later stages. What might seem abstract soul-searching is actually very important for the practical meshing of gears when all agree it matters.

Posted in Uncategorized | Tagged , , | Leave a comment

Why use systems engineering for project management?

Having set the Defence of Requirements Drift (or whatever I called it) to one side several months ago, I’ve been in a quandary. Although I feel I’ve got a fair bit of systems engineering (SE) experience under my belt, a lack of recent practice has got me thinking about the fundamentals once more.

The biggest fundamental has to be “Why Systems Engineering?”

This naturally breaks down into the eternal three reasons: Right thing to do, in the right way, for the right price

Probably the strongest argument is that SE is doing things in the right way. Whether it’s the right thing is going to be context dependent, and the right price is whatever the client can afford (and with the correct risk and so on).





Posted in Uncategorized | Tagged , , | Leave a comment

Well, it amused me, weekend nonsense 1

I’d stay out of the bushes, if I were you.

Posted in Uncategorized | Leave a comment

is “Logical effects architecture” logical?

We’ve been kicking around different names for OSS for some time now.

The last time I commited on paper I came up with the idea:

Logical Breach Modelling

Breaching. Looks exciting, doesn’t it?

The idea being that in the same way that the modelling finds gaps for committing research into, or vulnerabilities for focusing damage on, breaches are all about breaking something intransigent.

However, I’ve been pondering today how closely aligned OSS – I mean Logical Breach Modelling – is to UML. And if we are to align with it better we should probably use a name that is far less exciting.

How about “Logical effects architecture”?

Posted in Uncategorized | Tagged , , | Leave a comment


I note with interest this recent analytical release from Aspire Europe:

To paraphrase their key findings:

  • ‘Only’ 9% of respondents use agile for more than half their projects
  • A drop in training and development as part of budgets
  • PMOs are being used at higher levels, and are better regarded

Naturally, Aspire put a positive interpretation on this. And one can see good cause to be pleased that PMOs are achieving their goals and presumably being approved of as a consequence.


PMO the father

I am as keen on PMOs as the next man. They give form to chaos, and most plans I see these days bear a healthy resemblance to the principles of good systems engineering.

However, I can’t help feeling that the phenomena highlighted are more indicative of risk averse and generally ‘feart’ behaviour.

Being a PMO is more than just processing serenely through a series of waypoints. The waypoints are how you can tell things are going right or wrong. they are not what is going right or wrong in and of themselves.

PMOs have to retain both flexibility and a long term view, playing their part in the larger organisation. This means to my mind that we should see more use of Agile (where appropriate to task), and consideration of the importance of training.



Posted in Uncategorized | Tagged , | Leave a comment

Security capability – basic

Overheard a chap at lunch talking about how worried he was regarding the ‘threat’ posed by social media to his business. So I thought I’d remind readers of the ‘five R’s.

If you wish to be satisfied regarding threat, ensure you possess five ‘R’ capabilities:

1. Resist
2. Realise
3. React
4. Repair
5. Riposte (OK, counter-attack)

No, seriously, you don't

True fact about the seaslug: you don’t want to be a seaslug

The sea-slug has essentially NONE of these characteristics.

EDIT: rather embarrassingly I’ve given an out of date list of the 5 Rs above. I’m going to leave it extant, to remind me to double check these things.


The list should have read:

1. Resist

2. Realise

3. Repair

4. Rebalance/recover [which term you use all depends on how well you understand the principles of OSS]

5. Riposte/counter-attack [ditto]

The entire process is reaction. Rebalance/riposte is the process whereby one accepts damage to one’s own system, and changes the one uses it by emphasising different capabilities to the ones damaged. Still acheiving your goals.




Posted in Uncategorized | Tagged , , | Leave a comment

Quotation – transition of effect

“It is often said that when an effective Israeli leader speaks he does so using all three tenses at once: past, present, and future. In doing this he is relating Jewish events in the past to the present [seeking legitimacy] while keeping an eye on the future problems and challenges that lie ahead for the state.”

Why Blame Israel? Neil Lochery (2004) – referencing Ian MacIntyre The Proud Doers: Israel after 20 years (1968)


Posted in Uncategorized | Tagged , , | Leave a comment