Enterprise architecture (EA) clarifies corporate motivations (stakeholders, drivers, goals, objectives, etc.) and the strategies chosen by management to address them.  It creates blueprints (architectures) and roadmaps (plans) for the implementation of the chosen strategies and can use these to provide management with impact and value analyses of alternative strategies.  As strategies are finalized and clarified, enterprise architects use and continually adapt the architectures and roadmaps approved by management to guide strategy implementation.   The sustained practice of Enterprise Architecture enables organizations to continually adapt their investments in people, organizational structures, processes, information, and technology (including IT and physical assets such as factories and vehicles), to changing business conditions.  Successful EA adopters therefore reap the benefits of agility, transparency, and accountability.  

EA requires collaboration across business and technology disciplines, organizational subcultures, and organizational levels.  Motivations and strategy may flow from the top down, but successful implementation requires broad understanding and alignment.  Building broad understanding and alignment requires a variety of views of the architectures and roadmaps that address the concerns of diverse stakeholders while remaining true to the organization’s motivations and strategy—or to a set of alternatives under consideration.  For example, a financial manager may be concerned primarily about revenue, expenses and cash flow, while an operations manager may be concerned about processes and their metrics.  Each view, therefore, is a window on a consistent set of architectures and roadmaps that describe the baseline (current) state of an organization as well as its alternative or chosen transition and target states. 

While it is theoretically possible to maintain each architectural view as a separate diagram or table, this is impractical for all but the smallest and simplest organizations.  The innovation, collaboration and negotiation that is essential to EA requires many iterations of the architectures and roadmaps under development, making it impractical to maintain a set of consistent views in disconnected documents.  Therefore, an EA repository that maintains consistent models of the enterprise and its potential future states is essential.  If an object in a repository is changed, all the views that reference that object are automatically updated.  

EA repositories require a common language, disciplined maintenance and use, and rigorous peer review for success.  The ArchiMate language is the only freely available modeling standard designed specifically for enterprise architecture.   The layers and aspects of the language allow the clear, concise, and extensible expression of all architectural subjects: motivations and strategy; the structure and function of business, information, application, IT infrastructure and physical plant investments; and the programs and projects that implement them. Furthermore, the ArchiMate language easily supports individual models that span all these subjects, enabling rigorous alignment across complex organizations. 

However, just adopting ArchiMate as an EA modeling standard is not enough.  As with any industry standard or shared language, an organization must adopt conventions for ArchiMate usage that align with its business and culture.  These conventions, best expressed in an organization-specific style guide, must be applied, and continually improved, through peer review of ArchiMate models before they are incorporated into a shared repository.  If, for example, two architects use a different model object to refer to the same organization, business process, application, or location, the value of an EA repository is sacrificed.  

The value of an EA repository increases exponentially with its completeness, hence the requirement for disciplined use, at least in specific domains.  Since it is too complex and risky to implement the repository enterprise-wide all at once, initial implementation should be well-defined and mandatory for a particular portion of an organization, e.g., finance applications, where there is an opportunity to demonstrate significant value. Organizations must have requirements for architecture deliverables and consequences for failing to satisfy them, e.g., a move of new finance application functionality to production cannot happen unless the affected assets are properly reflected in the EA repository.  

While ArchiMate templates are available for many drawing tools, modeling tools are necessary to enforce ArchiMate syntax and to synchronize model changes across views.  For organizations with more than one enterprise architect, modeling tools must support collaboration.  Modeling collaboration, like software development collaboration, requires version control to track successive model changes, branching to enable different people to make model changes without interfering with each other, and merging to resolve conflicting changes and combine different people’s work.  A request by an architect to merge their work into an EA repository is the perfect trigger for peer review, ideally by a group of architects that includes the requestor as well as the architect(s) responsible for continuously improving the style guide. 

There are many commercial products that support disciplined, collaborative modeling with the ArchiMate language, but they are generally complex and require a financial and operational commitment to proprietary tools, terms, and processes.  EA repository implementations require alignment, collaboration, rigor, and disciplined usage.  Many organizations therefore need several tries to demonstrate initial value and build a business case for enterprise-wide rollout.  During this process, they may switch tools—at great expense—as they discover their organization’s architectural modeling requirements and idiosyncrasies. 

For these reasons, organizations should implement their first EA repository with the free and open source Archi tool and its coArchi and jArchi plugins.  Archi has been in use since 2010, and release 4.8.1 is currently available.  It supports the current release, 3.1, of the ArchiMate language, and has always provided prompt support for new language versions. Archi is built on the Eclipse integrated development environment and allows only syntactically correct modeling. Archi’s straightforward user interface is replete with a context-sensitive Hints function, a model visualizer and many other features that support ArchiMate learning.  

Archi imports and exports data in tabular (.csv) form as well as in the Open Group ArchiMate Model Exchange File Format, making it easy to integrate with or transition to commercial tools.  Archi can also import data in tabular form from many tools for IT service, portfolio, and project management as well as business process management.  Imports of current and accurate information from these tools, which can often be automated, can add important detail to architectural models and help integrate EA with other business and technology management practices.

Plugins further adapt Archi to the needs of complex enterprises. The coArchi plugin integrates with Github to support modeling collaboration, and the jArchi plugin enables JavaScript automation of model generation, consolidation, analysis, and revision, allowing the emulation of many advanced commercial product features.  The jArchi library is well-documented, and there is a public repository of shared scripts, some of which are quite sophisticated.  

In summary, for a successful EA repository implementation, organizations should adopt the ArchiMate language, pick a high-value portion of the enterprise to for a pilot project, begin with Archi and its plug-ins rather than committing to commercial tools, maintain a style guide, and peer review all work before merging it with the repository.   Successful EA requires collaboration, and successful EA collaboration requires an EA repository.

Authored by Iver Band,  Senior Trainer and ArchiMate Expert