Simplify complex things like business architecture

business architecture

One of the perennial problems with computer technology, especially as it becomes more complex, abstract and advanced, is that it’s so difficult to explain to the average person. 

However, as computer technology becomes ever more essential in everyone’s life, business architecture practitioners probably need to do more to make it easier for people to understand what they are talking about.

It’s been suggested on this website and others that perhaps tech leaders should avoid, or at least explain, the jargon they seem to enjoy using. A lot of jargon is often a sign of becoming tired of repeatedly using a long phrase – everyone wants to capitalise words and bundle them into an acronym so they don’t have to waste time saying the same things over and over again.

While that’s fair enough, at least explain the terminology somewhere in your article, conversation or presentation, if only once, preferably at the beginning – don’t leave lazy journalists to google your every other word because we’re not going to; we’re just going to get bored or bewildered and move on.

You can simplify complex things like business architecture – but only so much Click To Tweet

This is a serious point because learning about new technology is an ongoing requirement in this and many other jobs. If you make it difficult to learn about your new technology, you’re going to lose the attention of the reader to the competition, which is also offering new technology that needs to be learned and understood. And if they explain things better, who do you think is going to win the business?

Of course, “freeloading journalists” is not the market segment you need to worry about – it’s the procurement people at businesses and organisations who need to understand your product well enough to know exactly how it will benefit them. They cannot spend their money on trust alone.

And there are so many business architecture issues that remain unexplained, like foreign objects in dark skies that appear and then disappear into the ether.

Don’t be like Mulder and Scully and go through more than a decade of investigations without making a single arrest – solve a case or two.

Granted some things are really, really complicated – like business architecture – and you may only be able to simplify things so much; even explaining the architecture of physical buildings that people can see is sometimes an arduous task. But deliberately putting up obstacles that only geeks can navigate – or neglecting to bring those barriers down – might be avoidable sometimes.

business architecture illustration credit suisse

Neil McEvoy, CEO of Cloud Best Practices Network, suggests this inability or reluctance by tech experts to explain things in simple terms is increasingly making conversations about some subjects an exclusive club.

Writing on about “Agile business architecture for  digital government transformation”, McEvoy notes that explaining things better will lead to the building of stronger connections between the technology capabilities and business objectives.

McEvoy writes: “When discussing Government IT initiatives, such as the UK G-Cloud program, with public sector decision makers the most common complaint I hear is that it’s “techies talking to techies”, there’s little engagement with senior business executives or key departments like Procurement.

“This is evident when considering how it’s organized only in technological terms, classifying services as IaaS, PaaS or SaaS. This does provide the basic service listing structure but does little to link it to goals such as Digital Transformation.”

He continues: “A key skill set for filling this gap is Business Architecture, defined and shared through best practice forums such as the BA Guild and the OMG. Through techniques and tools like Value Stream Mapping, Business Capabilities and others, it provides the language for planning change in business transformation terms, ones that can then directly drive the architecture of the required technologies for implementing them.

“Contributors such as Credit Suisse offer keynote resources that explicitly state how to close the gap between technology deliverables and business goals.

“This presentation describes how you can roll down from business goals to populate an application architecture roadmap.”

While we find most of what McEvoy says quite interesting, the BA Guild website could do with someone making a new year’s resolution.

Neil McEvoy’s full article can be viewed at