How Up-to-Date Is Your Enterprise Architecture Tool Vendor?
More and more Enterprise Architecture (EA) teams are waking up to the fact that they need to invest in data and a dedicated data-driven EA tool. Data plays a critical role in keeping strategies agile and anchoring decisions and roadmaps for the organization.
Deciding on an EA tool is a serious investment. While the cost is one factor, EAs should also consider the substantial time and effort teams will need to sink into a tool to build out models of the whole enterprise and maintain data. Therefore, when deciding on a tool, the big question is whether a given EA tool meets organizational objectives.
These days, the EA tool market is quite mature, with established players and few new entrants. 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. Unfortunately, this maturity is also part of the problem with EA tools as a whole.
The world around EA has changed significantly. It’s an ongoing struggle to keep afloat with successive waves of technology and organizational change. Hard-pressed EA teams need to have confidence that their EA tool will drive the outcomes they need, both today and tomorrow.
Some Enterprise Architecture tools vendors are more up-to-date on the needs of the modern enterprise than others, so whether investing in a new EA tool or struggling to realize more value from an existing one, here are three significant shifts in Enterprise Architecture to consider.
1. Shifting Objectives: From Modelling and Standardization to Creating Insights With Business Impact
Most Enterprise Architecture tools are built around standards, from modeling and architecture frameworks to references and data interchange. However, in practice, few EA practitioners adhere strictly to these standards.
This is because formalized descriptions and industry best practices are not innately value-creating for the enterprise. Instead, the focus for EA teams these days should be on insight, direction, and engagement around creating an understanding of the organization’s current and intended future states, the need to create consensus, and a mandate with clear calls to action.
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 need to communicate with business decision-makers, not just technical developers. They have to tell stories around cost, risk, or speed-to-market. They must be able to persuade an audience that a shared investment or a deferred benefit might reap greater rewards than the perpetual scrabble for the present. To do all of this successfully, they need to be able to engage with decision-makers and tell stories around business performance.
The problem is many EA standards have evolved from an engineering rather than a strategy background. These standards focus on representing the component parts that make up the enterprise with accuracy and fidelity. So for EAs to tell engaging stories about the business and IT, they need to look beyond standards. The standards themselves shape a consistent language and methodology for describing things, focusing on answering the “what” but lack an effective way to help answer the “why”. Most EA standards do not have guidance on generating meaningful business performance metrics from the architecture. In fact, sometimes standards can actively inhibit the ability to tell business performance stories.
For example, an EA team has a list of applications. It may also have a business capability model so that it has a common language with the business. The team wants to be able to communicate how well applications are supporting the business capabilities, potentially from a cost, compliance, or risk perspective.
If they were to follow most EA standards, the standard would say that applications do not directly support business capabilities. They must instead be grouped into logical applications that provide IT services to support business services. These business services are then what actually realize the business capabilities. This is a painful process that creates several more steps in the process, which means several more data sets in between the EA team and the final perspective they’re trying to achieve. Furthermore, it’s highly likely that several of those data sets are of data they do not already have and so then need to figure out how to get into the database.
This complexity is exactly why many EA teams end up disregarding or “hacking” standards to overcome inflexibility. We aren’t advocating for disregarding those standards entirely, as they do represent valuable knowledge bases to be mined for guidance. However, EA teams need to 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 establishing a new, shared language unless it speaks to people outside the EA organization too.
2. Shifting Approach to Visuals: From Manual Diagrams to Data Visualization
Enterprise Architecture tools were designed to solve a specific information problem, not a modeling problem – we already had Visio.
From the early days of EA with Zachmand and IEEE1471, EA aimed to model the enterprise from different perspectives represented by different models: business models, application models, information models, and technology models. Unfortunately, by dividing up those perspectives, the information and understanding of the enterprise is also fragmented. Process models reference applications that don’t appear on application maps; application maps sit on long-decommissioned infrastructure. Every EA team ever to document their Enterprise Architecture in MS Office has discovered this to their cost. To improve consistency, it was proposed that the views be separated from the data with the addition of a database behind the diagramming tool. This meant that everything a database did could also be done, such as load data from other sources, run queries, create metrics and reports.
On paper, this model of back-ending an EA tool with an RDBMS sounded great. Except in practice, it usually played out one of two ways: the data either quickly became unreadably messy, or it was a perfectly organized artifact with no connection to the live state of the organization. The problem is that constrictive database technologies simply couldn’t cope with the sheer diversity of real-life enterprises.
In fact, the problems faced by Enterprise Architecture 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.
So other technologies have emerged to take their place. In the fluid world that is NoSQL, the graph database has emerged as the clear winner for enterprise modeling. It is naturally flexible enough to adapt itself to the bewildering array of data sources and standards that make up the description of the enterprise. Also, by virtue of its treating relationships as first-class citizens, NoSQL is far more effective at understanding cross-domain impacts or end-to-end views of cost or risk. However, it’s not just diversity of input that is a concern here but equally, diversity of output.
With the ever-increasing demand for understanding of the business and IT ecosystem comes a multitude of questions successful EA teams get asked (unsuccessful EA teams don’t get asked anything). So how can EA teams answer these questions effectively? With charts or with pictures.
The problem is Enterprise Architecture tools that were originally conceived as solution design tools so the number of visuals they needed to create was relatively small. The scope was fixed and deliverables were predictable. However, the visuals needed today to answer questions about the enterprise is vast. It is at this point that the conventional model of manually-drawing diagrams for EA breaks down. Teams don’t have the time to keep drawing pictures manually, and they can’t do it 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. Ardoq has made the bold decision to base its product entirely on data visualization and has no manual diagramming features.
The same reason drives the need for both graph databases and data visualization. The exponential rate of enterprise change, and the growth of diversity of data input and of requirement outputs from the Enterprise Architecture tools means that older technologies and methods, already underperforming, simply cannot scale. They break.
So the problem now facing many EA vendors is that the technologies that underpin their EA tools are a generation behind those which are now commodities in the enterprise data space.
It’s important to take time to dig behind the UI of a given tool to ensure that you have a platform that’s designed for the challenges of the 21st century, not restricted by the thinking of the 20th.
3. Shifting Audiences: From Engineers and Architects to Citizen Users
Technology’s capabilities have grown, and with that, expectations of how it is consumed have changed also. EA teams are compelled to fight for time with decision-makers, competing in a distraction-rich digital economy where attention is currency. Decision-makers don’t have the time or desire to sit through complex technical diagrams based on architectural standards they have no knowledge of. Despite this, some Enterprise Architects still cling to the belief that the technical “purity” of a standards-based approach will eventually swing the argument in their favor. This has hampered the progress of moving EA out of static, manual Microsoft Office documentation.
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. Developments like robotic process automation and real-time analytics mean that IT is now deeply embedded in the business architecture.
All this adds up to the fact that Enterprise Architecture no longer holds the same degree of control over IT as it may have once enjoyed. Shadow IT and now the concept of business IT and business technologists are on the rise. This signals an urgent need to change tactics. EA teams can no longer rely on asserting hard power. They need to build their soft power because traditional strengths like experience and authority are less critical than being competitive on the user experience (UX) front.
Until quite recently, Enterprise Architecture tools vendors simply haven’t done UX, and the sentiment is often that a given EA tool was designed with a very specific engineer user in mind. For the longest time, the diagram, also known as inventory or matrix, was the entire UI for an EA tool. Potentially the user would also get some kind of explorer bar that would enable switching from one view to another or the ability to link views from each other. Occasionally also, some kind of publishing portal (that tended to look identical to the tool except in HTML), and that was pretty much it. Tool vendors developed applications to support standards, and this is the result, leading to a deep-seated UX problem here: those standards were largely created by engineers for engineers.
To see why this is a problem, we’ll use an analogy much loved by generations of Enterprise Architects: The Enterprise-as-City.
Now cities, as a rule, are built in parts by specialists but navigated as a whole by regular people. At the building stage, everybody has their role, their scope, and their specialist view with their own arcane language. However, when it comes to exploring, this is entirely different. Let’s say you’re traveling to Ardoq’s home city, beautiful Oslo, so you ask the local Enterprise Architect for a bit of help finding your way around. What are you likely to get?
Well, most likely, 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.
This is great from a construction point of view but not at all useful for the casual explorer, the citizen user. The important point here is that EA tools often cannot be intuitively understood by non-specialists. They have predefined navigation paths that require tool administrators to go away and model or configure every time someone wants to present existing data in a new way. Tools like this do not allow others users to wander at will and lock them into a predefined viewpoint that is going to struggle to meet their specific business requirements.
Trying to reduce the mind-blowing complexity of the enterprise to something that fits onto your smartphone is an awesome UX challenge. This is something that even we at Ardoq haven’t quite cracked yet but what we have done is go 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? No, it just means it needs to evolve – and fast.
Today, vendors who are overly hamstrung by long-entrenched thinking or legacy technology are going to struggle. While they may still sell, the teams that use them will soon find that they just aren’t able to keep up with the needs of the modern digital enterprise.
Yet, 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 of the organization. Enterprise Architecture is needed now more than ever, but it has to be done with the right tools to really take organizations into the future.
Edward Granger Ed is Ardoq’s Product Strategist. With many years of Enterprise Architecture experience, Ed is at the forefront of driving innovation at Ardoq.