Being an architect is hard work. Given how small the population of people willing to do hard work is, it might be a little mysterious to you how many people manage to wangle ‘architect’ into their job titles*, but how few know what they are talking about.
If so, help is at hand – use this handy list of bluffing points to enable you or your team (or even that guy from Pret who brought the sandwiches in today) to play the role of enterprise architect while HR complete the twelve month recruitment process.
Bluff 1: I’m just not sure this solution will scale
Unanswerable, since any attempt to defend the solution can be simply rebutted by you declaring that wasn’t what *you* meant by scale. See below for worked example:
Victim: “So our document storage system can store upto 2 petabytes of data on a single node”
You: “I’m just not sure this solution will scale”
Victim: “Well we can easily scale out to 64 nodes without needing any additional configuration”
You: “I’m sure the trivial case is fine, but I was more concerned about real world scenarios; we are looking at a zetabyte load”
Bluff 2: What’s your use case?
Ostensibly an appeal to practicality, this is actually a brilliant way to patronise someone by insinuating they don’t talk to their customers and are obsessed with technology for technology’s sake. The use of Agile lingo makes it particularly hard to counter, since no-one wants to argue against Agile, right?
On very rare occasions you will meet someone who is actually half competent at Agile, in which case your fallback position is to bamboozle them with semantics, as follows:
You: “But I’m just not clear what our use case is here.”
Victim: “Well, as a customer of Big Corp, I want to log into my mobile app, so that I can check my orders”
You: “Hmmm. But are we sure that’s really a use case? To me that sounds more like an epic/spike/…/etc”
Bluff 3: What does the Technical Traffic Warden Committee say about this?
Every large organisation attracts a modest but determined band of people who love to proceduralise and standardise the joy out of anything they can get their hands on, including the very thing that got most of us into computing in the first place, which is playing with cool new stuff.
The TTWC won’t actually be named as such, but their ostensible function (preventing technical sprawl), and their actual effect ( keeping their organisation a decade behind the rest of the industry) will feel very familiar to anyone who has gotten a parking ticket.
Dobbing your victim into the TTWC will embroil them in months of red tape while they try to explain to a bunch of fifty-somethings what a graph database is. This will definitely make you enemies, so use with caution.
Bluff 4: Sorry, I’ve got to jump into another meeting now …
Never, ever, under any circumstances, decline a meeting. If you play this one right, you should have at least two different meetings happening in your calendar at any point in the working week. To get the full effect, you should share your calendar, so anyone who actually gets a bit of your time is fully aware how lucky they are, and how you might have to dash off at a moment’s notice (particularly if you’ve got something more interesting do, or if people start talking about deliverables). Also, if you fail to turn up to one meeting, the attendees will naturally assume you are at the other meeting. Not for the beginner, but can be devastatingly effective.
Bluff 5: Are we sure we’ve correctly separated the [control/management/data] plane from the [management/data/control] plane here? (Delete as applicable)
This is a ninja move guaranteed to bamboozle most people in the room in any meeting, sending them into a mental tailspin of anxiety as they try to figure out what you are talking about.
In computing this gets fantastically complicated, as people do crazy stuff like insist on separate physical networks for these things, and then wonder why they can’t afford a test environment or release more than once a year. Great for you, as you can simply make things more complicated if anyone looks like understanding:
You: “I’m just not sure we’ve correctly separated the management plane from the data plane here.”
Victim: “Well the admin process runs on a separate port secured by TLS”
You: “Hmmm. I don’t suppose you support a different LDAP domain for admin users, do you? That’s the Big Corp standard.”
Bluff 6: I think we need to run this one past Security
Not quite as bad as throwing someone to the TTWC (see above), but this will have similar effect, as the victim attempts to navigate whether they should be talking to the security architecture team or the threat prevention team. All of these teams will be small and incredibly overworked, to the point that the only way of speaking with them will be to actually accost them as they run from the smoking remains of one emergency to the next.
Security teams are usually masters at making sure the responsibility and effort for securing systems remains with the people building or buying them, so this is a good way of giving a project a mountain of invisible work that they are pretty much obliged to do if they want to get into production.
Bluff 7: I think there’s quite a lot of overlap here with the XYZ initative. I think we need to set up a meeting with them before we go any further with this.
Any large organisation will have multiple projects on the go, all competing for the same limited nutrients of money and management attention. There will definitely be something else out there which resembles or overlaps in some superficially plausible way with the project you’re looking at, so why not “help” by getting them together in the same room to pretend to be interested in each other? You can even rerun Game of Thrones for your private entertainment by secretly christening one project the Lannisters, and the other project the Starks.
Bluff 8: Why don’t we just try this out as an experiment before we commit?
The idea here is that to spend a few weeks/months kicking the tyres, before you commit millions, so you can walk away if it doesn’t work out.
Sounds reasonable, doesn’t it?
Despite sounding reasonable, it turns out most organisations are about as good at experimenting with projects as you and I would be with experimenting with crack. Experiments turn into POCs, which turn into pilots, which turn into Phase 1, which finally turns into Security being asked to sign off for go live on a solution they’ve never heard of.
So, yeah, you’re really only saying this to be the one who said it, with a side order of plausible deniability if it all goes Pete Tong.
Bluff 9: The underlying, guaranteed solution to all technology problems
I’ve used this one to justify multiple board position for two decades, it absolutely cannot fail. All you need to do is – ah, shoot, I’ve got to go to a meeting with the CCB about a firewall change, I’ll drop it to you in an email I promise …
* I’m talking to you, ‘DevOps Architect’, seriously?