EPMware is Multilingual...Only Where It Matters.

Let’s talk multilingual. No, not French, Spanish, or German, although EPMware can handle special characters like ç, ü and so on. Without a special install or configuration EPMware can handle these special characters within any field in the application, this includes the critical fields like member names and aliases.

The multilingual I am talking about is the coding kind. Coding multilingual like Java, SQL, Jython, C++, and other custom language that doesn’t yet have a name. There are governance tools available that include multiple coding languages that are made readily available to the users for creating dynamic/derived properties within the tool. Having multiple languages available to code in is great and the reasoning behind it is flexibility. However, having the multilingual available can also have the opposite effect. It can easily cause the “spaghetti effect”. The spaghetti effect is when there are many different things going on that no one can follow it except, maybe, the person who built it. If you can’t follow it, you can’t fix it, right? The “spaghetti effect” can also result in very detailed documentation that, let’s face it, no one will keep updated and it will eventually phase itself out.

EPMware has made it very simple to create dynamic/derived properties within their tool and it’s pretty ingenious. Why not give the developer access to EPMware's backend tables? Isn’t that dangerous? Why no, it’s not. In EPMware you are given SELECT access to the backend tables so you can have a direct way of getting the information you need. For example, you know when you need to scan the whole application, not just one section, to find out if there are duplicates? You can do that quickly without any complexities in EPMware. All you have to know is SQL in order to write a dynamic/derived property within their development section. No looking ???a nested IF statements within the AND, THEN, ELSE statements. It can be as easy as selecting Value From Table Where Blank = ‘Blank,” for example.  You can join and do more complex SQL. If you need to brush up on your SQL, there are a wealth of resources available or you can simply ask us.

You may be wondering if there are libraries already built for common metadata functions in EPMware.. Yes, you are absolutely correct. There are over hundreds’ of such APIs which simply makes your development tasks fast and very simple.. Just call an API with parameter. For example, want to know property value of a member, call remote agent to perform specific task (such as log out users before deployment), send email, and so many other cool tasks that you can do by calling APIs.

Lastly, this can save money! Use a single contractor to write SQL rather than spending time trying to find various contractors to fill the roles of writing a custom language, hieroglyphics, and groovy. Granted, you might get lucky and find one person that knows both but, you will pay a premium.

Simplicity is the word of the day. Reminds me of a popular acronym that we used in the military, KISS, Keep it Simple Stupid. That is what EPMware has done, they’ve kept it simple.


Popular posts from this blog

OAC Metadata Management

EPMware Is Not An Ugly Baby