Choosing the Right Architecture Tools

Over the years as an architecture consultant, I have come across IT and particularly Architecture organizations in all types of industry with varying degrees of maturity levels and as a result, with varying level of tools and technology adoption. I witnessed organizations using a few very basic tools on one end of spectrum and on the other end some using very expensive and highly specialized set of tools.

As expected, I noticed that there is evidence of direct correlation between organization’s maturity, use of specialized tools, and effectiveness in delivering value through their architecture services, that is, mature IT and architecture organizations are having better success in delivering quality services in timely manner using specialized tools. However, to my surprise, this correlation was not strong and consistent in all organizations.

I noticed there were a few organizations, although on the surface seemed mature, were struggling to deliver quality services on time despite the use of expensive tools. And some were able to deliver value with use of relevant but not necessarily expensive toolset. This was against the conventional expectation.

With a little further investigation, it became quite clear why it was so. I noticed some common patterns and root causes for this discrepancy.

Common sense suggests a tool is meant to be just a means to an end. And so, it follows that one should understand the “end” first before investing time, money, and efforts in finding a tool.

So, this is a true story. In one of the client’s companies the lead architect’s first order of the day while establishing new architecture practice (or rather, reviving dying practice) that also supported enterprise architecture capability, was to invest in what was perceived to be a “good” architecture tool.

All the efforts went towards identifying the architecture tool. Requirements were not fully understood. But that did not seem to be a big problem as the lead architect reached out to the “top” few tools vendors for advice. After a few demos and presentations by the vendors a decision was made to select one and the leaders expected the vendor not only to setup the tool but also showcase a few tantalizing use cases to the senior management so that the investments in the tool could be justified.

The vendor began with the application rationalization use case, that one is the favorite use case of the vendors, a low hanging fruit to showcase. It all looked great in the beginning but afterwards it became difficult to see continuous value of the tool. They had to keep adding more modules per vendor’s recommendations, of course at additional cost. There were quite a few interesting demos given to the management about the newly purchased capabilities but without real need to solve any specific problem.

This situation was a classic putting cart before the horse; without the clear understanding of the problem to be solved a solution was already put in place.

Once the tool was in place, the tool became the focal point; it drove the requirements. Yes, the tool became the proverbial “hammer looking for nails”. All priorities and decisions about implementing those requirements obviously were influenced by the existing capabilities of the tool (or rather, lack there of). More time, money, and efforts went into customizing the tool and integrating it to other similar tools that were brought into the ecosystem without proper requirements analysis.

It was a case of “tail wagging the dog” and continued to incur more technical debt. And when the real requirements popped up occasionally, they shoehorned the tool at great cost to meet the new real requirements. ?No wonder they struggled to deliver value.

Getting educated about “art of the possible” from various vendors is a great idea and leaders must take advantage of that option as often as it is possible since it usually does not cost a dime to them. However, relying on vendors entirely for the tool’s strategy is just plain being irresponsible.

When establishing the new architecture practice traditionally everyone believes a tool is necessary and since funding is usually set aside for such a tool, the lead architects are in a hurry to purchase the tool before the funding evaporates or gets reallocated to some high priority projects. ?Neither the vendor nor the lead architect is interested in spending time to identify the most valuable and viable use cases based on the strategic needs that must be delivered using the tool.

The vendor’s salespeople are keen on closing the deal quickly to meet their quarterly quota, and the lead architect is in a hurry not to lose the funding. This is like an eager young couple wanting to get hitched in a hurry, what the priest to do to prevent the future troubles!

A tool must not be just selected based on someone else’s “best practices” and baseline feature set that vendor recommends. ?This is an example of the “best practices” anti-pattern.

And lastly, one of the causes of failure of application of a tool, even when it is the right one, is the lack of proper roll out of the tool; by failing to provide necessary knowledge and training to all the users of the tool. As they say, “a fool with a tool is still a fool”. People, when they do not know how to effectively use the tool, despite having a great tool they fail to deliver value.

So How Should One Go About Selecting the Right Tool?

Firstly, the tool decision must never be taken in haste. The architecture practice’s operating model must be assessed holistically from people, process, and tools perspective before every planning period considering the strategic objectives to be delivered by the architecture practice by providing right high value and impactful services to its most affected stakeholders within business and IT organizations. The tool to be selected must provide required support for key use cases under the selected architecture services.

See the article “Why Architecture Fails to Deliver and What to Do About It ?” for some context.

Here are the key steps to follow in making the selection of the right tool for your architecture organization.

Identify Users and Use-cases:

In true agile spirit one must first define the users and use cases/ user stories. Each architecture service to be delivered has consumers at the end who benefit from the service. Identifying these consumers from the business and IT organization should be the priority.

One of the most well-known services provided by the architecture practice is to develop architectures (models and views) for enterprise with various levels of details (Contextual, Conceptual, Logical, and Physical).

Under this service, architecture artifacts are produced for informing the users about the strategic changes, providing them sufficient level of details about the current state of the business and technology landscape so that they understand enough to make decisions about the proposed options, and lastly provide sufficient details without any ambiguities about future state of the business and technology landscape to the implementers of solutions so that they can engineer the solution as intended by the architects.

