How ‘awake’ is your EA tool vendor?
More and more Enterprise Architecture (EA) teams are waking up to the fact that making their strategies agile, their decisions defensible, and their roadmaps joined-up means investing in data. And, except for those brave souls who choose to build their own, this means investing in an Enterprise Architecture tool.
Now, make no mistake: an EA tool is a serious investment. Not so much in licencing or subscription – the real price is in time and effort as you build out your models and maintain your data. But there’s no way around it. After all, you have a whole enterprise to model.
But let’s daydream, just for a moment. The work is finished, you have complete and accurate data.
Now the real question is: does my EA tool actually have what it takes to achieve my objective?
Well, the EA tool market is pretty mature, with established players and few new entrants. And there’s a broad consensus on what an EA tool is and what it does, and a well-established pattern around who uses them and for what
And, frankly, that’s exactly the problem.
Because the world around EA has changed. A lot. And hard-pressed EA teams trying to keep their heads above successive waves of technology and organizational change need to have confidence that their EA tool is going to drive the outcomes and conversations they need, both today and tomorrow. And some EA vendors seem more awake to that fact than others.
So if you are thinking about taking that step – or if you’re struggling to realise value from your existing EA tool – here are three things you should probably consider.
Most EA tools are built around standards. Modelling and notations standards; architecture framework standards; reference model standards; data interchange standards. Standards, standards, standards!
As the old joke goes, the great thing about standards is that there are so many to choose between.
When I first made the jump from being an in-house EA to an EA consultant, travelling on-site to work alongside clients, I was haunted by the idea that my wide-ranging frameworks knowledge might yet not be enough. So much to remember! Could I really name every BPMN event type? What were all the different matrices TOGAF listed? When should I use a UML Sequence Diagram versus a Communication Diagram?
I shouldn’t have worried.
Because only one in ten of those conversations revolved around standards. Even then, I met with few zealots for whom the standard was something sacred and immutable. Most EA teams were not particularly focussed on questions of formalized description or demonstrating compliance to industry best practice.
Simply because they didn’t see that as the main driver of value in enterprise modelling. Instead, everyone talked about insight, direction, engagement. Creating understanding of the As-Is and the To-Be. Creating a consensus, a mandate. A call-to-action.
What I expected to be an engineering discussion quickly turned into a marketing one.
And the reason is clear: Enterprise Architecture is not detailed design or even solution architecture. In many cases, EA teams are not specifying the technical solution within a project context once the case for change has already been made. They are strategists, charged with making that case in the first place.
This means EA teams are talking to business decision-makers, not just technical developers. They’re telling stories around cost, risk or speed-to-market. They’re trying to persuade an audience that a shared investment or a deferred benefit might reap greater rewards than the perpetual scrabble for the here-and-now. And to do that, they need to engage with that audience, and tell stories around business performance.
The problem is, many EA standards have evolved from an engineering rather than a strategy background. Their focus is on representing the component parts that make up the enterprise with accuracy and fidelity.
Now, to tell those stories EAs need a consistent way of describing their business and IT landscapes. The power of Enterprise Architecture standards is that they give us a predefined language and methodology for doing just that. Which is why older generations of EA tools were tightly-focussed on implementing standards.
But, as most EA teams usually discover, while standards are effective at answering the ‘what?’, they’re seldom very useful in answering the ‘why?. Take a look at your preferred EA standard: does it tell you how to generate business-meaningful performance metrics from your architecture?
In fact, sometimes standards can actively inhibit your ability to tell business performance stories. Here’s an example I’ve seen across countless EA tool implementations.
Our EA Team may have a list of applications. And because it wants to speak to the business in their own language, it may also have a business capability model. Now, what it wants to do is tell the business just how well those applications support their business capabilities – in terms of cost, compliance, cyber-risk, or whatever.
But wait! The standard says that applications don’t directly support business capabilities. Instead they are grouped into logical applications, which in turn provide IT services, which then support business services, which are what actually realize those business capabilities.
You can argue about the modelling. But in database terms, the standard is saying is that the query you need to answer that question requires you to join five tables, three of which must be populated with data you probably don’t have. Ouch.
The result in most cases is that the EA team disregards or ‘hacks’ the standard. And where the tool is too inflexible to do that, they simply disregard the tool.
So don’t throw away those standards – they represent valuable knowledge bases to be mined for guidance. But also be aware that EA’s mission has shifted, away from simple technical description, which prioritizes standardization, to creating insight and a mandate for change, which prioritizes impact.
There is, quite simply, no benefit to a common language unless it speaks to people.
Enterprise Architecture tools were designed to solve a specific problem. Not a modelling problem – we already had Visio. An information problem.
Now, as every architect knows – and enshrined in the enterprise architecture ‘constitution’ since Zachman and IEEE 1471 – we model the enterprise from different perspectives represented by different models: business models, application models, information models, technology models.
But when we divide up those perspectives, we also fragment our information: process models reference applications that don’t appear on our application maps; application maps sit on long-decommissioned infrastructure. Every EA team ever to document in their enterprise architecture in MS Office has discovered this to their cost.
Conceptually at least, the solution was straightforward: separate the view from the data, and put a database behind the diagramming tool. This not only resolved the consistency issues, it also had the added advantage that you could now do everything that a database did: load data from other sources, run queries, create metrics and reports.
And for 20 years this model of back-ending an EA tool with an RDBMS worked pretty well. Didn’t it?
Well, actually no.
What often happened in practice was one of two things: The data either quickly became an unreadable mess, or it became a beautifully-organised fossil, several cycles behind the current organisation.
The problem? Constrictive database technologies simply couldn’t cope with the sheer diversity of real-life enterprises.
In fact, the problems faced by EA tools are exactly the same as the problems that led to the emergence of the NoSQL database. Input data formats are too variable, Extract-Transform-Load is too costly and takes too long; imposing data standards is painful; and the whole landscape changes too fast. The conventional RDBMS is simply too rigid to model the fast-evolving organic enterprise ecosystem.
Other technologies have emerged to take its place. In the fluid world that is NoSQL, the graph database has emerged as the clear winner for enterprise modelling. Not only is it naturally ‘loose’ enough to adapt itself to the bewildering array of data sources and standards that make up the description of the enterprise, it is also, by virtue of its treating relationships as first-class citizens, far more effective at understanding cross-domain impacts, or end-to-end views of cost or risk.
But it’s not just diversity of input we need to worry about. Just as important is diversity of output.
Because the ever-increasing demand for understanding of the business and IT ecosystem means that the number of questions successful EA teams get asked (unsuccessful EA teams don’t get asked anything) has increased exponentially. And how do EA teams answer questions? With charts, or with pictures.
Now the problem with EA tools that have their legacy as solution design tools in projects is that the number of pictures you need to draw to deliver a project – where the scope is fixed and the deliverables predictable – is relatively small. But the number of pictures you need to answer a question about the enterprise is huge. And at this point, the conventional model of manually-drawing diagrams – placing each box lovingly by hand – breaks down.
You simply can’t draw enough pictures fast enough.
Fortunately, automated diagramming – data visualization – has matured hugely in the past decade, to the extent that complex diagram-like views can now be auto-generated entirely in real-time. And Ardoq has made the bold decision to base its product entirely on data visualization. We don’t do manual diagrams.
And the reason for both graph databases and data visualization are exactly the same. The exponential rate of enterprise change, and the growth of diversity of data input and of requirement outputs from the EA tools means that older technologies and methods, already underperforming, simply cannot scale. They break.
And the problem now facing many EA vendors is that the technologies that underpin their EA tools are a generation behind those which are now commodity in the enterprise data space. So before you pull out your credit card, take some time to dig behind the UI. Ensure you have a platform that’s designed for the challenges of the 21st century, not by the thinking of the 20th.
‘Digital’ is a buzzword for sure. And like many of the buzzwords that circle the IT industry, the technical community is hotly divided on how to interpret it. But also like a lot of buzzwords, it makes a lot more sense in marketing terms. It’s much easier to say how Digital feels than to specify what Digital is.
When I worked as an in-house EA, we had a running joke: whenever we came across a piece of EA ‘best practice’ that seemed more-than-usually technical, bureaucratic or just plain obscure we’d ask ourselves:
“How would Apple do EA?”
To which the answer was always: “Not like this!”
Because it’s not just technology’s capabilities, but our expectations of how we consume it that have changed. EA teams have always had to fight for time with the decision-makers at the top table. Now they also have to compete in a distraction-rich digital economy where attention is currency. Yet some enterprise architects still cling to the belief that the technical ‘purity’ of a standards-based approach will eventually win swing the argument in their favor. Unfortunately, few experienced enterprise architects share this belief – which is why it’s so hard to prise PowerPoint out of their fingers.
It’s also important to understand that the shift towards the ‘consumerization’ of enterprise IT signals a far more profound shift in power around the management of IT itself: SaaS and Cloud have driven IT acquisition decisions to the edges of the enterprise; Digital means that IT is the business product or service, not just some enabling substrate as it was in a previous age; and Robotic Process Automation and Real-time Analytics means that IT is now deeply embedded in the business architecture.
To put it bluntly, enterprise architecture no longer holds the same degree of control over IT as it may have once enjoyed. And when control shifts away from you, you need to change your strategy. We can no longer rely on asserting hard power; we need to build our soft power. That means that EAs can’t simply compete on their traditional strengths of experience and authority anymore; they now also need to compete on user experience (UX).
Until quite recently, EA tool vendors simply haven’t done UX, best typified by a sharp observation a colleague of mine once made on our then-EA tool:
“This EA tool was designed to be used by the guys who designed this EA tool.”
Because for a long time the diagram – or inventory, or matrix – was the UI. We’d get some kind of explorer bar that would enable us to hop from one view to another. Maybe we could link directly from one view to another. Maybe some publishing portal (that looked identical to the tool except in html). And that was pretty much it.
You can’t entirely blame the tool vendors for this. They support the standards, remember? And that’s what the standards say you do. But there’s a deep-seated UX problem here: those standards were largely created by engineers for engineers.
To see why this is a problem, let’s use an analogy much-loved by generations of enterprise architect: The Enterprise-as-City.
Now cities, as a rule, are built in parts by specialists but navigated as a whole by regular people. So for sure, when you’re building, everybody has their role, their scope, and their specialist view with its own arcane language. But not when you’re exploring.
Let’s say I’m travelling to Ardoq’s home city, beautiful Oslo. So I ask my local Enterprise Architect for a bit of help finding my way around. And what do I get?
Well, a set of 90 street plans, some of which overlap, some of which have gaps; a set of building schematics (including detailed wiring diagrams), hyperlinked to a 6,000 row spreadsheet inventory of shops and restaurants, each of which has 74 different properties; another spreadsheet of hotels, and finally a 300 by 300 cell matrix showing which restaurants are within walking distance of which bars.
What??? Just give me Google Maps!
Alright, so I’m exaggerating for effect. But there’s an important point here: EA tools that can’t be intuitively understood by non-specialists; that have pre-defined navigation paths; that require tool administrators to go away and model or configure every time you want to present existing data in a new way; in short, that don’t allow users to wander at will (even if they occasionally encounter a ‘keep out’ sign) and locks the user into a predefined viewpoint is going to struggle to meet requirements.
So we at Ardoq know we haven’t fully solved this problem yet. Trying to reduce the mind-blowing complexity of the enterprise to something that fits onto your smartphone is an awesome UX challenge.
But I can tell you this: we’ve gone further than most vendors to strip away the ‘mystique’ of EA. We talk UX every day. And we’re never satisfied, because we know that in the 21st century the success of the EA mission itself hangs on it.
The EA tool is dead. Long live the EA tool!
So does that mean the EA tool is dead in the digital age? Well, no. It just means it needs to evolve – and fast.
And in the new world, those vendors overly hamstrung by long-entrenched thinking or legacy technology are going to struggle. Because while they may still sell, the teams that use them will soon find they hit the buffers. Engagement will drop, demand will dry up, and the attention of the organizational will quickly focus elsewhere.
Which is a shame, because in this era of cloud, IoT, and business and IT ecosystems, more and more stakeholders are desperate for that joined-up view of the enterprise to put their understanding and decisions in context. They want that digital twin.
And who better qualified to create it than the Enterprise Architects?