Configuration Management

I spot an opportunity for Business Analyst – Configuration Management with an investment bank.

Configuration Management is not, as far as I can see, particularly difficult in theory – but I bet it's a bugger in practice: it's all very well if everything has been under configuration control since Day 1 (unlikely) and it would all be quite well if everything was easily identifiable (it isn't), and it would be, well, surprising if all the things whose configuration needed to be managed were known in advance.

The shade (wishful thinking?) of Donald Rumsfeld speaks: the list of things whose configuration needs to be managed is one of those known unknowns.

Take a for-instance: years ago when I was a simple hardware engineer, I worked with a slightly dubious  circuit design that included a monostable – a thing that produces an output pulse of defined width upon receipt of an appropriate input pulse (Such devices are generally not best practice, but there were mitigating circumstances.)

Anyway, a new batch of boards didn't work; investigation eventually revealed this monostable, a 74LS221 I think, to be at fault. The design called for an LS221 and, since all devices with the same number were all supposedly interchangeable, regardless of manufacturer, the configuration control did not control the chip manufacturer – and this was a degree of freedom to be exploited by purchasing in minimising the component cost.

It emerged eventually that the chip design/implementation was faulty, so that particular manufacturer was scratched as a supplier for certain classes of device... and then later the same fault turned up in a device from a different manufacturer, who had either licensed the (faulty) design/manufacturing mask or was re-badging the product.

So, even with very tight configuration management, whether you use white-lists or black-lists, there's always another unknown waiting to catch you out, one of those inevitable unknown unknowns.

The problem is the same regardless of the scale of the systems under configuration control: PC manufacturers will sell PCs with identical part numbers containing different but supposedly functionally equivalent components, except that they're not always equivalent: I have personally seen Microsoft Excel behave quite differently on two ostensibly identical groups of machines, which did in fact differ in their internal chipsets. Different chips can mean different device drivers... how on earth does one efficiently manage the configuration of systems that are superficially identical yet may  – or may not  – actually be identical in all material respects? This is one of the real challenges of configuration management.

And before you nod off with boredom, here's one of the biggest challenges of configuration management: Disaster Recovery.

Disaster Recovery often relies on having duplicate systems ready to take over when primary systems fail: it's all very well having robust and fault-tolerant systems, but what happens if a critical business system is taken offline suddenly, whether as the result of a natural disaster or not?

What business wants to happen is for all data, transactional information, etc. to continue to be available on a backup system that is identical in its operation to the "live" system; some degradation in performance may be acceptable (depending on the magnitude of the disaster) but the essence of DR is that business should continue pretty much "as usual". However, if this is to happen reliability  – as opposed to just once on acceptance of the DR solution  – changes in the live systems must be reflected in the DR capability... and there's the rub.

What should happen, but doesn't necessarily happen, is that system configuration changes should be reviewed not only for their general suitability, but also specifically for their ability to be replicated in the DR setup. I personally noted on very large government system that was set-up and managed in such a way that, whilst the DR solution was sure to work when first implemented, there was no thought given to the need for reflective configuration management, live-backup cross testing or managed retesting of the DR solution.

The common experience of the home IT user, that when the hard drive on the desktop PC fails you suddenly realise that either data backups haven't been made for too long or, if they have, that the configuration has changed so much restored data is difficult to re-use effectively, is easy to replicate on vastly greater scales in business.

However, all one needs to know is that configuration management is not only about recording the status quo, it is also always about ensuring that the status quo can be reproduced. It does introduce new factors to Change Reviews and Implementation Plans (never, ever implement a change until and unless a matching change has been design and tested on the DR system... and the two implementations can be synchronised) etc. but it can be done... if one is careful to bear in mind the purpose of Change Management, rather than unthinkingly following existing processes ad infinitum.

Every time something changes, Change Management may need to change too...

Read more...

Job Sites - On the Other Hand

Whilst the list of job site incompetents grows ever longer, there is more positive news.

I have actually encountered a few companies that are not information/CV black holes. A few companies have emailed to say that particular applications were not successful; so in the spirit of perfect even handedness, whilst I shall continue to berate those who, it would seem, have never bothered to try using their own search engines it's time to say Very Well Done to:

• CMC Partnership
• Thomson Reuters
• BrightRed

who took the trouble to send emails once the CV had been considered against the client's requirements.

Not that I expect for a moment that anyone is employed to send such emails, rather I applaud the forward thinking that said "we're keeping a database of applications, so we know who we select and who we don't... it should be trivial to automate the 'thanks, but not this time' emails." and then proceeded to make sure the IT delivered that marginal increment of service that makes prospective candidates think these people are a cut above the rest.


And I'll actually go beyond the mere thanks for the email for Carly at CMC who rang me, once I had been emailed to say I was not appropriate for a particular role, to discuss other possibilities and then conducted a very professional and thorough but pleasant phone interview lasting forty minutes. That's what I call taking care of business.

Oh... and I had a very nice chat with Natasha of Opus Recruitment too.

But, lest you think I am becoming soft and uncritical in my dotage let me finally attempt a last hurrah by ridiculing Experteer, who will register candidates for free but insist on concealing job information (information which, I am reasonably confident, is probably mostly freely available elsewhere) from the freeloaders, requiring instead a paid subscription.

I also received an email shortly after (pointlessly) registering, which said

Become a Premium Member now. On average, Premium Members receive six times more contact requests from headhunters, in comparison to Basic Members


Why? Because you volunteer 6x more paid for CV's?

Read more...

Job Sites & Job Specs – Jobseeker's Banes

I am eagerly and assiduously looking for a contract.

I have about seventy job sites bookmarked – individual recruiters, consolidators & what I think are merely some site-scrapers. Some are quite good – I quite like CWjobs and Indeed – but whilst others are generally OK, there are some real clunkers out there: I am a contractor, I only want to know about Contract opportuntities, but you would be surprised how often the search interface is badly designed. If the option to search by job-type is present at all it's usually at least two-clicks away, sometimes more (find the "search options" link, click that, unclick "Permanent, unclick "Both" and check "Contract", for example).

[I am actually "registered" on many of these sites, yet even when I am logged in none seems to take note of the fact that in my profile I have said I am only interested in Contracts]

Fortunately however, with a small selection of job sites with decent coverage and decent interfaces one can get at a large number of prospects... and then the fun begins. The job title always comes first, that at least helps one narrow down the possibilities (keyword search on titles only, for instance); then comes the description or long list of "responsibilities" (which aren't really "responsibilties" at all, they're tasks which become responsibilities by virtue of the fact that you would be responsible for doing the things you are requiried to do.)

Then, finally – though sometimes they're towards, but not actually at, the bottom of the advertisement – one finds the lists of Mandatory, Essential, Required, or merely Desirable skills and experiences. This is where, having carefully worked through some HR lifer's tedious overview of some exciting opportunity, mentally checking what the employer would like done against what one can do, one finds the foreseeable but unforeseen requirement that "the candidate must have a minimum of 5+ years experience of naked unicycling."

In the absence of a genuinely semantic web it is not possible to screen out the roles for which one is totally unqualified because one is limited to merely including or excluding certain words or phrases, and there are far too many possible ways of expressing either the desirability or actual necessity of unclothedunicycling experience, let aline allowing for the possibility that the employer might perhaps be interested in those who would be "willing to undergo a clothesless one-wheeled cycling proficiency test with a view to determing up-front training needs."

There is also, unfortunately, no job category "Doer of Stuff", so those, such as yours truly who not only do Stuff but do it very, very well, find great difficulty in identifying suitable opportunities and have to wade through reams of Other Stuff in search of nuggets.

Sometimes I wonder who designs job websites and whether they, or the site operators, have ever tried to use their own systems. Come to that, I wonder sometimes whether...

Sigh... I could go on, but I have job-sites to peruse...

Read more...

Recommendation: Sensibly Insane

“Julian is a truly independent thinker for whom 'thinking outside of the box' is quite normal, without ignoring the need for a well-grounded common-sense approach to the basics. He always enjoys a challenge and can be relied on to bring an extra dimension to the analysis and assessment of any problem space. He is a pleasure to work with.”

Roger Clarke, Senior Defence Consultant, Vega Group plc (colleague) August 8, 2010

Read more...

Recommendation: Gets it done

"I hired Julian to do a very technical piece of work, for Arthur Andersen. Julian is extremely bright, inventive and capable. He writes extremely well, rapidly grasps complex issues that baffle others and can be given a highly complex task and trusted to just get it done, without supervision or intervention."

Angela Knapton, Manager, Consulting, Arthur Andersen BC, February 19, 2010 (was with another company when working with Julian at Tier Technologies)

Read more...

CV – 2007/10 – Sabbatical and Travels

During this time a book (an epic philosophical work) was written, illustrated and typeset (the results are on show here), and then the wife and I headed off for a much belated honeymoon to India for several months.

From Karnataca to Kashmir we braved the out-of-season heat, exploring the great cultural sites of Hampi, Ellora, Ajanta, Khajuraho etc., the industrial heart of Maharashtra that is Bhopal,  the Bandhavgarh tiger reserve, Delhi, Agra, and the deserts of Rajasthan and eventually joined the locals in fervent prayers for rain when we got back from Ladakh, which we escaped to for a month. Everywhere we went in Rajasthan – Jaipur, Jodhpur, Jaisalmer, and Udaipur – it rained, usually on the day of our arrival, and it was wonderful.

Now we must get back to reality.

Read more...

Recommendation: Intelligence, Integrity & Innovation

"Julian is a highly intelligent individual driven to find innovative answers and solutions. Coupled with an excellent work ethic and being highly personable he is a bonus to any team. He is also excellent at customer facing roles and clients view him with integrity."
 

John Openshaw, Team Leader, MoD Integration Authority March 11, 2010 (managed Julian indirectly at MoD Integration Authority)

Read more...

The Arts of Negotiation

Whether you are buying or selling something, even if that something is a one-off commodity, item there is always scope for negotiation — the very nature of the wish to buy or sell is a factor in determining the price and conditions of a deal. No doubt there's a plethora of good books on negotiation but here are a few handy hints — some more useful that others no doubt.

Firstly, don't neglect personal relationships: liking and trust both have value. In some places (perhaps France, for example) the unquantifiable value of a good relationship may nonetheless be high enough to outweigh other significant factors. In long-term business relationships there is considerable value in spending time & money on your partners... but don't be over generous: you'll either look needy or sleazy.

Secondly, don't forget the cultural factors — the local style of negotiation and attitude to business in general. In some places it may be appropriate to throw an occasional tantrum (indeed lack of passion for the business may be considered a negative quality), in some it is very bad form to say simply "No" to a proposal or request (the Japanese for "No" in such situations is merely "That would be very difficult."), in some you should attend to the spirit of your proposed agreement and in others the letter (and, in the case of the Netherlands, what the other side may be mentally including/excluding in invisible ink — "In matters of commerce the fault of the Dutch//Is offering too little and asking too much."). As the American's might say, don't bet the farm on the first deal in a strange land.

Thirdly, always be clear about the bottom line: at what point must you walk away — know the value of the business as well as the price.

Fourthly, never make two concessions in a row — a principle even better deployed if your first concession is a "gimme" (i.e something you had planned to give away anyway). The reasoning behind this is that if you do not require something to balance a price reduction (e.g. longer delivery, shorter warranty, larger up-front payment etc.) the original price was (un)necessarily inflated: you should be protecting your margins at all times. (Though we cannot neglect other considerations, such as the time-value of money (cash-flow) it's a very bad idea to appear needy.)

But, beyond these things, what about some specifics. Here are a few negotiating ploys encountered , and my (successful) responses to them

You must give us a discount because we are a prestigious customer. 

The idea behind this ploy is that somehow by associating with you, the customer is adding value to your business. Typical specific examples include "Other's follow where we lead, if we buy from you, this will encourage others to buy — and we should share in the value we add to your business."

I have no objection to sharing the value once the (theoretical) value has been realised. If the client actively participates in a sales and marketing program, provides sales leads, introductions,etc. then it would be entirely appropriate to offer an element of commission on sales arising from their efforts... in appropriate proportion to those efforts. Obviously I couldn't discount the price for the current contract as the added value is currently undefined.

We will buy more from you if you reduce the price on the initial sale.

Again, a theoretical benefit is being offered. Offer a quantity discount with a fixed call-off period; charge the quantity price and if no subsequent order materialises invoice for breach of the quantity discount arrangement (if cash-flow permits such an arrangement).

We have already bought X units from you.

This was particularly amusing when deployed by a South Korean buyer since the first two units had been sold at a significant discount on the basis that the next order would in fact return the average price to the nominal list price (the price had therefore gone up). Answer: yes, but you didn't tell me you were going to buy more and you certainly didn't contract to buy more. That information or such a deal might have been valuable then. Do you think you might buy even more? Perhaps we should negotiate a quantity discount now so that you don't miss out again in the future.

You could also point out that if they intend to buy more from you then the previous purchases must have been at minimum satisfactory — probably better — and so the economics of the first deal was beneficial all round anyway.

It's too expensive.

A truly classic and vapid approach, which really means only "I want to pay less." Ask (delicately), "What does 'too expensive' mean?" If the answer is that it's more expensive than competing products, use product differentiation to justify the price differential. If the answer is, "I don't have the budget," then obviously you should seek to re-examine the requirements and then to offer something that does fit — or you could phase implementation (find out what the budget issue actually is).

Sometimes a buyer might challenge you to justify the cost of something — price breakdowns are always useful for dealing with such challenges since, below a certain level of granularity it is simply not possible for anyone to object to a particular cost item. But, when price breakdowns are not appropriate or unavailable (Why aren't they available? Always be prepared.) hand-waving arguments about long-term viability, investment, contingencies, etc. can deal with many specific objections.

Feel free to add your own one-line negotiating ploys and responses.

Read more...

A Sabot in the Works

While I was at the home office, working "without portfolio" I came across an interesting problem.

Beyond the Immigration and Nationality Department's main offices, front-line immigration staff were — erroneously and discriminatorily — often thought of as confirmed Luddites. At a time when the asylum processing system was in crisis, the perceived unwillingness of outlying units to cooperate with technical and process improvements was both a source of friction and a genuine impediment to the implementation of necessary organisational changes.

Being without portfolio I took it upon myself to visit a certain significant location to find out what the real problem was. Not having a portfolio, and hence being agenda-less, it wasn't too difficult to begin with a simple "exchange of views": I explained the issues as seen from "head office"... and they told me why they weren't interested in any solution emerging from East Croydon. Unsurprisingly (to me) most of their objections were reasonable and they all boiled down to one fundamental issue — no one listened to them and took into account their particular situation.

So I asked them to explain the difficulties they perceived with the technical and process developments being discussed and then asked whether, if I could come up with some way of bridging the divide, they would be willing to discuss matters further. The answer was, of course, yes indeed they would: they were neither Luddites, nor saboteurs; they were, as is usually the case, genuinely committed and working hard to achieve the organisations goals. The only problem was that, based upon experience, whatever was imposed from without

• Wouldn't work
• Would very quickly be replaced by something else
• Would probably leave them worse off than they already were

Anyway, to cut a long story short, I went away and built a prototype system that would interface the centre with East Croydon whilst also providing some buffering, and reflected both the local processes and the needs of head office. I then presented it to them — not by giving a presentation but actually by sitting them down with the prototype and working through some representative cases.

Of course the system was not right — there were mistakes in my understanding and process refinements and subtleties to incorporate — but having clearly seen their input reflected in a technical solution they were then ready to engage... and engage they did. A couple of months later, as the system was being finalised, not only was everybody enthusiastic about the new system, when certain significant technical issues surfaced they were even willing to propose modifications to their own processes in order to make it work — and thus were the so-called Luddites shown never to have been anything of the kind.

Following which, it should then have been And they all worked happily ever after...; alas, owing to a certain Not Invented Here mentality back in East Croydon, the final hurdle to formal roll-out and implementation was never cleared and the effort stalled.

What are the lessons from this?

Firstly, that passive resistance or even active obstruction to business change — whether technical or process — is not proof of corporate treason.

The basic psychology of motivation is this: in order to be motivated to do something one has to believe:

• that the goal is worthwhile
• that the goal is achievable in principle
• that one has the personal capacity to achieve the goal in practice
• and, finally, that the value of achieving the goal outweighs the value of the effort required.

Or, to put it in shorthand: Motivation = Value x Achievability x Practicability x Relative Cost.

Failure to appreciate this is a common problem. The British Prime Minister Tony Blair once famously railed against the workers of the National Health Service for their opposition to what the government perceived to be necessary changes to the NHS; this was both a political mistake and failure of leadership. NHS workers, like the vast majority of all workers, being genuinely committed to their organisations goals would, I am sure, have enthusiastically done what was necessary if they had believed in the achievability of a desirable goal. The problem was that they were not merely unmotivated, they were positively de-motivated to cooperate (which problem Tony Blair's comments only exacerbated).

In the case of the Home Office outpost, the value of the goal was not in doubt — what I did was help the immigration staff see how it could be profitably achieved.

Secondly, do not allow the ultimate goal of perfection to prevent any progress at all*: do what works until you find a better way.

It seems obvious, but somehow those to whom it should be obvious frequently fail to see such things.

* Whilst I first came across the idea that "The best is the enemy of the good" in an engineering context (attributed to Voltaire in the words "Le mieux est l'ennemi du bien," but apparently of even earlier origin), the mindset it epitomises is almost universal.

Read more...

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