It is important to define the use cases based on individual user’s needs succinctly to reflect their intents (i.e., why they need to use the tool) and expected outcomes (i.e., what results they will get and how). These use cases must also reflect the user experience, security, availability, integration with other tools, scalability, extensibility, reliability, and performance related requirements.

Identifying the Key Capabilities and Features

The use cases (or the user stories), along with the non-functional requirements, should sufficiently drive out the key capabilities and features that you should expect in the architecture tool.

It is quite possible that you may not be able to find one vendor with a single tool who can meet all the requirements for the needed capabilities and features. Usually, this is the reality. There will never be a perfect tool for all your needs. So, the lead architect must prioritize the wish list of capabilities and features and focus only on those that are mandatory, followed by those that are essential. This way, you may be able to whittle down to a smaller subset of tools and vendors to evaluate.

You should also be open for using multiple tools collectively providing the needed capabilities as long as they can be configured to interoperate and be supported easily; and of course, fit inside your allocated budget. For example, some tools are great for modeling but not so good for creating views. So maybe you could consider two separate tools, one for model creation and other for rendering various views according to stakeholder’s interests as long as they can be integrated easily to share the data.

Another reason to consider multiple tools is that architecture for enterprise can be very complex for a given strategic change. The architecture must be developed to support Contextual all the way down to the Physical level models and views and architecture tool requires a very different set of capabilities and features to support development of various models and views at different levels that must be developed for specific stakeholders.

A very few high-end tools provide support for such wide range of capabilities and features, and they are not necessarily great in all the areas equally. So, it is entirely possible that you may end up needing more than one ‘best of breeds’ tools.

Besides the set of essential use cases that support your strategic services you also need these tools to meet common capabilities and features. These tools must improve the productivity and provide fast time to value. In today’s fast paced agile world one cannot afford to spend too much time in creating architecture models and views and perform lengthy assessments.

The tool must also allow full collaboration capability among business and IT users of the tool throughout all stages of the strategic planning cycle. It must support automation to speed up data sharing, analysis, and report generation. And it must seamlessly be able to integrate with the rest of the IT ecosystem so it can be easily and securely used, monitored, and managed.

For a typical enterprise architecture tool, it must be able to minimally support modeling of standard business objects such as, business strategy, goals and objectives, competitors, partners, products (goods and services), OKRs/KPIs, metrics/targets, risks and cost associated with these objectives. ?They should also support modeling of other related business objects e.g., various application, data and infrastructure items, services supported by these technologies, business functions and value streams that enact these services, more detailed business processes involved within the value streams, etc.

These tools should be able to support modeling of operating models at the highest conceptual levels with value chains and customer journey maps. They should also be able to create business capabilities model and provide mapping with all the above business objects with programs and initiatives in form of projects, themes, and epics and be able to create actionable capabilities roadmaps.

These tools should be able to support creation of various solution and technical architecture diagrams using standard modeling languages such as - UML, BPMN, ArchiMate, and many other similar modeling languages.

All such capabilities should be identified and prioritized while creating selection criteria for evaluation of shortlisted vendors and their tools. Prioritization is the key to defining concise but effective criteria. You must not have unnecessary or even ‘nice to have’ criteria items that are not relevant to the selected use cases.

Sample Capabilities and Features

The following list of capabilities and features should help you as a starting point. You should select only those that matter to you and build upon it to create more comprehensive list of essential capabilities and features by reviewing your specific architecture objectives and essential services you have decided to offer to the business and IT organizations.

Modeling:

• Supports various modeling languages and various standard architecture frameworks (Zachman, TOGAF, ArchiMate, BPMN, UML, etc.)
• Provides accelerators and ready templates for quick and easy data entry, modeling, and diagraming (for example, ready graphics and icon libraries, Azure, AWS, GPS, IBM cloud service/resources Icon library) ?

Versioning and archival:

• Supports both “As is” and “To Be” models and views with version control.
• Supports back up and archival of the older models and views.

Configuration:

• Provides accelerators and preconfigured forms for ease of use and data entry
• Trivial to configure, should not require help

Integration:

• Supports Integration out of the box with other tools with minimal customization (using standard interfaces and APIs), such as - Content Management (CMS), Configuration Management (CMDB), Service Management (e.g., ServiceNow), requirements management (e.g., Jira, Confluence), product and project management (e.g., any leading PMO tools), Visualizations tools (web based), Business intelligence, data modelers, application performance (APM), etc.
• Supports automatic synching of data with standard data formats and data exchange protocols (xml, xpdl, SVG, CSV, SQL, Rest, etc.)
• Support easy import and export of data in and out of the tool.

User experience and Visualization:

