Best Practices to Implement Enterprise Architecture Management Tools

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.