BankerVision

Walking with Dinosaurs

Tomorrow, I'm going to be giving a talk to a group of young people who have come to our organisation through our graduate programme. They are all very, very bright, and some of them are just about the most motivated to succeed I've seen in a while.

I love working with people at the start of their careers, and particularly this generation. The reason? They know and accept there are dinosaurs around, and they aren't scared of them.

I know when I was starting out, there were also dinosaurs. They had all this experience, all this knowledge, probably won in the "school of hard knocks". They were all senior, and you would never dream of questioning their determinations and decisions. If you did, there'd be consequences. I mean, what would you know about anything? Why would you be entitled to an opinion? Youngsters, you should listen and learn.

Well, that's over.

The dinosaurs today - and I hope I'm not turning into one myself - are hopelessly ill-equipped in many cases to deal with the way things are now. The problem is their years of experience are now a hindrance in a world where what's really important is freshness in absorbing concepts, ideas, and innovation. Things at which young generations have always excelled.

You can imagine the collective meltdown those words are likely to cause in the established IT community, of which I am a part. We're all in charge because of all those years of experience. How dare I suggest all those years are not that valuable?

But, for example, have a look at your IT organisation, and especially at your development processes. I bet you'll find they're gummed up with gates, and procedures, and evaluations and reviews. Everything takes ages, and the mantras will be "reuse" and "architecture" and "governance". These are the hallmarks of the dinosaur.

Why do I say that? Because they are mechanisms for controlling rampant spread of technology solutions in an age when doing big systems was expensive. It is still expensive, but only because of  the artifacts that have been left behind when things actually were expensive. It is our control artifacts that are now making us expensive, not the problems we are asked to solve.

This new generation of tech managers we're growing know this. They sit there and sigh when we ask for "one more gate", knowing that the new world is completely throw away. "Just build it", they mutter under their breaths, and could, indeed, fire up their personal laptop and do it overnight probably if they were of a mind to do so.

Don't laugh. We had this group of students show up once and do a hack-day. In about 24 hours they'd accomplished about as much as we'd done with traditional methods in several months. Oh, of course, it wasn't "governed", and "reusable" and "consistent with our architecture". But is was throwaway. Throwaway is what you want when the cost of development is a reducing function.

And it is a reducing function. I am amazed at what young-people start-ups can accomplish with practically no money. They maybe get half a million dollars from an angel investor and a month or two later have a system that's actually really useful and which people are desperate to use.

They go into these ventures serially. They work until something is obviously not working, throw it away, and start again. It is no accident that many of the most successful tech entrepreneurs presently are pretty young. They're not dinosaurs.

Anyway, back to what I'm going to say to these young technology managers I'm going to speaking to tomorrow.

Firstly, I'm going to tell them to recognise there are dinosaurs around. I'm going to tell them their bark is worse than their bite and even if they get bitten, they have years to recover. But of course, the best won't get bitten, because they will be clever about how they get their messages across.

And I'm going to tell them to question everything that comes from dinosaurs. And that their inexperience with the old way of doing things is their best chance to make a huge difference now.

Using people as glue

Sometimes, you're in a meeting, and the technical people will say that they have to do huge amounts of integration to get X old system to work with Y new one. The integration, because it involves your old stuff, will be expensive and time consuming. You sigh and wonder how you are ever going to get out of the legacy trap.

You know that, even if you mandate a new systems approach, you're always going to have to spend piles of money doing legacy integration, because that's where the data is. It is data on which the business relies, so it has to be available, and, obviously, the job of moving it all, and the business rules and all the rest, to a new system in one go is far to large and politcally charged.

And then, you wake up one morning and realise on top of everything, you have the "die or retire problem". Everyone who knows the guts of legacy is either dead or about to retire.

You have to do something about legacy, so you sigh, and sign up for truck loads of integration anyway.

it occurs to me, though, that there are solutions to this problem which don't involve piles of expensive technology work. What about, for example, using people as glue? Why can't they look up data in both systems and perform appropriate updates?

The thing is, technologists have spent decades trying to systematise and automate everything. The idea that you'd de-automate is an anathema. "What about error!" they cry whenever you suggest it. "What about security!, How about our data quality, how about... how about... and how about...!".

There are obviously lots of objections to putting people back into a system but they all miss the major point: if you are time constrained, and you need to get something out the door right now you can get almost any system up and running instantaneously with paper and people.

That is certainly true when you have the die-or-retire thing to deal with.

As far as I can see, the only time this absolutely won't work is in those circumstances when a process is entirely automated from end to end with no people in it at all. Like, for example, an ATM transaction or a web purchase online. But whenever you have people intermediating the machine for other people, you can use people as glue.

