Enterprise Architecture Tools

Thanks to the original writer and article :

https://medium.com/geekculture/enterprise-architecture-tools-b8165c8c9d7

The evolution of Enterprise Architecture

With the advent of digital transformation, many Enterprise Architects have been exiled into corporate IT — reducing their scope of influence to the confines of technology.

Even within technology, Enterprise Architecture is undervalued - often referred to as “Ivory Tower Architecture”.

As technology becomes more prevalent across organisations, the value of EA is slowly being eroded.

“Setting strategic direction has always been an important EA task, but with many companies becoming increasingly digital, it has become a business-level priority.

In the past, major failures affected only the IT budget. Now, they affect the entire business. In a typical retail environment, for example, a major flaw in the overall architecture, such as an integration architecture that doesn’t scale well, would lead to a slight increase in IT costs but only a minor impact on the margin.”

-?McKinsey

According to an?article ?by McKinsey, EAs need to evolve to support three objectives:

1. Enable strategic decisions

2. Ensure reusability

3. Enable development speed

Besides facilitating cross-team collaboration, the McKinsey article doesn’t explain?how?to make this happen.

In my opinion: to position EAs as trusted advisors, they need data. They need a system that models the enterprise — allowing them to mine for insights, perform “what if” analysis and identify opportunities.

This is where EA tools can help.

What are EA tools?

EA tools are knowledge management-based applications that capture, model and analyse data about the enterprise.

Depending on the product, you can also think of EA tools as vertical Business Intelligence products that include additional features such as collaboration, data quality and governance.

Meta Model

The data is organised according to the underlying meta-model — think of this as the schema — containing entities, attributes and relationships.

Based on the Archimate meta-model, the image below depicts the business, application and technology entities.

The Archimate framework also defines the relationship constraints for each domain. The image below depicts the supported relationships within the application domain.

Visualisation and Reporting

Enterprise Architects leverage the model data to create visualisations, diagrams and reports to aid decision-making.

The example image below assesses the number of applications that support each capability. The RAG (red, amber, green) status highlights the application support level of each capability.

Visualisations as depicted below can be automatically generated using off-the-shelf EA tools.

A typical EA model workflow

This section provides a brief overview of how architects leverage EA tools to support the business.

[1] Capture

Data can be imported using a variety of methods. Some examples:

• Connectors: will automatically ingest, transform and load data from standard systems, e.g. ITSM, SQL DB.
• APIs: provide more flexibility, allowing you to build your own integrations.
• File Import: support bulk data loads using standard formats like CSV and XML.
• UI - CRUD: If all else fails, you can load the data manually via the UI.

[2] Model

Once the data has been loaded into the tool, you can begin modelling.

Initially, you may need to prepare the data for reporting. This could involve data cleansing, transformation or adding relationships between entities, e.g. applications and business capabilities.

Depending on the use case and EA product, you can create diagrams, build visualisations or use an existing dashboard.

[3] Publish

Once the model has been updated, you can publish the updates to the EA portal. Typically, EA tools provide a user-friendly UI.

[4] Analyse

You can now assist decision-makers with interpreting the results and providing insights and recommendations.

Challenges

In my experience (albeit limited), I’ve seen the same implementation issues occur across multiple organisations:

• Model too granular: Trying to model everything is nigh-on impossible. With the first EA tool I was involved with, we decided to capture all the third-party libraries for each component…this lasted a week.
• High rate of change: Keeping pace with an ever-changing enterprise is immensely challenging. The more complex the enterprise, the harder this becomes.
• Lack of automation: I’ve seen cases where EAs become data entry clerks, spending most of their time inputting data.
• Poor adoption: lack of training, process and direction, to name a few.
• Cost:?EA products aren’t cheap, and in my experience, most businesses opt for the most inexpensive package — typically, just enough licenses for the architects. The problem, however, is that no one other than the architects will be interested in keeping the information up-to-date. And if it’s not up-to-date, it’s of little value.

EA Tools: The right way

Quick disclaimer: I’m not an expert in EA; in fact, I’ve never done the role (officially). However, I have been responsible for selecting, implementing and rolling out two EA products.

If anyone were to ask my advice (however unlikely) on implementing an EA tool, it would be this…

1. Maturity assessment

Understand where you are?now. Do you have a capability model? Do you have reference architectures? Are the team familiar with model-driven architecture? Do they understand meta-models? Etc etc.

The assessment outcome will help determine what kind of product you need.

For example, if the team is unfamiliar with meta-models, I would opt for a data-driven tool. With this, the team simply captures data, and the tool will take care of the rest — rendering pre-defined visualisations.

2. Identify use cases

Ask yourself why. Why do I need an expensive EA tool? What value will it provide?

The best way to do this is using use cases.

Here are some example use cases:

• Technology lifecycle management
• Cost management
• Application rationalisation
• Roadmaps and strategic planning

3. Start simple

If you’re starting from a position where you have nothing, don’t try and model everything. Take it from me…you’ll fail. Honestly, don’t do it.

Pick a few use cases and focus on delivering an outcome — this could be as simple as understanding what applications support each capability.

Build your own. As an MVP, this could be a few spreadsheets.

A few years back, I worked at a company where we spent a week developing a solution using Power Apps, Azure SQL and Power BI to analyse the application portfolio.

This allowed us to demonstrate the value and prove the business case before going down the procurement route.

4. Create a plan

Most EA product vendors provide guidance on getting started — typically oriented around use cases, e.g. capability analysis, application portfolio management etc.

Building your own EA tool

In addition to the guidance above, here are my recommendations for building your own EA tool. Not that I advocate reinventing the wheel, but as I mentioned above, you may need to “build your own” solution to prove the business case.

• Use low-code solutions, e.g. Office 365: Sharepoint, Excel, Power Apps, Power BI.
• Avoid coding other than for ETL — these solutions can always be reused when, or if, you purchased a fully-fledged EA tool.
• Select a meta-model. I recommend Archimate.
• Ensure the data is easily exportable — this will make your life easier if you adopt an EA tool.
• Start with the logical architecture. For example, starting with a use case like application rationalisation will require you to define the business capability model up-front.