Have you considered the benefits of adopting data-driven architecture?
With data-driven architecture, there’s no longer a need to manually craft every model and visual using boxes and arrows.
This approach allows architects to save considerable time, enabling them to focus more on advising, communicating, and actively engaging in architecture dialog rather than spending excessive time doing hand-crafted models.
However, it raises two obvious questions:
Q1: When is it appropriate to use manual sketching (models), and when is data-driven preferable (automated models)?
and,
Q2: If data-driven is superior, why doesn’t everyone achieve success with it?
To analyse these two simple questions, let’s look into each of them:
Q1 – When to apply manual sketching?
To address the first question, we firmly believe that manual modeling is a creative process that aids architects in structuring their understanding and thoughts to effectively communicate ideas visually. This is particularly valuable when dealing with new projects and solutions, such as project and solution architecture.
However, in the case of a well-established and familiar landscape, where no creativity is required in documenting it, data-driven enterprise architecture becomes the ideal choice. We advocate distinguishing clearly between project architecture (which is transient and dynamic) and the well-established portfolio of architectures (which is more efficiently documented using data-driven methods and is more about documenting the current truth).
Q2 – If data-driven is better, then why does not everyone go there with success?
The second question pertains to the state of various architectures, systems, integrations, projects, investments, value streams, etc.
Referring to a recent post, we recently had a conversation with a chief architect who abandoned a competitive EA service that claimed it could stop manual modeling and turn all stuff into data-driven methods. We found ourselves pondering whether the issue lay with the tool, the approach, or perhaps the team. The unequivocal answer was “It was the tool.” Her initial expectation was clear – she invested to gain strategic decision insight and a means to offer management easy reports on future investments, aiding in the conversion of strategy into roadmaps. However, the tool proved, as she said, “to be a mismatch for the organisation, as it demanded upfront data that was not available.”
In dissecting whether this failure was attributed to the tool, the approach, or the team, the chief architect succinctly rephrased her observation: “We acquired the tool with the vision of becoming data-driven. Yet, our maturity is low.”
The two main challenges
In our view, this is spot on! There are two issues with data-driven
- When people are trying to use it for solution architecture where crafting and discussions are key for capturing the use-case and getting to the information; you often learn while sketching, and do not have the final layout up-front.
- When people know what they want, but the maturity is so low, the relevant data has never been collected and provided to provide an easy usage. In such case the tool should be more than a visual representation, it should aid in getting the right data.
The implication of this observation
This observation resonates with our broader observations. Many hope to procure a tool to solve the complexities of Enterprise Architecture (EA). The challenge, however, lies in understanding that:
- EA is not a one-time endeavor; it is an ongoing journey to provide data and information under governance to a broader user group.
- The maturity of an EA practice will influence the quality of data you have; if you start with low maturity of data, then it is an effort to migrate to a fact-based and data-driven enterprise architecture function. There are more routes, but it is a journey that requires effort. When we e.g. work with digital roadmaps, this can be done data-driven, but it requires data to be created along the journey, e.g. see post. Another example is capability maps. It is clearly time-consuming to manually create and maintain boxes and arrows manually, moving to data-driven capability maps is far more efficient, but it will still require new information to output anything meaningful.
- While a tool is a crucial component, it is only one facet of the entire process that also involves people, effort, and information; and often also the hand-over of architectural artifacts from completed projects. It is important to distinguish the differences between solution architecture requirements and enterprise architecture requirements; they are not the same.
Aim for the right data, to start right
It’s a sentiment we encounter frequently – individuals seeking a data-driven transformation with poor data and low maturity in architectural practice must reassess their charter or seek assistance, which we can help with.
The focus should shift towards planning for the tipping point, where data is mastered with digital governance outside the projects, using a consumable user-friendly interface, rather than mix-up data-driven and manually crafted designs. They both have validity, but the scenes are different; solution architecture and enterprise architecture are different and support each other.
Attaining the tipping point marks a shift, enabling the acceleration of an EA practice with a growing user base and scalability. However, until that point is reached, the path is more of a guided tour with a gradual ascent.
In conclusion, for those seeking data-driven insights amid poor data and low maturity in their architectural practice, it’s imperative to revisit their charter and get guidance on the journey – we can advise you.
Data-driven insights for the future require sound data, a governed as-is, which is an important stepping stone to automate the mundane tasks of architecture.
“Remember, a data-driven tool without data is akin to lights-off”
The tipping point becomes the catalyst, unlocking the potential for data-driven visuals and supporting human interaction with unparalleled efficiency. To delve deeper into the journey of Enterprise Architecture.
While many vendors may rush to provide early solutions, our approach involves assessing, designing, and several smaller sprints to quickly identify quick wins at the intersection of enterprise architecture, risk management, and low-code apps.
Let’s connect if you require assistance in converting from a low-maturity into a future-oriented data-driven architecture practice. Book your advisory session.