Now, I'm not suggesting that anyone put people back into systems permanently. But as temporary, good enough, solution while something better is worked out, surely it makes sense to at least consider the option.

Fake Experts

It is possible that the most frustrating thing ever is to have to sit through meetings with people who have declared that they’re experts, and then discover that they aren’t.

Here are the top five categories of people I’ve come across in the last couple of weeks who fit this category:

1. Innovation experts who say they know lots about the subject, but then dish out standard stuff that wasn’t current a few years ago. They toss out key buzzwords like “open innovation” and “radical Innovation” and “stage gates” because they’re the words that come up when you Google innovation. I reserve a special level of irritation for those who quote the major thinkers like Clayton Christensen, and then misrepresent his theories as something else entirely.

2. Social media experts who say they know everything about online but don’t do online themselves. Double demerit points awarded those inside large organisations who are responsible for intranets and therefore think they know anything about how social media really works. Their own intranets should tell them they don’t.

3. Analyst gurus who have gone into management, and then are trotted out by account managers because they are “senior”. As you know, my view of analysts is pretty dismal most of the time, because you so rarely see anything original from them. Managers of analysts almost never have an original thought left in them, and they always refer to their past research as if it was what made them qualify as management.

4. Architecture thought leaders. Please do not trot out one more model, or one more rendition of TOGAF with a new colouring scheme. Or, worst of all, a “disruptive” new approach to architecture. It is all so, so tired.

5. Almost all vendor CTOs (thankfully, we have a good one or two at the Department, who at least try).  They are there to flog product. Period. Any thought leadership you get is driven entirely from the perspective of convincing you to make a purchase of some kind. Of course, vendor thought leadership is somewhat an oxymoron anyway. They are always about responding to what the market will buy, so they are pretty much forced into copying the thought leadership they find in the market. That’s why analysts are always reporting what decision makers think, rather than dreaming up new stuff themselves.

What could all these groups have done differently and made the meetings less annoying? To have made it a valuable discussion that created new opportunities?

They could have thought through the stuff they Googled, and used their highly paid brains to give some unique opinion or insight.

They could have said something unexpected, something we might not have dreamed up ourselves.

They could have brought their unique experiences to the table, and used them as a foil for whatever points they were making.

Or, maybe they could have used their networks to bring interesting people to the table that would have astounded us. People we have now way of accessing ourselves.

Instead, what we get is oxygen thievery of the first order. Sometimes, you open the door and the whoosh of air into the room is palpable.

Originality is a precious commodity. Its such a pity that you so rarely see it.

Enterprise Architecture – the big catch up

Here is the problem with EA – it is never complete at the point instant when a project asks some question of it. I think that is true no matter how many architects you have or how good they are.

This is the third time I’ve been responsible for “Architecture”, and – no disrespect intended to architects, who aren’t the problem – it never seems to be in complete enough a state that it can answer the specific question a project needs answering at a specific time.

In an organisation that respects its architects – and I think that DWP is one – that means the projects ring up the architects to get advice. Which is all very well, of course, but since the architects are spending all their time trying to build their architecture out to the point  where projects need it to be going, they don’t have time to write all their advice down and add it to the architecture.

Of course, you could have an architecture team that builds things at such a high level that you get completeness simply because you’ve abstracted away all the detail altogether.

But I think that kind of defeats the purpose of having decent architects. You’re then into the realms of strategy, and lets face it, architects are supposed to be working out how to get to the endpoint that the strategy defines, not defining the end point itself.

Now I know that this set of statements will be like waving a red flag at a bull for some people. I don’t mean to cause offence, really I don’t.

But I have come to the conclusion that demand for architecture – at whatever level of detail – will always outstrip the supply of architects available. No matter how much money you spend.

Now, this presents a quandary, I think. On the one hand, if projects can’t get what they need from the architecture, I wonder what the point of having an architecture is at all. But on the other hand, the chaos that results from not having one at all seems pretty likely to have awful repercussions. I’m not certain anyone wants to go back to the days where people did exactly what they pleased, and dang the consequences.

Anyway, it would be impossible now that we have to do “service orientation” and “reuse” and “integration”.

But I can’t help but wonder if the real answer is to decentralise architecture in some way  - make it a more collaborative and participatory activity, one in which projects do a degree of self serving. Where, maybe, the architects are curators of the content, rather than the creators themselves.

I’m going to be talking to my teams about an interesting experiment I have in my mind along these lines over the next week or so. If we go ahead and try something new, I’ll write about it here.

In the meantime, does anyone else have experiences that are relevant? How did you get your architecture ahead of project’s demands for it?

Corporate bloggers are boring (especially new ones)

Why are so many business and corporate blogs so boring?

