Mapador fully understands that every client may have unique needs. This is exactly why Mapador’s technology was architected and designed so that it can provide targeted solutions to our clients. The components and modules can be seamlessly packaged and customized to deliver a custom solution for requirements that otherwise could only be handled manually. Over the years, our technology provided significant cost savings to numerous projects, from carrying out mass, targeted and one-time changes across the full enterprise to implementing test environments or replacing outdated documentation with direct, automatically refreshable knowledge repositories.
A typical parser product finds ‘physical’ components and relationships in the technology it is designed for. At best, such parsing covers the full, standard syntax of the technology at hand:
In the example above, if a method calls a custom object that in turn accesses a database table, such custom code would not be understood by a typical standard parser. As a result, some impacts and connections would be missing from the output.
At Mapador we believe that incorrect and incomplete automation can result in serious failures. At the same time, it is highly unlikely that a tool, out-of-the-box, would handle ADP’s code base without errors.
Mapador’s uniqueness stems from its ability to cover and connect a large number of technology types and, at the same time, taking the client’s specific code and frameworks into consideration, as described below.
Ability to customize parsers
In our experience, every client uses at least some unique coding practice that, if left unhandled, would break the impact analysis. Mapador’s process is rules-driven, thus it can quickly adjust its parsers and environment to ensure full automated coverage of the code at hand.
Ability to define ‘logical’ components and relationships
These components and relationships only exist for a specific client and are based on some rules, specific to the client. For example, clients may define systems based on naming conventions, the location of directories or a combination. Mapador can define and connect ‘logical entities’ (such as an application or sub-system) to the physical entities found during parsing, thus representing the code base according to a structure familiar to our clients.
Mapador can also define ‘logical relationships’ that may connect one or more physical or logical entities. The diagram below depicts how Mapador’s technology covers the full application portfolio, regardless of custom coding and presents the results according to client specific definitions. As a result, ‘logical relationships’ such as ‘System A is related to System B’ can be shown in the repository, as well as a full and correct impact analysis is possible, even across technologies.
We strongly believe that Mapdor’s unique technology is the best fit for any solution you are looking for, regardless of potential custom coding or technology boundaries.