Early on, when we were just a little start-up, we started using our own product. First off, we needed it to help with our governance while staying agile. Secondly, we knew it was important to experience our Enterprise Architecture (EA) tool just like a customer would, bugs, patches, and all.
We’re writing a series of blog posts to share our experiences as an Ardoq user (or, as we call it, Ardoq-in-Ardoq). We described the first part of the journey with Ardoq-in-Ardoq: Using Our Own Product.
The next step took place towards the beginning of our journey as we worked towards making a useful As-Is state. Of course, Ardoq can also model future states using Scenarios - but that’s a story for another day, further along in our maturity journey.
Now on to part 2, explaining how we use agile governance to maintain a trustworthy production area while providing a staging area.
In the beginning, we started with a staging area for Ardoq’s basic repository. In it, we stored all the ‘stuff’ that goes into building our tool. Then, we collaborated, tested, and updated all the magic that goes into making the tool.
Only, if we’re honest, the first incarnation of our staging area for the basic repository was, well … chaotic. Nevertheless, every Ardoqian could access it for a place to play, learn how to use the platform, and do some serious experimentation.
It was a good experience; Ardoqians built everything from mapping out hackathon ideas to loading movie data. Some serious work took place too, like formally tracking ownership of applications which provided information we needed for GDPR. However, we had 14 different application workspaces alone with different apps, lots of people working in them, and what happened there often had a short lifespan.
Experimentation and a lack of standardization created a relatively unstructured mass of information. It was our bad - we hadn’t assigned ownership or developed a process for sorting through Ardoq’s repository.
- We had no folder-naming or sorting system
- We didn’t know what information was ‘good’ and which was ‘bad’
- We had no idea if the information was up-to-date or if more recent versions of this information existed
- Some of the bad we thought might be useful, and some of what we deemed good information turned out to be, in fact, bad
The information held in the repository was unquantifiable, meaning it was hard to know what we should keep and what we should delete. On top of this, the sheer amount of information that we needed to sort through seemed overwhelming.
To be clear: our staging area is perfect in all its experimental beauty. However, we realized that it couldn’t be used to build the needed confidence and trust in Ardoq-in-Ardoq. We have a business need for this data to build solid governance.
Trust is paramount to building governance. We couldn’t use a tool when we didn’t trust it to deliver data to the security and legal departments. For example, to run GDPR we needed to trust the application list is accredited. Unfortunately, if a repository isn’t controlled, people lose trust. Once that trust is lost, it’s hard to get it back again.
Many of Ardoq’s customers find themselves in a similar situation. Often an organization brings in an Enterprise Architect to ‘fix’ the issues stemming from disorganization and a lack of overview of systems, processes, people, and more. There might be some sort of repository in place, with all the hallmarks of the one we started with at Ardoq, one with information anarchy.
We started on the next step of our creation journey, imposing order on our data. Our mission: to dig out the good data so we could see and show the value. After all, our results can only be as good as our data. These are the steps we took to bring order and transparency into our own repository.
Step 1: Beginning Agile Governance, Separating Chaos and Order
Our first step involved splitting out two separate environments to create order. We kept the staging area with all of its chaotic glory and added a separate production area environment in the same Ardoq repository. With the simplest step done, we rolled up our sleeves for the next stages.
FYI: We separate environments with permissions because of our newness in the maturity journey. However, many of our mature customers have physically different environments for the staging area and production environments.
Step 2: Creating a Common Language, Organizing the Production Environment
To get started in the production environment, we needed a common language. Just as you need to define apples and oranges to compare them, you can’t count the number of applications before you have classified what they are in the first place.
To begin with organization, we needed to sort out folders named anything and everything. In the production environment, we started with a clear, logical system of organization. Ed Granger, Ardoq's Product Strategist, explains, “We already had a best practice guide and pre-defined metamodel which we recommend to new users, so we followed that to start."
Step 3: Moving Data Based on Feedback from Domain Experts
Before we move anything from the staging area into the production environment, we carefully review it based on our criteria list. When it’s worth keeping, we move it into the production environment.
Ardoq’s flexibility means that there is a relatively low barrier for entering information. As a result, it’s not hugely time-consuming, and it’s quick to learn - even for non-Enterprise Architects. This low barrier means information can quickly be elevated to the more formal ‘review’ stage, and our staging area set-up means we can easily formalize things without having to start from scratch.
As we grow, getting people to contribute their insights, content, and information, the process of extracting this information needs to be kept as simple as possible. Yet, the information contributed must be highly structured if it’s to be useful.
Criteria - check-in with domain experts
- Do they want to keep and maintain it?
- Is data current?
- Is it translatable into the meta-model standard?
- Is it complete? Is it the most complete?
- Duplicate information: what is most recent and most accurate?
- Is it relevant for our purposes and useful?
As we move through this process, we’re finding a lot of valuable knowledge and information put there by experts we take seriously. There’s a lot of relevant data that can accelerate the process, for example, risk management, ISO 27001 compliance, GDPR, and vendor management. It’s just not joined up and lacks coordination. Of course, sometimes it’s just people trying to learn.
Step 4: Governance Oversight, Standardizing and Linking
Staging areas are like junk shops - shelves full of left-over stuff, with occasional genuine antiques. As we find the antiques and move them into the production area, we have insight over the whole, instead of only bits and pieces. As the chaos changes to standardization, we can see vendors and applications and use that knowledge to start answering questions.
By step 4, we were getting an overview and insight, thanks to having consistent data and building a standardized relationship between applications and other parts of the repository, including processes, vendors, people, and information. Because there are always new items in the staging area, it’ll be an ongoing process. Importantly, we’ve started to build repeated processes around predictable data and questions, making it easier to qualify what’s worth keeping and moving. Over time, we’re starting to build stories around the data.
Altogether, this stage enables the building of queries and dashboards to better understand and model the data.
Step 5: Keeping Data Relevant, Tracking Data Quality
Data ages like fish, not wine - the longer you have it, the less anyone wants to use it. Having quality data to track builds the confidence of your stakeholders that they’ll always have fresh fish and never have a stinky fridge.
As we mentioned in Step 2, a common language is vital. So we’ll pause for a quick language alignment. In Ardoq, we have several phrases to describe the quality of data:
- Unuseful Data = Data that isn’t useful, although it might be high quality
- Bad Data = Data that may be useful but whose quality is bad
- Good Data = Data with high quality and usefulness
Our initial goal was to track our data, giving us a purpose. Then we threw out the unuseful data and kept the bad data. We thought about how to make the quality of the bad data better, put in the fix, then waited. In the next week, we checked to see if it had improved. Over time we kept making changes, moving along incrementally until we could say we had good data. Each day we continue to track data, keeping it at a high standard because we’ve wrapped solid processes around it. (A lot might be good quality, but not useful for us.)
Once you have your basic data in place, it can be turned into a set of numbers and trackable metrics. We kept an eye on everything using our dashboard to:
- Track data quality
- Note applications missing ownership or key fields
- Find applications without life cycles
FYI: It’s easy to get carried away. Don’t. Just track a few key metrics around your data quality and move forward.
Step 6: Maintain Agile Governance, but Remember to Play
For us, agility is all about innovation, experimenting, and finding out what we can do with Ardoq. To stay agile, it’s vital to keep the staging area as a safe play space. Without the ability to innovate and flex the model, creativity will die, killed by too much control. In order to innovate, to get better use of the tool, you have to experiment. People need an environment where they can feel free to play.
Our staging area allows us to work in informal environments, helps us stay agile, lowers the barrier to entry, and allows us to do things fast. With the two-speed approach, we can move items into production when they’re ready.
Ardoq-In-Ardoq: Using Our Tool
All Ardoqians have given us valuable insight as we experiment with, use, and build our tool - especially as we split our staging area and production area to make our governance more trustworthy.
We wish Ardoq were a solution to all of our and your architecture woes. But instead, we can tell you that it’s a flexible tool. After all, we’re real people behind it with real EA struggles.
Stay tuned for more or our Ardoq-in-Ardoq stories, including how we:
-
💡Manage our application portfolio
-
💡Developed Capability Modeling
-
💡Got ISO certified
-
💡Manage our integrations
We promise that these posts will share the human journey we’ve gone through to build each of these things. We’ll share 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.
Want to see Ardoq in action? Reach out to one of our experts today 👇
