Badly Designed Hardware

Despite the name, Walton Radar Systems did more than radar — it did all sorts of custom systems (1 offs and more) for all sorts of applications. One of the more interesting areas was replacement peripheral systems for obsolete legacy computer systems at various nuclear power stations.

That little picture above shows the extent of the interface timing information Walton was given to help it design replacement equipment for the Ferranti Argus 400 computers at Hartlepool and Heysham nuclear power stations. I've re-drawn it of course, but it's pretty accurate (it's not as though there was a lot to forget) — even down to having the appearance of a slightly blobby photocopy.

Apart from the nominal width of the two strobe signals  (measured where, top, bottom or half-way?) there was no other information at all — no rise/fall times, no timing tolerances, no voltage tolerances (I don't think there was even a voltage scale, you just had to know that the nominal voltage was 4.5V). No nothing... and from this Walton was supposed to design a display replacement system.

The existing computer displays in the control room were cursive displays, which is to say that information was drawn on the screen by moving an electron beam as one would move the tip of a pen, lifting the tip as necessary between repositionings. The problem (the problem?) was that the monitors required careful and frequent calibration lest the inevitable drift in the gains and offsets of the various analogue amplifiers turn Roman text into Elvish. (The borderline between Roman and Elvish script was a little hazy; I distinctly recall seeing reactor operators reading screens illegible to me without any apparent difficulty.) Another problem was that the writing was spidery, unpleasant to look at, and, of course, everything was monochrome.

The Central Electricity Generating Board's R&D division had investigated the possibility of replacing these displays with modern raster graphics — gasp — and maybe even adding colour. They decided it was impossible.

Walton's technical director, Eddie Richardson, disagreed and for a modest consideration offered to build a prototype display replacement. In hindsight, Eddie's trick was blindingly obvious: whilst there was no way to decode the signals that drove the monitors and turn them into raster graphics, if the graphics instructions were intercepted, the mapping from cursive stroke programming to characters and lines etc. was pretty straightforward. All we had to to was intercept the data from the Argus data highway (an old fashioned  term that lost out to bus in the evolution of English, even though a highway is the thing along which vehicles travel and a bus is a vehicle; not doubt the computer usage of bus is due to the American verb to bus).

Given the paucity of the reference information available the scope for design error was enormous, so Geoff Allan (Walton's Chief engineer) and I decided that we should work separately so as not to compound  our inevitable errors: he would design the interface hardware and I would design an Argus 400 emulator; we would both take our own measurements from a real system and interpret documents independently. — and we wouldn't talk to each other about the details of each our designs. The idea was that, where there were ambiguities in specifications or measurements, being rather contrary people, our conflicting interpretations would hopefully lead us to effort directed at reconciling our differences and clarifying how the Argus actually worked.

Hence The QARGIF — the Q-bus to ARGus InterFace. Walton's conservative design principles were thrown largely thrown out the window as far as the QARGIF was concerned, at least at the actual interface level: I made the bus drivers push and pull too much current, completely failed to provide sufficient 0V connections and refused to allow any noise reduction measures in the cabling — no twisted pairs, no shielding. It was the noisiest, most potentially unreliable and nasty interface I could make.

When Geoff's prototype interface was ready we hooked the two up and of course the system as a whole failed to work beautifully... but we resolved the issues and when the finished prototype was taken to site and installed in an Argus it worked first time. 

Subsequently Walton then replaced all the displays, and with that success under its belt set about replacing the aged Burroughs disk drives with solid state memory... and thereby hangs another tale. But, the QARGIF was there through it all, and despite the occasional apparently bizarre behaviour of a system under test, in about 20 years of use it has, apparently, never gone wrong.

Not bad for a piece of badly designed hardware.

Read more...

Computer Batteries

You may think the only role for a battery in a computer is to keep your laptop running without access to mains electricity (unless you know abut the little batteries on motherboards too...) but you'd be wrong.

Once upon a time — after relays and valves but before IC's — computers were built not with transistor only logic but with diode-transistor logic (DTL) and RAM was not semiconductor based at all but built from little tiny coils of copper wire (actually knitted or sewn by knitters/seamstresses).

And once upon a time you couldn't start a computer like a Ferranti Argus 400 (a core store module from which is shown above if its battery was flat (photo by adewale_oshineye).

Yes, I know this from first hand experience with an obsolete Argus 400 being disposed of by Tioxide in Hartlepool.

We actually had to jump-start it... with jump leads and a car battery. So... progress of sorts.

Read more...

Negotiating with Jet Lag

I'm summoned to South Korea for a meeting with Samsung, the prime systems contractor for a new South Korean Navy ship. Ferranti had been subcontracted to supply (amongst other things) radar equipment, but at a meeting the previous week Samsung had asked them about "the radar recording equipment." A hurried check of the contract then revealed that Samsung had forgotten to include it in the requirements... but they still wanted it. The only problem was — a standard negotiating ploy — they had no budget for the extra equipment (not that it was very expensive in the grand scheme of things).

So off I set. South Korea is +8 hours with respect to the UK so normal business hours in Seoul are murder for new arrivals.

"Whatever you do, don't have any meetings between noon and mid-afternoon," a Ferranti chap helpfully advises in the hotel bar, "you won't be able to concentrate and they'll walk all over you."

I nod sagely, but before I can say anything in reply up walks Ted, the Ferranti account director, still looking very much the worse for wear after a heavy soju drinking session with the client the night before, one eye seemingly shrunk to the size of a pea — such are the peculiar effects of too much soju.

"You made it! Good!" Ted beams, his one good eye almost seeming to twinkle. "I've arranged the meeting for twelve o'clock tomorrow...."

And so it was that at noon the following day, barely able to keep my eyes open (being then 4am as far as my body was concerned), that I sat down with the intentionally inscrutable Koreans to negotiate the sale of some radar recording equipment, for which they claimed to have no money. Ted had helpfully told me that these Koreans were particularly difficult to negotiate with as they had learned how to overcome the threat of "loss of face" — "I cannot accept this... I will lose face badly for this failure, but I would lose more face if I accepted your proposal." How helpful.

The only other piece of advice I received before the meeting was "Watch out for the silences — they know they make westerners very uncomfortable and tend to lead them into offering concessions they shouldn't make, just to break the silence." I nodded sagely — or sleepily, I can't recall.

And so it was that after various courtesies and formalities, the technical discussions and then the negotiations began. I made my offer, they wanted a discount. What did they think was worth a discount? The promise to buy more equipment "later". No deal — at least not like that. I knew the finance problem was with the first delivery, so I offered to reduce the price on the first if I could add the discount to the second and so maintain the nominal total price.

Silence. A very, very long silence. I raised my eyes to the portrait on the wall. I let them rest there... and promptly fell asleep — fortunately with my eyes still open.

Sometime later, the Koreans started talking again and I placidly rejoined the conversation. There was more haggling, but I was too tired to do anything than out-stare them. A deal was done — on my terms.

"You handled that very well, especially the silences," Ted said on the way out.

"I fell asleep," I told him.

"Whatever works!"

Read more...

Recommendation: "Great Results, On Time, Creative"

"Julian worked for me developing an approach to architecture modelling and implemented the approach in the defence procurement environment. His creative ability was second to none and lead to successfully solving a number of business and technical challenges. A thought leader with the ability to work alone or as part of team, Julian can be relied on to provide novel and successful solutions.

Top qualities: Great Results, On Time, Creative"

Peter Burge, February 18, 2010 (hired Julian as a IT Consultant in 2005, and hired Julian more than once)

Read more...

Enterprise Architecture

If you look up "Architecture Framework" on Wikipedia you will find that it is a "layered" approach to Enterprise Architecture. Referencing an American document, Wikipedia explains:

Contemporary federal guidance suggests thinking about “layers” of the enterprise architecture:^[9]

• Business processes and activities
• Applications such as custom or off-the-shelf software tools
• Data that must be collected, organized, safeguarded, and distributed
• Technology such as computer systems and telephone networks

I can however tell you from personal experience that whilst you can do enterprise architecture within such a framework, the results are neither pretty nor particularly illuminating (though I have to say that the sheer size and complexity of the resulting architecture can be pretty impressive); which is a pity because architecture done properly can be not only impressive to look at but also tremendously valuable.

The problem is that the layers (not to mention possible domains and sub-domains) are fuzzy, ill-defined and certainly not orthogonal, i.e. they are not mutually exclusive (suppose you are downloading an application... is it not also data?)

The impossible-to-overstate issue with this is that different modellers, constrained perhaps by the capabilities of different toolsets or pre-existing organisational perceptions, can — indeed usually will — model the same thing in completely different ways.

Such inconsistencies make it much more difficult, time-consuming and expensive to exploit models from diverse sources by combining them into a larger whole, and make interpretation by outsiders.

I discovered some of the problems when I began doing architectures for UK MoD (using ISSE). Try as I might I couldn't see how to divine the correct model element and layer. Certainly there were established practices and reasonable reasons for doing things in a certain way, but there were equally good reasons for doing things differently, nor could I see how the seemingly inevitable ambiguities could be resolved so that all the pieces would ultimately fit together and add significant "value".

When it became apparent that there was a genuine problem in the approach, rather than merely a problem with understanding and implementing a sound approach, there was at last a reason for throwing away the old "Reference Architecture" levels and doing things differently.

As the (habitual) iconoclast I had to persuade, nay demonstrate, to the senior and far more experienced members of that little team (Gary Davies in particular) that there was a better way. Eventually however there was a collective sigh of relief and things rapidly improved: we were soon able to create larger, more sophisticated and more meaningful models that could be quickly and easily joined up to make very large and complex architectures.

However, at some point UK MoD decided to create its own Architecture Framework (MoDAF), which was heavily influenced by the US DoD's architecture framework, DoDAF.

At that time, MoDAF, DoDAF and indeed every other formal system I looked at, whilst a great improvement upon their predecessors continued to suffer from the same general lack of orthogonality in classification as the layered approach. However, the interest in ontology (basically the science of classifying things) has steadily increased since then, and to judge by a cursory examination of some of the work of the IDEAS (International Defence Architectures Specification) Group, sense and logic is slowly prevailing; IDEAS Group thinking has significantly influenced DoDAF V2.

It is, I think, all heading in the right direction at last: arbitrary distinctions between "functions" and "services", "specifications" and "rules", etc. are slowly being transformed into nuanced yet logical and meaningful distinctions.

However, having just dipped into the latest MoDAF specification I can still find plenty of room for improvement — but don't the deficiencies of current approaches deter you from making use of architectures: executed with care they can be very, very useful... but don't ignore the caveats either.

Further Reading/Browsing

DoDAF Information (including manuals in PDF) is available at the DoD website here; or at Wikipedia here.
MoDAF At the UK MoD here;or at Wikipedia here.
IDEAS Group here.

Read more...

The Head Count

An agency calls and asks whether I can do UML modelling. I look it up... it's just "a formal language" so I say, "Yes, I can probably do that... but do tell the client I haven't actually done it before..."

Some time later I am called for an interview and after driving half-way across the country I am met by a specialist in UML modelling. Twenty minutes later it's all over.

I am direct, but polite.

"It seems to me this interview was very brief, so I infer that either you have already decided that I would be completely useless or that I would be perfect for the role — but either way no further discussion is required — yet you haven't said whether you think I would be suitable or not. Can I ask what your assessment is?"

"Oh, it's not up to me... that's for Dr Burge to decide. I was only asked to check that you had the right number of heads."

Fortunately, one head was the required number and I then spent two years doing architectures for Peter Burge and UK MoD (during which time UML was hardly ever mentioned).

Read more...

Business through the Looking Glass of Evolution

Or, the How Fast and Where To of Running

Here, you see, it takes all the running you can do, to keep in the same place.

The Red Queen, Through the Looking Glass, and What Alice Found There

In which we consider how evolution works, how evolutionary ideas have been applied beyond biology, some related concepts in physics and computation, and synthesis an approach to business success.

Keywords: Branding, Product/Service Differentiation, Competition

Introduction

It's a jungle out there... an arctic wasteland... a searing desert... but life manages everywhere: it has evolved into every available niche. Whilst one might not think of organisations as living things, they are just man-made organisms in man-made environments — and however you look at it, it's a dog-eat-dog, big-fleas-have lesser-fleas, and a plenty-more-fish-in-the-sea world we have made.

Generations come and go, the fit survive, the unfit perish. What does it take to survive in the modern business world?

Answer: Intelligence — by which I mean the application of creative but rational thinking based on a clearer understanding of business dynamics at the most fundamental level. It doesn't matter what you do or make, your business has an environment — it's part of an ecosystem and you have to know how the system works and your place in it in order to flourish.

Ecosystems & evolution

An organism's ecosystem is everything that surrounds it and affects it - the physical environment (geography, topography, climate and weather...) and all the other organisms (predators, rivals, mates, food, shelter) it interacts with. It's complex and dynamic, but everything has found — or created — a place for itself through the age-long process of evolution.

The three standard, basic elements of Darwinian Evolution are:

1. Heritability of characteristics — progenitors influence the characteristics of their offspring
2. Variability of characteristics — offspring are not identical to their progenitors
3. Selection — not all offspring become progenitors (some fail to pass on their characteristics to the next generation); on average, the better an organism is at exploiting its environment, the more successful it will be.

What's usually overlooked however is the nature of the selection process. In many simple examples (and here I'll be extremely simple, possibly over-simplistic) such as Darwin's Finches, a particular characteristic, such as the shape of the beak, evolves to suit the environment: finches evolved particular beak-shapes to suit particular types of food (plant, insects, blood, etc.).

What is taken for granted in such examples is an effectively static environment. In the case of Darwin's Finches the life-cycle of the food source

In reality, organisms do not evolve independently of their environments and the rest of their ecosystems: they co-evolve — and on occasion an organism can be said to create its own environment.

Mankind has certainly created its own environment, but other organisms do the same, albeit on smaller scales. The beaver, for example, fells trees and uses them to build its lodge and dams, which provide protection against predators and corral its food supply. The beaver creates and maintains its own ecosystem — and since the lodge is accessible only from underwater, few others could get in and fewer still are admitted.

For most organisms however, deliberate alteration of the environment is not an option — they have to work with the environment as it is. However, the direction that evolution takes them also depends on the size of the population. The smaller the population the greater the effect of chance in determining which characteristics get passed on. Natural variations are typically small

Beyond Biology — Physics and Computing

Being rather too small to see, the behaviour of atoms and molecules is obscure, but the bulk behaviour of stuff has been studied for a long time. In metallurgy, the process of annealing

Landscapes of Thought

... Alice said she wanted to climb the hill.

When you say "hill," the Queen interrupted, I could show you hills, in comparison with which you'd call that a valley.

Of course, Alice object that a hill couldn't be a valley — but it depends what you mean by "hill" and "valley."

As this picture of a "saddle point" shows the red dot is a local maximum if one were heading front to back, and a local minimum heading side-to-side.

Business Examples

Apple is an interesting example of an organisation that has effectively created its own environment. Apple's brand and offerings are not so much "distinguished" from competitors as . In this respect Apple is not unlike the beaver, which creates dams as protection against predators and to corral its food supply. ... and you could say that the Apple Store online is Apple's iPhone lodge: access is strictly controlled and only non-threatening and non-competitive

A competitive analysis based on evolutionary principles would therefore say that Apple is a good long term bet as long as it controls its environment. Once a beaver has established

Further Reading/Browsing

A pleasantly readable introduction to fractals, networks, chaos, power laws, etc. can be found at John McCrone's Dichotomostic Blog

Read more...

Trite Questions, Trite Answers

Remember the acme of strategic thinking that was S.W.O.T.? Strengths, Weaknesses, Opportunities and Threats — and a mnemonic as applicable to an individual as to an entire organisation.

What are you personal strengths and weaknesses Mr Moore?

My strengths are my weaknesses and my weaknesses are my strengths.

The question is inane because it makes an assumption that any particular quality is absolutely either a strength or a weakness, when, as with most things, context is no less a determinant of goodness or badness than the quality itself. One can be decisive when one should be considered, one can be attentive to detail when one should be considering the big picture. And vice versa. Never neglect the prevailing conditions: business conditions are the environment in which the business man lives... adapt or perish.

Are you a "team player"?

That depends on the team... I don't work well with the unqualified, the inattentive, the lazy, the stupid or the selfish... otherwise , yes, I'm a team player — a good team can be considerably more than the sum of it's parts. And sometimes I should lead, and sometimes I should follow.

Building a good team takes time and care, a good leader can wield an average team to good effect, and a bad leader can lead the best of teams to disaster.

What makes a good leader?

The ability to create trust. A good leader is trusted to be honest, to be honourable, to be clear-sighted and to be strong.

Strong?

Strong enough to be a little authoritarian when circumstances demand decisiveness and speed of action, and strong enough to be willing to be softer & fluffier, to be more consultative, when there is no emergency to be dealt with.

But modern business can so hectic — there is never enough time. Every day is an emergency!

Then the organisation is teetering on the verge of collapse... when there is no margin for error disaster is just one bad, hasty decision away. Invest in a little slack — it costs less in the long run than repairing the damage... if it can be repaired.

This sounds trite but is actually based on some basic physics and computational techniques used in optimisation and complexity. In the never ending quest for efficiency and productivity it is often overlooked that the most efficient are often the most specialised... and thus the most vulnerable to adverse changes in conditions. Agility, flexibility, adaptability etc. come at a cost — but are probably better for long-term survival.

Read more...

Enterprise Architecture

What on earth is Enterprise Architecture and, more to the point, of what value is it?

Enterprise Architecture is about the design of businesses, companies and organisations — especially the large and complex. However, hardly anyone ever designs an enterprise; more often than not they simply grow to the point at which they are perceived as inefficient (in absolute terms or relative to competitors) or unsupportive of further growth and so found to be in need of a re-design — at which point careful and methodical consideration of the organisational goals, resources,

Enterprise Architecture, though frequently applied to the IT infrastructure of an organisation, is properly about the design and strategy

Enterprise Architecture is to the design of the business infrastructure as Project & Programme Management are to the delivery of the business objectives: quality assurance tools and methodologies.

Read more...