Not long after we started making Ardoq, we realized that if we were to create a scalable, user-friendly Enterprise Architecture (EA) tool, we needed to start using it ourselves. Using Ardoq in our everyday work, we now experience it just like a customer would with the good, the bad, and the ugly. The experience we’ve gained by acting as an outside user has been invaluable.
In this series of blog posts, we’ll share our experiences as an Ardoq user (or as we call it in the company, Ardoq-in-Ardoq) and how it’s informed our development of the product.
Along the way, we’ll meet Ardoqians across the business who have helped make Ardoq the EA tool it is today. From IT to Security, to Marketing and everything in between, we want to be transparent and explain the processes behind building the Ardoq tool, showing how we actively use it in our everyday work and how it’s helped us create a better product.
Foundations For Building a Scalable Enterprise Architecture Tool
In the beginning (2013), a side venture resulted in the creation of Ardoq’s original Enterprise Architecture tool.
Over time Ardoq grew, gradually opening offices overseas and signing new customers. With this growth came the realization that our Enterprise Architecture platform needed to be more accessible. Scaling the tool would be near-impossible if only a handful of IT specialists with very specific experience could understand and use it.
As we adapted, we questioned ourselves: Was Ardoq getting things right? Could the company actually improve and promote its product by...well...using its product? And, if so, how would we go about doing this?
To answer these questions and explain how we got to where we are today, we caught up with some of those who have helped shape Ardoq into a scalable Enterprise Architecture tool, namely our CEO, Erik Bakstad, Product Strategist, Ed Granger, Head of IT, Per Fjelddalen, and VP of Marketing, Sigrun Rodrigues.
Describing the need to treat ourselves as an Ardoq customer, Ed Granger, Ardoq’s Product Strategist explains:
“We realized that we were making some guesses about how our customers were using Ardoq. We weren’t yet using Ardoq ourselves, which meant we could easily be making assumptions about the entire user experience. We needed to shift our thinking 180° and experience Ardoq from the outside-in, and not from the inside-out”.
We wanted to understand our customers’ behaviors and pain points, share their experiences and use the knowledge to continue improving upon and scaling Ardoq. This wasn’t only about product development; the company was increasingly feeling a ‘lack’ of documented architecture.
Erik Bakstad continues: “We’d realized that our rapid growth meant many of the processes we had in place were no longer working - what was effective for 20-30 people was no longer feasible for 50-60 people. We understood that by actively using and believing in our own product, we could also help to ease some of our own growing pains."
Becoming our own customer and using Ardoq (in Ardoq) became part of our scaling solution.
Acting as our own customer led to some revelations. “We realized we didn’t know which of our processes were formalized, and which weren’t,” Erik explains. “We saw that if we couldn’t track our technology, people, capabilities, and interdependencies in Ardoq, then we probably shouldn’t be telling our customers how to do it.”
The learnings gained from acting as a user also helped us establish governance for Ardoq and set the tone for maintaining our transparency. Now, we could see the power and potential of the tool, but we could also feel some of its pain points like a customer might. The process also helped steer us on how we should be training our customers on using Ardoq.
After our first taste of using our product, Ardoq-in-Ardoq (AiA) was born. What started as a small side-project driven by a few individuals has become an essential part of how Ardoq develops - both in terms of our processes and our EA tool.
Self Enterprise Architecture Experimentation
In a company with different teams, the scale at which applications (apps) are bought and become redundant can be staggering for a large enterprise - for a company of Ardoq’s size, we get a small taste of the complexity and implications of this. These complexities and their implications are 100 times more intricate for a large enterprise.
Operating as a SaaS (software as a service) as Ardoq does, we have a company policy of only using SaaS-based applications, making acquiring apps much more straightforward. This simplicity results in a very modern architecture problem - it becomes easy to lose control of your apps, resulting in churn. Per Fjelddalen, Ardoq’s Head of IT, who runs Ardoq’s Application Portfolio Management knows this first hand.
In his role, Per continually asks:
- What apps do we use at Ardoq?
- What apps could we get rid of?
- Could we use one app to do more than one thing?
- Where can we license more effectively?
- Are we putting any of our information at risk by using these applications?
- Which department owns these apps?
All businesses need to maintain a balance between agility and control as they grow. This balance becomes all the more pressing as a company opens new offices, enters new markets, and starts new business lines - something that just about all of Ardoq’s customers have in common. Our own Application Portfolio Management (APM) is an example of how we maintain discipline as we grow and means we can build our own enterprise architecture along the way. It also makes sure we’re hyper-aware of the processes our customers are going through.
Want to know more about how we manage our apps? Stay posted - we’ll dive deeper into Ardoq’s Application Portfolio Management in a later blog post.
Non-Expert Insight is Critical for Scalability
Making sure our own team understands and uses Ardoq helps us know how a customer from a non-EA background might use the tool.
“When I joined the company in 2019, Ardoq felt like a blank sheet with buttons to a non-architect like me,” says Sigrun Rodrigues, VP of Marketing. “It seemed to be only accessible to engineers with a technical background and not those from the rest of the business.”
During a company hackathon, Erik sat working with the Marketing team. He was alarmed at the amount of frantic clicking he could hear coming from Sigrun as she attempted to map out her team using Ardoq. This was a turning point, as Sigrun explains. “Ardoq was growing, but the tool was becoming more and more challenging to use internally."
We were beginning to see that if we continued this way, Ardoq wouldn’t be useful for others or, indeed, scalable.
Erik continues, “The danger of becoming an expert is that you quickly assume everyone has the same understanding as you. The hackathon was a great reminder of what it’s like to be completely new to the product. It brought us back down to earth a little - reminding us that the tool needed to be as accessible as possible.”
Ardoq-in-Ardoq: An Accessible Enterprise Architecture Tool
The insight from non-technical, non-IT team members from the business side has proved valuable in building Ardoq. These early revelations help support our belief in Ardoq’s roadmap, informing us about where we go next with the tool. This includes plans for opening Ardoq up even more to non-tech users - making the product accessible to more across the business, both for our customers and ourselves.
We can’t pretend Ardoq is the magic silver bullet that will solve all your business woes. Still, we can say that behind Ardoq are real people who have gone through rounds and rounds of tweaks, edits, re-writes, trials, and errors to make it the scalable EA tool it is today.
By going through the same journey as our customers, we believe we’re doing the very best we can to help.
Stay posted for the rest of our blog series over 2022, when we’ll share more of our customer journey, including how we:
- 💡Manage our application portfolio
- 💡Build and maintain our basic repository
- 💡 Developed Capability Modeling
- 💡Got ISO certified
- 💡Manage our integrations
These posts will tell you the human journey we’ve gone through to build each of these things. What’s worked, the mistakes we’ve made, the discussions we’ve had - we want to talk about how we’ve experienced it all. No dry theory, we promise.
Want to see Ardoq in action? Reach out to one of our experts today 👇Ardoq This article is written by Ardoq as it has multiple contributors, including subject matter experts.