The Rise of Architect-Made Enterprise Architecture Tools Through Vibe Coding

Enterprise architects are increasingly building their own tools with AI. Is this a welcome development for the profession, or are we creating a new generation of software nobody really needs?

Nov 03, 2026

Enterprise architects tend to have an interesting relationship with technology. Although our work is supposed to focus on the big picture, strategic planning, and organizational change, many of us still enjoy getting our hands dirty with technical things. We experiment with software, write scripts, build integrations, and occasionally spend far too much time perfecting something that could probably have been done in Excel. I certainly recognize this tendency in myself.

With the arrival of AI-assisted software development, and especially vibe coding, this technical curiosity has found a new outlet. Instead of writing the code yourself, you describe what you want in natural language, let AI generate the code, and refine the application through further prompts. In its purest form, you barely need to look at the code at all. A working prototype can sometimes be created in an evening.

And naturally, enterprise architects have started building their own enterprise architecture (EA) tools.

I have done it myself, and I have also been asked to review and comment on tools that other architects have developed. Browsing professional networks and online communities suggests that I am hardly alone.

This raises some interesting questions. Are we entering an era when individual enterprise architects can develop tools that genuinely challenge established software products? Could these applications make EA more accessible and useful? Or are we simply making it easier to create yet another collection of architecture repositories that nobody maintains? It is worth having a closer look.

A Growing Phenomenon?

I have no reliable numbers on how many architect-made EA tools exist, or how many have been created through vibe coding. I suspect nobody really does. Some are publicly available, while others are personal experiments or internal applications that never leave their developers’ computers.

I started noticing these applications through my professional network, when fellow architects shared their projects, sometimes asking for feedback. Similar examples occasionally appear on LinkedIn. I cannot say for sure how many of these tools have been developed through vibe coding, but I strongly suspect that many have.

From what I have seen, most seem to focus on architecture modeling, basically on creating diagrams. Some address quite specific needs, such as helping users identify the appropriate ArchiMate relationship types. There are also more ambitious applications built around architecture repositories.

Until recently, there were relatively few serious free alternatives to commercial EA modeling tools. Archi, an open-source ArchiMate modeling application with extensions available, has been my go-to option for years. I have used it for personal exercises and in client assignments where no EA tool was available.

Now, creating a customized alternative has become considerably easier. Whether this will produce a significant new category of EA software or mainly a collection of interesting experiments remains to be seen.

Why Build Yet Another Enterprise Architecture Tool?

Commercial EA tools offer sophisticated modeling, repositories, integrations, reporting, visualizations, collaboration, and various governance features. However, they can also be expensive, complicated, and rather demanding to implement and maintain.

For a small organization with simple EA needs, introducing a comprehensive EA platform can feel like buying a large enterprise resource planning system to manage the office coffee supplies.

An architect developing a tool for a particular purpose can concentrate on precisely what is needed. Perhaps that means simple modeling, managing an application portfolio, visualizing dependencies, or producing a specific analysis. Features that nobody needs can be left out.

For solution architects, a lightweight browser-based modeling application can also lower the threshold for getting started. Open the application and start modeling, without installing and configuring software.

Vibe coding also makes experimentation much more practical. An idea can be turned into a working prototype quickly, tested with users, and improved based on their feedback. Some of these applications may even be better than certain commercial products for their intended purpose.

I also suspect that many architects simply want a tool that works exactly the way they prefer. Having used several EA tools over the years, they probably have quite specific ideas about how modeling and visualization should work.

And, of course, there is the simple pleasure of building something yourself. I suspect this motivation is more influential than we might want to admit. After all, developing a new tool may be considerably more interesting than updating the current-state application map. But every hour spent coding is also an hour away from actual architecture work and its stakeholders.

From a Simple Application to an Enterprise Architecture Repository

The opportunities are real, but so are the limitations. Much depends on what kind of application we are talking about.

At the simpler end are lightweight tools for creating architecture diagrams, visualizing dependencies, or analyzing architecture information. These can be genuinely useful, either as standalone applications or as extensions to an existing EA repository.

Building such browser-based applications is relatively straightforward with AI. I suspect many architect-made tools are primarily frontend applications that use local files or browser storage. For individual modeling, demonstrations, and specific analyses, that may be perfectly adequate.

At the other end are comprehensive EA tools with shared repositories, portfolio management, reporting, collaboration, and various visualization capabilities. Developing these is a considerably bigger undertaking. A proper backend, database, user management, and supporting infrastructure require much more effort than creating a browser-based interface.

The shared repository is particularly important. Organizational EA work typically requires several people to maintain and access the same information. Without a shared database, managing versions, responsibilities, updates, and consistency becomes difficult. This is also a limitation of traditional desktop modeling tools such as Archi. Although Archi supports Git-based version management, I have found this functionality rather cumbersome in practice.

Another challenge is the quality and consistency of architecture information. A tool may produce impressive diagrams without properly supporting architecture modeling. Does it follow established concepts and relationship rules, such as those defined in ArchiMate? Can the same elements be reused across different views? Is the information structured for analysis and exchange with other tools? Otherwise, architects may end up creating new information silos while encouraging everyone else to follow standards and improve interoperability.

More advanced tools also need integrations, data portability, testing, software updates, and ongoing support. These requirements become increasingly important as the application gains users and the organization starts depending on it.

The initial development may take a weekend. Maintaining the application can turn into a permanent responsibility.

What About Data Security?

A very real concern is the processing of actual architecture information.

