When evaluating Architecture Management, what aspect do you think is the most important to look for?

It'll all depend on your major focus: Enterprise Architecture, Solution Architecture, Software Architecture, Business Process Management etc.
In general I'd look on model verification, compliance with standard notations (UML 2.x, BPMN 2.0) and ea frameworks support (TOGAF, Zahman) along with extendability and manageability.

Product maturity, product roadmap, existance of a industry vertical, similar industries references, is it compatibile with standards.

Should be Easy to learn. Schould have Information modelling capabilities. A very Good information flow.

The question is rather vague .. here is my take.

Architecture Management does not track well with those who control the purse strings.
And yet transformations - e.g., digital transformation - invariably need changes to the underpinning architectures. While Exec-s aspire transformations - digital or other - they wont necessarily see or appreciate the need for infra-structure transformations.

So the single most important aspect is to engage with / sell to the Exec-s the fact that Architecture Management is essential in the digital age.

Needless to say that the while clean slate architecture (like building a brilliant house on a vacant land) is all too easy, transformation from a legacy world to a well-architected new world (like transforming a thriving city into more efficient city) requires vision, roadmap and dogged determination to execute, all the time navigating the prevailing funding and organisational context. Happy days. :-)

Hope this helps.

First, understand wahat means the Arquitecture Managemente, I think people is confuse with these term anda concept.

Feature and functionality, scailabilty for implementing

I think the performance of the process is the most important figure to look for.

Define your terms! Are we taking about evaluating the quality of EA Management processes, or technology available to support EA?
In either case it's important to understand the maturity of current processes, state of current architecture, rate of change in the enterprise and perceived current "fit" of architecture to business activities.
With that knowledge in hand ... the better current architecture supports current business, and has been able to flex to support changes, the better the practice is. The tooling decision is critically tied to maturity -- don't buy a tool that you can't handle at your current maturity state.
Things I would specifically look for would be compatibility with business process, application and data design technologies. "Fit" with other methodologies (agile, for instance), and support for standards such as TOGAF.

Product flexibility and conformance to the standards.

Security, Feature and functionality, implementation of the product, maturity of product, future maintenance of the product, workforce availability for implementation

Features and functionality which would include also the compatible platforms and direction of the software vendor for future releases.

having a well defined and up to data enterprise architecture blueprint in place

How the functionaility of tool meeting Current Requirement, Future Possibilities.

Before buying any product, we need to analyze what are all the platforms does that application going to support and how simple it is.