Akwatype – Early data modeling for all your teams

Data modeling (also known as domain modeling, structural modeling or static modeling)  is still the most important element of your whole development strategy, even in these “AI-driven” times.  But, surprisingly, there are very few tools that focus on data modeling. Basically, the only ones that still exist are the survivors of the golden data modeling area, at the time when relational database modeling was the most popular.

Today’s tools are either “draw whatever you want tools” (with a huge number of palettes and icons but no actual modeling support) or low-code tools with a clear focus on code-generation, mostly of web-based or data-intensive applications.

Akwatype is a fresh new tool that wants to bring data modeling back to the center. As they defined themselves: “Akwatype is early data modeling for efficent design. Structure your data modelling right from the start of your projects to communicate, describe your data flows and feed your development teams”

In this tool review, we take a closer look at Akwatype and what it brings to the modeling / development community.

Core modeling capabilities

Everything starts with a data model. The Akwatype language is similar to other well-known modeling languages such as UML or ER, though with some particularities. The main element is the type, which, as expected, can include properties, relationships with other types and can also be part of generalizations. Association classes or n-ary relationships are not possible (they need to be explicitly reified). Read more about the language details and see the featured image for an example. In general, the learning curve is rather shallow as it will immediately look familiar to anybody who has played with other modeling tools in the past.

Models are not graphically defined. Instead, they are created using an intuitive textual syntax which is continuously compiled to create the corresponding graphical representations (in fact, more than one, depending on the type of view of the model you are interested in). The editor is quite smooth and fact, giving you the feeling of playing with almost a projectional editor. Still needs some polishing, but overall, I got a very positive impression and I didn’t miss all the drag and drop needed in other editors.

 

Those that know me, we’ll not be surprised if I say that I do miss the possibility to express more complex business rules with some kind of OCL-like language. But a thumbs up for adding the primary key metadata attribute, one of my pet peeves, as I strongly believe every class requires an attribute (or combination of attributes) that can be used to uniquely identify objects of that class.

Beyond modeling: facades and services

A second core principle in akwatype is that having a single unified model for all the development teams is not enough. It is also important to clarify how each external service will “see” the model.

This is what facades are for. Each facade explains how a type/s is exposed to an eternal service (e.g. an API call) and the mapping between the original type and the facade following a simple set of navigation expressions explaining how the facade elements are retrieved from the types.

This image, taken from their website, illustrates it quite well. Note how the facade elements are not just a subset of the type model but they may decide to present the information in a slightly different way.

Finally, each facade can be linked to a concrete service (e.g a specific endpoint of an API) so that you have the full “route” between the schema of the input/output messages in a call and the ultimate data model these calls will be reading/updating from.

Code-generation and export capabilities

Once all stakeholders (from more business-oriented users to more technical architects) have agreed in the data model, Akwatype offers some export capabilities both for the model itself (that could be exported to Excel, to PlantUML,…) and for artefacts that could be easily generated from the model such as HTML, SQL, AsyncAPI or OpenAPI specifications.

This makes sure that the ROI (Return on Investment) of the modeling activity goes beyond creating a sharing understanding within the company and can be used as a starting point for the development process itself.

Final thoughts

As somebody who started his professional career modeling databases (with PowerDesigner at the time!) I fully buy the Akwatype concept and philosophy and the powerful set of features it offers. But I believe it’s facing a complex market situation. In the next subsections, I try to give my opinion on this and a couple of other topics. Make sure you share your own thoughts at the end of the post!!

How big is the market for this type of tools??

As I said, I’d be an example of its target profile. But am I representative of a large set of clients?

Akwatype’s bet is to provide tools for data specification, most often carried out with office automation tools, upstream of the API description and application development phases. While we can all agree on the benefits of such approach, the key question is whether there enough companies with a team of business analysts, data architects,… looking for a solution between drawing tools and low-code tools (more formal than the former, on top of the latter)? Obviously the pricing will play a role here (though from what I’ve seen, prices are really competitive) but for now, you can enjoy a free lightweight version.

I also feel that a clearer transition path between Akwatype and the low-code tools will also be helpful here. Akwatype offers some code-generation features but not enough. So there is either a manual development to complete the app backend or you need to somehow redraw the  models in a low-code tool and use that tool to generate the full backend. To maximize the ROI of Akwatype I’d suggest to either generate models in a format that can be imported by a couple of the popular low-code tools or that Akwatype itself is able to generate full backends. Which, to me, it is not far away from what they can generate already.

The reality is that companies have already plenty of “implicit” models

It is nice to be able to start a development project from scratch. But this rarely happens. Even less on the backend side of things. Akwatype is aware of this reality and has already added to the tool a few importers (e.g. from OpenAPI specs and DDL SQL scripts) to avoid starting all domain models from scratch. Obviously, automatic importers often result in low-level models (as they are a direct translation of the implementation). It would be interesting to see: 1-  how beyond the initial model we can generate the service and facade models and link them together and 2- have the tool to propose some refactorings to improve the quality of the automatically generated models, while still keeping the service and facade models able to transition from these refactored models to the existing implementation so that nothing is broken in the process.

Where is the AI?

I don’t think any new tool can skip questions on the integration of AI in the tool itself. I may disagree in this fever of adding AI everywhere but I do think AI can help speed up the modeling process by assisting modelers with partial models automatically derived from a variety of information sources available in the company. What we call low-modeling.

Akwatype does not include AI-driven features yet but I’ve been told (and I’ve even seen :-)) that this is work in progress and we’ll see them soon. Among this upcoming features, you’ll see an AI assistant to create your own export options, which could bring us even closer to the backend generation I was mentioning before (even if the tool doesn’t offer it by default, you could built it).

 

So, overall, I’d encourage all of you to give it a try and share your thoughts. With their free plan, there is not risk in exploring how Akwatype can help you and explore this new and “fresh” modeling approach. And as the tool is still new, you have the chance to influence its development and make sure it is a great fit for you