EA documentation can contain sensitive information about an organization’s applications, technologies, dependencies, and business operations, and sometimes even personal data. Exposing this information may create security risks.

Some lightweight EA applications promise that everything happens locally in the browser and that no information is uploaded to external servers. This sounds reassuring, but such promises should be verified rather than simply accepted.

For example, an application may use external libraries, scripts, analytics services, or AI functionality. Information may be stored in the browser, and the application itself may have vulnerabilities. Whether data actually stays local depends on how the software has been implemented and what it communicates to external services.

For repository-based tools, data security becomes even more important. Where is the architecture information stored, who can access it, and how are access rights managed? If data is hosted externally, the organization also needs to understand who operates the service and how the information is protected.

Before using a homegrown or otherwise unverified application with real organizational data, I would expect a proper security assessment. This should cover the application’s data flows, external dependencies, storage, hosting, and access controls, as well as applicable privacy and organizational security requirements. AI-generated software is still software, with the usual security concerns and potentially some additional ones.

For experimentation, synthetic or otherwise non-sensitive data is a much safer starting point.

When Would I Use an Architect-Made Tool?

I would distinguish between using a small application for a specific task and adopting one as the organization’s main EA platform.

For limited purposes, architect-made tools can be excellent. A tool that produces useful visualizations from exported architecture information, for example, may provide value without introducing major dependencies. Similarly, an intuitive modeling application that lowers the threshold for creating architecture descriptions may be perfectly suitable for occasional users.

Using a homegrown application as the main EA repository requires more consideration. Without a shared database, it may be difficult to support collaborative architecture work. The organization also needs to know that the information can be maintained, protected, and eventually migrated elsewhere. Someone must take responsibility for the application’s continued development and operation.

The fact that a tool was built by an experienced enterprise architect is encouraging when it comes to understanding EA requirements. However, developing and maintaining production software requires a different set of skills.

Ultimately, a good EA tool should be evaluated based on how well it supports actual EA work, rather than the elegance of its interface or the technology used to create it.

Thinking of Building Your Own?

Having experimented with this myself, I understand the attraction. Seeing an application take shape after describing a few requirements to an AI assistant is quite satisfying.

If you are considering developing your own EA tool, I would suggest keeping a few things in mind:

Start with a genuine need. Identify a specific problem and the people who would benefit from solving it. Consider what your application would offer compared with existing products, including free tools such as Archi and Draw.io. Do we really need another version of Archi with slightly different features?
Keep the scope manageable. A specialized visualization or analysis tool is much easier to develop and maintain than a general-purpose EA platform. Think carefully before trying to recreate everything existing products already offer.
Design the data model properly. Define the architecture elements, relationships, attributes, and modeling rules early. Consider whether users need shared data, persistent storage, and integrations. These decisions are much more difficult to fix after the application has grown. Using ArchiMate or another established metamodel makes things easier.
Take software engineering and security seriously. Review and test AI-generated code, understand how information is processed, and arrange a security assessment before using sensitive data. Production use also calls for documentation, version control, backups, and a maintenance plan.
Make sure your data is portable. The application should support importing and exporting architecture information in commonly used formats, preferably established exchange formats such as the ArchiMate Model Exchange File Format, where applicable. You should be able to move data between tools and switch to another application without losing years of work.
Think about the long term. If you publish the application for others to use, are you prepared to maintain it, fix bugs, answer questions, and keep it working as technologies change? Even a free tool can create expectations among its users.

Finally, consider the alternatives. Vibe coding may reduce initial development effort dramatically, but testing, maintenance, security, and support still require time. Sometimes configuring an existing product or building a small extension to it is more sensible than creating something entirely new.

A Tool Is Still Just a Tool

There is something slightly ironic about enterprise architects becoming enthusiastic about building their own software.

After all, we spend much of our professional lives encouraging organizations to reduce unnecessary complexity, reuse existing solutions, manage application portfolios, and make sensible build-versus-buy decisions.

And now we have discovered a convenient way to create new applications ourselves.

I do not see this as a bad thing. On the contrary, I believe AI-assisted development opens interesting opportunities for making EA more flexible, accessible, and useful. It also encourages architects to experiment and develop their technical understanding. Perhaps the greatest potential lies in complementary applications: specialized analyses, visualizations, and quality checks that use information from existing EA repositories, without introducing another database to maintain.

But the ease of building software can make us focus too much on the software itself. AI makes developing applications easier, but deciding what is worth developing still requires some judgment.

The real challenge in EA has never been the lack of tools. It is getting relevant architecture information created, maintained, understood, and used in actual planning and decision-making. These are largely organizational challenges involving people, responsibilities, collaboration, and working practices.

A better application may help address them. Sometimes considerably. Still, even an impressive repository with beautiful diagrams is of little value if nobody uses the contents. And a simple spreadsheet may be perfectly adequate when it helps people make better decisions.

The same principle applies whether we use an established commercial platform, an open-source application, or something an enthusiastic architect created during a weekend with the help of AI.

The tool is just a tool. What matters is what we achieve with it.

🧐 Can Enterprise Architects Afford to Be Arrogant?

Enterprise architecture seems to attract some strong personalities, and I have met my share of them both offline and online. In fact, some of the most arrogant experts I have met during my consulting career have been enterprise architects. To be fair, many have also been exceptionally good at their jobs.

But how much arrogance can you afford if you are really good? And what if you are not quite as good as you think?

I explored this in my Expert Work by Design article: Can You Afford to Be Arrogant If You’re Really Good?