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...