I started to wonder this the other day when I was trying to clear out my reader. I looked at the list of feeds I get, and started to examine my reading behaviour. There are blogs I immediately select whenever there is a new post available. And there are ones where I let the posts build up, until, in the end, I feel duty bound to read and clear them.

It is the blogs in this latter category, I noticed, which are boring.

So when I started to look more closely at this, I noticed something. Almost all are business or corporate blogs, and almost all are relatively new writers. And, boringly, they’re all comprised of statements of facts easily deducible either from the writings of others, or the corporate line their organisations are taking.

The common characteristic of boring blogs is - for me - that they don’t give you any insight into the mind of the author. They’re always about the minds of others.

New bloggers, apparently, fail to get that the purpose of blogging is not to demonstrate what you know - since all knowledge is highly commoditised these days anyway - but to show others what you think.

What you think is unique, and valuable. What you know is not. There are, anyway, very few experts around who know things that noone else knows, and of course, the minute they share whatever-it-is, its commodity.

Real experts, in my view, have interesting blogs when they create new thoughts. The reason they are experts is they take existing knowledge and ratchet it up a notch.

But most people aren’t interesting experts, and therefore must rely on the quality of their thinking about things already known.

I was put in mind of this the other day when I heard a story (through backchannels) that some people in the architecture profession here in the Department were horrified that I was joining because of this piece I wrote a few months ago. You see, part of my directorate is an architecture team, and the question everyone was asking was “Does he get architecture? Look what he thinks of architects!”

Of course, many architects I know are very savvy people indeed, and that particular post was deliberately aimed at architects and their cronies in various banks around town. I was letting them know what my opinion was. A tongue in cheek approach, perhaps, but I think, interesting reading.

Now, when I read most new bloggers, you’d never get a post like this. They are still trapped in the idea that blogging is about what you know, not what you think. They make statements of fact you could just as easily have Googled to get. Or else they reinterpret authorised messages from their organisations, perhaps with a little personal spin.

Or, my favourite, they have been told by their comms peope they need to do more communication, so they issue wonderfully crafted pieces which have quite clearly been written by someone else.

As I said, boring.

So here’s my challenge to all new bloggers out there: give us your mind. Share your thought processes, and your unique perspective of things that are happening. Tell us the way you see things, not the way things are.

And don’t tell us things we already know or can find out for ourselves. You’ll be interesting if you stimulate and challenge. But not if you are a dusty encyclopedia about things we don’t really care about all that much.

Should you do only things that are “strategic”?

I've had a couple of emails from readers in the last week complaining that an initiative they are passionate about was either slowed down, or cancelled altogether because it was deemed "not strategic".

In one case, it was an architecture function that said this when the project wanted to implement something not in the standards. And in the other, it was a new business initiative stopped because the opportunity wasn't aligned to existing revenues and failed to meet the "adjacency" test for new markets.

As a general rule, my own thinking is that lots of little initiatives that aren't part of the strategy can get distracting. Usually, the benefits associated with such non-strategic initiatives are microscopic compared to the amount of bandwidth they take up to generate those benefits. And the strategic projects, big as they usually are, tend to have equally large benefits associated with them.

But does that mean that non-strategic projects don't have any value at all? By no means.

Whilst it is true enough that when you factor in all the long-term costs (i.e, the operating costs of non-standard, the dis-synergies you get from complexity, and the increase in potential legacy, for example) of these non-strategic things, the business case usually collapses, those few times when it doesn't are highly illustrative.

Such cases tend to tell you that the strategy, not the project, is wrong.

People always tend to think that that strategy, once defined, is inviolate. That it should be fixed over some long term planning period, and must be adhered to rigorously.

I, on the other hand, prefer strategy to be flexible. The overall objective can't change every few seconds, of course, but the way those objective ought be achieved should have a degree of flexibility, a flexibility that increases the less course-grained the decision level is.

So, for example, I wouldn't like to see a new platform introduced to a technology estate just because a single project wanted to do so. On the other hand, if the benefits outweighed all the long term costs, I can't see any rational reason to prevent it. Even if it meant a new standard had to be created.

The fact is, if the new platform can stand alone and pay for itself, it actually represents a new capability that can reasonably be added to strategy.

Here is the fundamental failure I see so often with strategy, and strategy-related functions like architecture: as custodians of the one-true-vision, it is often the case that such teams fail to consider the inputs from teams they feel have no stake in the "big-picture". Small business lines, and smaller projects fall into this camp. Because their overall contribution is demonstrably less impactful to the whole how could they possibly have any idea of what the overall picture should look like?

The thing is, those small projects and business lines, when added together, are often much bigger than even the biggest of the big-ticket items in any organisation. How, then, is it reasonable to fail to consider their views in the overall scheme of things?