• Supports variety of views, standard model diagrams as well as more sophisticated artistic charts, graphs, catalogs, and tables.
• Supports generation of outputs in various file formats (image files, pdf, MS Office, Vision, etc.)
• User friendly, flexible, and customizable visualization features (visually appealing look and feel, dynamic renditions, and configurable styles)
• Supports automatic / dynamic generation of views based on updates in the model
• Supports heatmapping, filtering, road mapping, etc. views
• Supports modern intuitive UI/UX with all standard usability features that users are already familiar with. ?
• Stakeholder specific preconfigured views, reports, and dashboards.
• Ability to highlight changes. Comparisons between old and new versions, etc.
• Supports variety of search, filtering capability while data modeling and view renditions.

Collaboration

• Supports single repository
• Supports co-authoring and sharing
• Supports remote access

Analysis:

• Supports impact, gap, scenario-based, cost, etc., analysis
• Supports prebuilt algorithms and calculators for the above analysis e.g., Total cost, Return on investment, net payback period, etc.
• Supports traceability and lineage of changes
• Supports predictive analytics for scenario outcomes and future state architectures

Extensibility:

• Supports extensible Metamodel (objects and relationships)
• Allows for customization of metamodel and templated views.

Availability:

• Tool is highly available per expected SLO/RPO/RTO
• Available anywhere

Security:

• Supports integration with enterprise identity and access management and identity governance systems.
• Supports role-based access to features in the tool. Supports multifactor authentication
• Supports data security, encryption at rest, in motion and in use.
• Supports data classification and segregation
• Supports full audit trail and integrates with SIEM

Scalability:

• Supports future growth in architecture services and activities.

Reliability:

• The tool is resilient (i.e., recovers fast) and reliable as per your organization’s reliability standards.
• Supports integration with your standard application performance monitoring tools

Performance:

• The tool performs as per your organization’s performance standard requirement.

Cost:

• The total cost of ownership is low (within your budget)
• Return on investment in the tool is high.

Deployment:

• Supports Deployment modes as per the IT standards (On-premises, private/public cloud)

Technical Support:

• It is fully managed (preferably in public cloud) so, users can focus more on using the tool rather than managing and supporting the tool.
• Technical support options available per your SLA needs.
• Provides great documentation and knowledge support

Vendor credibility and Product adoption:

• Vendor is mature and in business for reasonable amount of time
• Has a growing customer base and gaining market share
• Already established
• Able to provide client references for you to verify

Defining the evaluation criteria and performing evaluation

Based on your mandatory and essential use cases and list of key capabilities and features that you expect in the tool you can create evaluation criteria. You may use any standard scoring methodology with equal weights, or you may add weights for some capabilities and features higher than others depending on your needs. Ensure to have explicit mandatory and essential categories for capabilities and features and keep “nice to haves” to a minimum.

Collect the scores from all the key business and IT stakeholders to create shortlist of vendors and tools for further evaluation.

Depending on your organization’s standard practices you may conduct an informal or formal request of information and proposal (RFI/RFP) steps and get the shortlisted vendors to present their product details for your reviews. Based on the feedback from the potential users and management within business and IT organizations who have the high stakes in the tool you should score the evaluated vendors based on their presentations to determine how close they came to meeting the essential use cases and key capabilities and then select one for the next approval step.

As a next step you may want to conduct a proof-of-concept (PoC) assessment of the tool supporting a select set of use cases and ensure to assess all the key capabilities and features as a part of this PoC.

You may even further host a pilot instance of the tool if the vendor agrees to do so, for users to play with to get a firsthand feel for the tool and experience its key capabilities and features.

If all goes well according to your expectations, then you may take it to the approval stage and finalize the purchase of the tool (or the SaaS service if it is in the public/vendor cloud).

You must ensure that the vendor provides all the accelerators for your team to enter the initial data into the tool efficiently and accurately. Get all the help that you can get during the warrantee period to ensure every user is comfortable with the tool and the tool performs and delivers all key capabilities and features as per your expectations.

Make sure all the business and IT users and stakeholders get proper knowledge transfer and training so they can use the tool like an expert user. The tool can be considered fully operationalized only after every user is fully trained and is comfortable to use all its capabilities and features.

Here are the leading vendors in the enterprise architecture tool space (circa 2021, courtesy Gartner). This is a useful list to be aware of the reputed, stable, and mature players in this space. However, it is up to you to determine based on your strategic needs and use cases what tool will meet your requirements and whether you even need any of these tools. You may be able to get away with simple set of tools for most of your simpler architecture services; such tools may already be available to your business and IT/architecture users (e.g., MS office, Visio, Jira, and whole range of free online diagraming tools, etc.).

It is not about what tool you have access to, but it is indeed about how skillful you are and how you use the tool to solve your problems effectively. Of course, specialized tools will certainly give you the edge if you use them correctly, but it comes with additional price tag which you may not afford given the level of maturity of your architecture organization.

Not to sound like a broken record but tool is just a means to an end, so choose a tool wisely that meets your needs (and not the other way around).

By the way, although this article dealt with architecture tools as the subject matter, you may have noticed in general the content equally applies to any type of tools in IT service management area.

_______________

Author: Sunil Rananavare, IT Strategy Planning and Architecture (CIO Advisory)

Follow me on LinkedIn to stay informed. Share the article if you found it useful.

The views in the article are author’s own and not necessarily of his employer.