Enterprise Architecture Tools
Before we look at best practices to implement an enterprise architecture tool, it helps to take a quick look at some of the software. In today’s market, there are five popular tools:
- Avolution ABACUS
- Progress OpenEdge
Let’s take a quick look at these tools and what they offer.
This is our preferred enterprise architecture management tool. We use ABACUS for enterprise architecture modeling and as our enterprise architecture repository. The reason we prefer ABACUS is that it is designed to support an analytical approach to enterprise architecture. ABACUS helps your enterprise architecture team to make decisions and manage change through a result-driven approach. This means that your enterprise architects can analyze business developments, model the people, processes, and technology, build roadmaps and align the IT and business strategies.
The ABACUS software has some capabilities that set it apart from other similar software in today's market such as:
- Collaborative browser-based catalogs that help keep information up-to-date.
- It has an unparalleled ability to perform option analysis and gap analysis to guide your roadmaps.
- ABACUS allows users to develop a single source of truth usable across the organization by enterprise architects, implementers, and stakeholders.
- It features a built-in ability to calculate business-critical metrics or export key data to Microsoft Excel.
Through a real-time overview of your business potentials, ABACUS helps you boost your business transformation.
LeanIX enterprise architecture management allows your organization to leverage technology, make decisions, and manage change using a result-driven method. With easy access to relevant data, you can speed up decisions, reduce risk, and save on cost. It helps you fast-track your business transformation through real-time overviews of your business capabilities. LeanIX offers three key modules:
- Technology Risk Management: This detects risks from obsolete IT components.
- Application Portfolio Management: Allows real-time overviews of the IT landscape.
- Business Transformation Management: This enables businesses and IT teams to work more collaboratively.
We find that LeanIX is highly focused on addressing IT-centric issues. Although this is a common requirement, if your enterprise architecture team is focused on providing enterprise architecture to support strategy or portfolio, then you will find it constraining.
Progress OpenEdge helps you choose your path to application modernization through powerful monitoring and agile functionality. Most organizations have relied on critical enterprise applications that were built years ago but yet they have evolved in an unmanageable way. OpenEdge powers the process that allows you to take control of your application evolution during all the stages:
- Architecture: refactor and expose codebases to allow apps to be easily adopted.
- Cloud: scale applications quickly and efficiently
- Data Integration: boost uptime, increase extensibility, and fortify security.
- Security: continue to evolve the protection of your applications.
- UI/UX: update and improve user interfaces for a better user experience.
- DevOps: optimize resources and improve efficiency.
OpenEdge provides an innovative and affordable solution to help you thrive in these areas.
OpenEdge is tightly focused on addressing application-centric questions. While this is very important, if your enterprise architecture team is focused on providing business architecture, or broader IT-architecture then it is constraining.
Ardoq visualizes data to help you make more informed decisions. Utilizing meta-analysis and the power of a graph database, the tool can help you uncover powerful insights to inform your decision-making. Key features of Ardoq include:
- Business Capability Modeling: manage your resources to ensure they are working more efficiently.
- Strategic Execution and Alignment: reduce operational risk with security threat detection.
- Data Flow and Integrations: see your enterprise architecture in a simple, visual way to streamline complexity.
- Business Process Modeling: automatically record activities to ensure compliance.
Ardoq is a powerful data-driven tool that will help you with your digital transformation journey.
iServer is a highly flexible enterprise architecture tool that can immediately improve productivity. The tool is easy to install and can quickly help businesses align to industry standards, reduce risk, and ensure robust governance. This helps businesses see a fast return on their investment (ROI) and improves their performance. The key features of iServer include:
- Visualize Future Performance: Transform data into compelling reports and visualizations.
- Engage with Stakeholders: Communicate across business functions and engage stakeholders on the tools they use and the results that they expect.
- Unify Enterprise Data: Collate data in one central repository.
With highly focused onboarding and excellent support, iServer is an acceptable enterprise architecture tool. However, we find that constantly focusing on diagrams keeps the enterprise architecture team at a low maturity level.
As we have seen, there are several tools, each offering varied ways to implement your architectural changes. It’s now up to you to choose the right one. Each of these tools offers unique additions to your enterprise architecture. But what sets them apart when it comes down to picking one of them? What are some of the things that you should look for when choosing an enterprise architecture tool?
Things to Look for When Choosing an Enterprise Architecture Tool
There are a couple of fundamentals that you should look out for when selecting an enterprise architecture tool. The following are five key questions that you need to consider:
How Long Does It Take to Offer Value?
When you purchase an enterprise architecture tool, you definitely want to see returns on your investment as soon as possible. For this, you need an intuitive tool. You want your enterprise architecture tool to offer early insights and adapt to your organization’s models going forward.
Does It Automate Key Functions?
Enterprise architecture tools should have the ability to automate basic functions and make your processes more efficient. This is an important consideration when choosing the right tool for your organization.
Does It Support an Optimized Meta-model?
The primary function of an enterprise architecture tool is to support your enterprise architecture team. This support is a ripple effect because your enterprise architecture team is designed to support stakeholders and answer various questions. Although most enterprise architecture tools are designed to use a locked enterprise meta-model, you need to find one that tackles the exact problem that you are experiencing.
Does It Offer an Integrated Platform for Corporate and Product IT?
In the past, product IT and corporate IT have been kept separate, but in the modern business environment, they are becoming more aligned. For this to take place, your enterprise architecture tools need to be compatible with other solutions in SaaS and Value Stream Management.
Does It Facilitate Full Collaboration Between IT and Stakeholders?
You need an enterprise architecture tool that enables someone without a computer science background to understand the data presented to them. When stakeholders can look at the data from the IT team and have full confidence in their business decisions, then your tool is effectively functioning.
Best Practices to Implement Enterprise Architecture Tools
Now that we know what to look for in a great enterprise architecture tool we can move on to the deployment stage. Let’s take a look at some best practices for implementing enterprise architecture tools while developing high-functioning enterprise architecture teams.
1. Support Your Enterprise Architecture Use Cases
It is usually frightening how often people shop for tools before thinking of their modeling and analysis needs. We recommend you purchase a tool that helps you analyze your enterprise architecture use cases and facilitates effective change. Of course, the end goal is to guide effective change, but the question is what kind of change? Enterprise architecture use cases describe types of change. Therefore, the first step is to identify and support your use case.
The following are some of the enterprise architecture use cases:
- Strategic or Disruptive Change Use Case
- Incremental Change Use Case
- Supporting Strategy Execution Use Case
- Supporting Portfolio Development & Execution Use Case
- Supporting Project Execution Use Case
- Supporting Solution Delivery Use Case
- Mitigating Technology Risk
- IT Modernization
- Digital Transformation
- Cloud Transformation
- Acquisition Integration
- Security Architecture
- Application Portfolio Rationalization
Which of these use cases best describes what your organization’s enterprise architecture team aims to achieve? We recommend working backward from the primary use cases, information requirements, model, and analysis needs before picking an enterprise architecture tool. If you do it the other way around, you will end up buying expensive shelfware that doesn’t compliment your enterprise architecture team.
Clearly define and clarify your use cases and determine the data inputs, models, and analysis needed to support these. Engage with your stakeholders, both IT and business, to ascertain there's a full understanding of the functional requirements, business challenges, and objectives. Involve your enterprise architecture team and consumers (stakeholders and implementers) since you serve them differently and you might need different features in your tool to cater to their varied expectations.
Focus on your core use cases and identify the most pertinent challenges and areas that need change. You also need to confirm that you have the enterprise architecture team skills/ capabilities to address the use cases. Develop a clear rationale and create a roadmap for the work and outcome of implementing an enterprise architecture tool.
We'll be frank. We have been engaged to save several enterprise architecture teams that bought tools that do not support their enterprise architecture use cases. Developing your enterprise architecture team is critical.
2. Test Key Features
Your enterprise architecture tool will only be justified based on the productivity of your EA Team, and quality of your enterprise architecture. Don’t look at random features or outcomes suggested by a vendor. Ensure that you use a rigorous use-case-driven approach to determine whether they can show their tools in the context of your use case. Conduct thorough research to shortlist and choose vendors whose core capabilities align with the organizations’ use cases.
You need to communicate the documented requirements of the enterprise architecture program to the vendors of the enterprise architecture tools. Pay very close attention to the direct support for your specific use cases. To get an accurate assessment of the features and functionalities provided by the tool, schedule a demonstration in your organization and ensure all relevant stakeholders are present. Stakeholder presence and participation are important so that you get feedback and so that the vendor can be questioned further concerning each capability area. Ensure that you consider the data input and reporting output in your evaluation.
3. Model by Project
You must develop your enterprise architecture model bit by bit and avoid falling victim to instant gratification. The TOGAF Framework which is an industry leader and a personal favorite, drives home the best practice of an enterprise architecture development project. You need to engage specialists (consultant or vendor) for the deployment and to build a foundation for the enterprise architecture program. As you develop your model, ensure that you develop data management and data governance as well. This will result in long-term improvements to internal and operational efficiency.
Don’t get lost in what the tool might do, especially if the tool is based on a use case that isn’t core to your enterprise architecture team. Overly focusing on what the tool might do risks the downfall of your enterprise architecture team. Instead, we recommend delivering use cases that your stakeholders care about. Think of an end-to-end enterprise architecture, i.e. from process management via the modeling of business data, to the creation of a repository for processing information systems of the organization.
The first step is to look at your process from information collection to analysis, decision support, and implementation governance. Secondly, look at where your enterprise architecture tool fits in. Avoid early customization. The more you use the tool, the more you speed up architecture development and improve the quality of your enterprise architecture. Don't customize before you have to. Instead learn the software's core components and learn how to use a model and data-driven analysis. In the long run, this practice pays off when you bring in new staff and it effectively reduces the time spent in bringing these new staff up to speed.
Leverage the vendor’s consulting knowledge for the implementation, and draw from architecture best practices and foundational enterprise architecture knowledge as a whole and not just the expertise knowledge. Use an incremental approach to learn how to handle the architectural work and where to integrate it. Focus on a few basic use cases at the beginning and then gradually increase complexity. Ensure that you implement the fundamental components before adding any more features. Ensure that the structure and processes of the enterprise architecture are in place before scaling out the models. This entails defining roles and assessing risk levels in each area.
4. Develop Enterprise Architecture Skills (Dedicate Resources to Drive the Enterprise Architecture Tool Effectiveness)
Bad models are simply that, bad! Effective models require an understanding of how to represent things. You will need training on the features of the enterprise architecture tool (how to drive the tool) and modeling (selection of model kind, integration with/ separation from an enterprise model). You will also need training on analysis and exercising the models. You may need to add specialized skills to enable your architects to perform their duties, i.e. conduct analysis based on concern, preference, and constraint, exercise the model, and engage with stakeholders.
Build foundational data-driven enterprise architecture capabilities and skills among end users such as enterprise architects, to champion the learning efforts. These skills are transferable from one tool to the next. Utilize the online and sit-in courses available and increase the team’s understanding of the tool to extend the meta-model at a later stage. We propose dedicating resource teams to drive the integration and adoption of the tool. This can be an in-house enterprise architecture team that can guide and manage the modeling efforts from the beginning.
Progressively increase the training of staff and promote continuous training from the onset. This is important because we must work in a continuous cycle of improvement and ensure that the vendor facilitates this effort. Ensure extra training for users and create a more structured repository. An efficient enterprise architecture tool is easy to deploy and allows a significant amount of flexibility. However, this comes with the challenge of knowing what it is exactly you want to do with it and how to proceed. This means that any enterprise architecture tool requires a high level of maturity, discipline, and expertise from the teams using it.
5. Avoid Data Overload
Enterprise architecture tools can sometimes drown in data. Ensure that the data for all the departments are segregated and stored separately. Your organization constantly changes and this is inevitable. In a couple of years, you might rename your departments, or add and decommission infrastructure. The more detailed physical data loaded, the less you have an architecture tool. Minimize the data used for the enterprise architecture tool to necessary things. Otherwise, you will find yourself creating a data monster.
TOGAF mentions in the first steps of Phases B, C, and D that you need to figure out the models you need. Your use cases will determine what models your organization needs and anything else that isn’t needed is a distraction. Models have a core purpose from their inception, which is to help you simplify and understand the interaction. Keep the modeling data entry to a minimum with only data necessary for the project entered. Never migrate data from existing systems to the enterprise architecture platform, instead we recommend selective harvest of data based on the architecture project. Keep everything logical for as long as possible. Logical models have proven to stand the tests of time and they rarely change. What usually changes are their attributes about them.
6. Avoid Integration
Integrations often take you to the physical world and start to replicate other information. The moment your model becomes bit by bit a replica of the physical map, then you are building a digital twin rather than an enterprise architecture model. Even if you have a use case in line with application rationalization, there is no need for a detailed count of instances and pricing models. Each system within the organization is designed for a specific purpose e.g. asset management, cost accounting, and IT operations, among others, and if the purpose doesn't line up with that of the enterprise architecture then the data will not align as well. You need absolute clarity that your use cases align with the data in other repositories.
Many software vendors speak strongly about their integrations, but they are almost always chasing two use-cases at a project-execution level - application rationalization and IT infrastructure modernization. They passionately explain detailed project planning, but we are sorry this isn't enterprise architecture. The goal of enterprise architecture teams is to guide effective change in line with their stakeholders' use cases. If the team can’t deliver this, they are shut down or replaced. Be hesitant when it comes to data integration because most use cases are usually harmed by the data noise and distraction from integrations.
We recommend that you never integrate your enterprise architecture tool with an asset management system, a configuration management database (CMDB), a source code management tool, or with a change management tool.
Last Thoughts on Best Practice to Implement Enterprise Architecture Tools
Software is an integral part of enterprise architecture, and these powerful tools can make a huge difference to the performance of a business. The enterprise architecture market is adequately stocked with options, and it’s often just about finding the software that best matches your needs. However, it doesn't end with choosing a good enterprise architecture tool. The implementation matters too. If not properly implemented, most enterprise architecture tools fail.
The best practices highlighted in this guide will help your enterprise team to increase the success during the implementation of the tools. Conexiam offers an Enterprise Architecture Capability Workshop to identify the best enterprise architecture team and supporting tools.