What I am really describing here, of course, is ivory-tower-ism. That's what you get when groups are entrusted to keep the "one-true-vision" and aren't forced to justify their decisions to those who are entrusted with implementing them. They go ahead and publish their positions to the organisation, without very much acceptance of the do-ability of those positions.

All this leads me to a diagnostic question: when were the architects, or the strategic folk, or the business development people in your organisation last asked to prove their statements were valuable? If the answer is never, I bet you have lots of documents, but not much coherence to them. I bet your organisation spends a whole lot of time getting around all these people rather than working with them. I bet, in fact, that they represent a consistent drain on progress, a brake to any move forward that anyone ever proposes.

On the other hand, I've seen working strategy functions. Even working architecture functions! They all have one thing in common: they have to prove that what they're saying is worthwhile doing. And they have to prove it to everyone, not just management.

What kind of organisation is yours? Strategy as hand-break, or strategy as accelerator?

Update: Peter Evans-Greenwood adds some interesting points in this comment. Refer to his blog posts on the value of strategy and enterprise architecture and how the new name of the game is moving from velocity to acceleration.

A letter to Architecture

Dear Architect,

Thank you so much for reviewing the initial designs for our latest proposition. As you know, we need to be in the market with it as soon as possible, because DownTheRoad bank is taking share from us. In fact, their latest offer is so compelling that our rate of churn has gone through the roof. Everyone agrees that our proposition will reverse that trend, so we're pretty excited about getting it out the door. In fact, getting it out the door is pretty much a mission-critical thing for us, right now, if we want to stay in business.

So we were surprised to discover that you'd rejected the design as "not strategic". Yes, we know we're wanting to use technology that's not on your roadmap, but your strategic platforms are too expensive and destroy our business case. Actually, we don't really understand how a technology platform could be strategic anyway, because it is all just pipes and wires to us. We thought strategic things had more to do with market level outcomes for our business than technology sourcing decisions.

Thank you for your comments and recommendations on what we should do to get your approval, by the way. They were illuminating, but illustrate a fundamental disconnect between your objectives and ours. For example, we don't think we should have to pay for a "business process management" platform or implement "service orientation" so that future propositions that might come along have lower costs. If you want to build out "cool" architecture, you must find your own way to fund the bits and pieces that you need, rather than loading us up with costs.

Actually, we're still burned from the last time you did that to us, when you told us that "multichannel integration" would give us all the competitive advantage that we needed. It didn't give us anything very much, but we suppose you got some "cool" bits or architecture. Anyway, once bitten, twice shy.

But even more surprising than all this was the discovery that even if we agreed to everything you want, we will then have to face an Architectural Council who have the power to overturn everything and send us back to the drawing board. Considering the constitution of this "council" is anyone who has a view on anything, we've heard on the grapevine pretty much no decisions get made ever. Apparently you all argue for hours over definitions of things such as TOGAFs and whether your "strategic" statements are correct or not. Its all so very ivory tower. Herds of elephants must have been destroyed in the process.

You'll forgive us, I hope, for ignoring Architecture for now. Our need is so very urgent that we don't feel we have a lot of choice. Actually, we do have a choice, because our vendor says they'll host the entire thing for us, for much less cost that we're forecasting ourselves. We've decided to ask them to do that, because it seems easier and quicker.

We therefore assume that as we will not be touching anything that uses internal IT, we are not subject to architectural sanction. All you have to do is provide us a bit of an internet connection, and we'll be fine.

Thank you so much for your consideration our proposition, and we look forward to working with you again when you have caught up with business reality.

Best Regards

New Propositions Team.

How ready is your institution for the recovery?

Security: I don't understand it, so I'm not going to allow it. Even if I did allow it, I'm going to treble your costs with a penetration test, a massive security review, and another couple of layers of technology to minimise the chance of even theoretical attacks succeeding.

I.T Architect: That's not our standard. Yes, I realise this is so new it isn't on our architectural roadmap, but in the interests of architectural purity, I can't allow it till I've tire kicked for at least a few months. Anyway, we're fast followers. Why on earth would we agree to be the first?

Risk: Nope. It is my role to mitigate risks to the bank, not to work out how to accept them. Look what happened last time – on my watch – when we took a few risks.

Finance: You want to invest now? You must be joking. Anyway, your numbers show little or no return until year 3. Don't bother unless you can get a return this year. And preferably this quarter.

Call Centre Director: Forget it, I'm not investing in training.

Branch Director: Neither am I.

Online Channel: Is it Web 2.0? Everyone tells me that's what's needed. In fact, Web 2.0 is the answer to everything.

Marketing: The budget is already spent. And our message is "back to basics" banking anyway.

CEO: Yes, that's right. Back to basics. It worked for hundreds of years. It will work now. You need to rethink what you're doing.