REST/XML, REST/JSON, UOPY/Python, .NET

[Kevin Christensen]

Hello, first time caller... Joined just in time to find out GG may go away?

I recently started working for a very large multi-state company (2500 user licenses) and the interface reminds me of my first Pick job in 1981. I've worked in environments since then that were more modern.  They have been discussing updating, but as with all large companies, everything works at a glacially slow pace... especially when the higher ups have no experience in modernizing interfaces.

A little over a decade ago, I worked for a medical software house that modernized their UI using UniVerse/SOAP/Java with uniObjects.  However, I worked 100% on the Pick Basic side creating fieldtypes that communicated with it, so I'm afraid I don't have the hands on experience to provide this effort.

We are on UniData, that's won't change. My boss steered me away from Rest Services (which I quite liked) because he equated it with going to jBase. I believe that if Rest is the way to go, I can counter that.

In 2021, there are so many options... and NO, we're not interested in a "Rapid Development" "No/Little Code" approach.  What are your thoughts regarding Rest Services vs Python or SOAP (I hope I'm not comparing apples and oranges). I've explored different options, but my head spins with so many choices.  Give me the 50,000 foot overview.  

I'd also love to talk to large companies who have transitioned to a web front end, how they accomplished, what they like, what they don't like, etc.

Kevin Christensen

Salt Lake City, UT

[David Green]

Kevin,

 

I’ve been using UniData with RESTful services for several years and I’m loving it.  The install process is a bit cryptic so make sure you take good notes when someone shows you how.  It can leave hung processes if the backend program dies.

 

But I think it has some really good security.  Normally people don’t touch the backend database directly from outside the firewall, but with the security RESTful server provides you can.  This saves you from having to export to an SQL server first.

 

It is also easy to expand and grow, so you can start with a simple function or two and build on from there.

 

Tools to use:

 

HTML5, CSS3, JavaScript, jQuery, Bootstrap, Font Awesome

 

David Green

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms
---
You received this message because you are subscribed to the Google Groups "Pick and MultiValue Databases" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mvdbms+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/031f6c7a-7c38-41af-b2b1-61d704dea3d8n%40googlegroups.com.

[Kevin King]

REST is definitely the way to go; that gives you all kinds of options on the front end; whether Python, Javascript, PHP, whatever.  I'm not a fan of the Rocket REST tools; they never quite seemed fully baked but it's easy enough to create your own.

To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/000801d6df68%24db5fa680%24921ef380%24%40dagconsulting.com.

[Dick Thiot]

Kevin,

I think that the way to modernize legacy applications like those that have existed as Pick/MultiValue applications for decades is to do it a piece at a time and you don't have to do everything.  You can update areas of the system that make sense to update.  For example, do you need a customer-facing portal, or interface with a 3rd party whether vendor, customer or service provider.  Your task is to replace the User Interface (UI) that you have now which is old and out of date with a more modern UI.  However, you have many users that have worked on this system for years, even decades, and are very proficient at their jobs.  Unfortunately, bringing in new staff is met with resistance because of the "old" look and feel of the UI.  As you stated, you have lots of options.  The key is to remove the old UI and replace it with something more modern in a way that makes sense.  

As for the technologies that you mentioned, SOAP is a bit of an antiquated technology now having essentially been replaced with REST API.  REST usually returns data as JSON but can easily return XML too using the same code.  I believe that UOPY will lock you into Python where as REST really just provides your data wrapped with the business logic to any client/consumer of the data.  There are many ways to implement REST.  I think that the full REST specification is flawed in that it gives too much access to your data and doesn't require it to be wrapped in your business logic.  I have taken a different approach over the years and this has worked well.  However, before I do let me explain your options if you choose REST.

You can use U2 REST API from Rocket where you write subroutines in Unidata and define the data structure in the U2 REST manager and then this data is exposed as JSON.  This can be a good option but I believe has some limitations that may or may not be an issue for you.  The other option to provide access to your data via REST is to implement your own REST server, which calls subroutines written in MultiValue like U2 REST but you have more control over how the data is returned, how authentication works, etc.  The advantage to either of these approaches is that you can use your existing code, remove the input and output logic and just return data that can then be consumed by anything including code that you write in your traditional MultiValue methods.

The long and the short of your dilemma is that in today's world, REST is the standard.  It separates your database from the user interface and that user may be a person or another computer.  

There is a lot more to be considered.  I would be happy to talk with you about this in more detail.

Dick Thiot

To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/000801d6df68%24db5fa680%24921ef380%24%40dagconsulting.com.

[Mike Wright]

It's interesting (and amusing?) to see that your boss was relating REST to jBASE when in fact it's quite possible to build REST APIs for any flavor, as the guys in the thread have mentioned. Heck, here at Zumasys we even offer a cross-flavor library for doing so (MV Connect) which is also baked into jBASE and OpenQM. Technically that means we provide a method for building these APIs that you could lift and shift across flavors--granted, once you're building on jBASE or QM you're likely also starting to take advantage of the advanced PICK BASIC features we've added like objects and classes.

Taking off my Zumasys hat, I would echo what the guys here have said--double down on REST and don't hesitate. To add my own two cents, once you've got the APIs, check out Vue.js :)

[Albert Kallal]

First up, I don’t think it really matters. REST, SOAP, and that whole bag – really! It don’t matter.

Do you really care if the company delivers office supplies uses Ford or Chevy truck? Gas or diesel?

Really, all that stuff is just nuts and bolts.

Furthermore, I doubt you have an actual real choice in this matter anyway.

You think that a company that’s building say REST interfaces is out of the blue now going to adopt say SOAP?

What development stack you wind up with is going to be a choice of the developers and team and people you have or will adopt to achieve this end goal.

In VERY few cases that choice will be made out of the blue – it will be made based on the developers and systems they use. Such is the state of technology that you don’t just choose out of the blue a TRS 80, or maybe an Apple II – the dev stack is TOO large now – it takes too much time. So what team and what skills that team has will determine what software stack you use.

Next up?

Why?

Why why?

What do I mean? I been through this SO many times.

Company:

We need to web enable our application so our staff can work at home, or on the road.

Really? What does that have to do with the web?

Apples and oranges I say.

So, a company was looking to web enable their application. A huge amount of money would be spent.

What did we do?

Well, they bought about 25 rather nice surface pros, we setup a VPN and then setup a nice little shortcut on their desktop to launch the application via RDP (remote desktop).

So, now any Wi-Fi, any location – at home, on the road etc. They can now use that line of business application.

While this was a rich and complex windows application?

ZERO reason existed to convert to web.

Same goes for most of these MV legacy applications.

Every tom, Dick and Harry from a company point of view now has some corporate VPN and what not. As a result, those staff can use, can consume and use that application anywhere on planet earth.

Such companies do NOT need web.

And after you web enable? What benefit have you achieved for the company?

If this was my shoes?

I would take the budget and build a CUSTOMER web portal. Why spend money to web enable a perfectly good internal staff application that everyone uses.

You web enable, and what have you achieved? What have you saved?

How will this investment pay off? You gain next to nothing with such money spent – and all you doing is turning the terminal software into a web browser system. That gets you near zero.

But, over the last 30 years, such companies have HUGE investments in all that computer software.

That’s why I would spend the money on a customer service portal, and not convert the existing system to web.

Why?

Well, when is the last time you used a travel agency?

When is the last time you phoned your bank for a bank balance?

The simple matter is there are HUGE business process(s) that are locked up in that software.

Purolator courier in Canada? I read that introduction of their web based tracking system saved them something like 10 million dollars in the first year! Payback time and cost justification is REALLY high and really fast for such systems. (Payback time was measured in months!!!)

Not to mention that building with 4 floors of people answering phones for package tracking was eliminated.

So, I would look at ANY internal business process that uses that software and systems and AT WHAT POINT of inflection does that software interact with customers?

Why have a customer phone up the company, and then ask what is the status of their project or order or whatever?

What occurs with above?

The staff shoves the phone on their shoulder, starts clacking away on some “legacy” software to get that information, and then emails or speaks over the phone.

Yes, your project is scheduled for such and such.

Or

Yes, your project is being shipped.

Or

Do you want to re-do the same project?

ALL of the above occurs between customers to staff to INTERNAL computer system.

Want to run some SHOCKING numbers?

Say just 10 phone calls per day. Customer to staff to internal computer system.

At 10 minutes per interaction? 

Say only 10 per day of these “events” occur.

That is 100 minutes in ONE day.

In 10 days, 1000 minutes of labor saved!

In 100 days, 10000 minutes!

You can buy a new cool windows accounting package (cool mouse driven UI). But what does that save the company?

You can buy a new nice workstation printer – but what does that save the company over what they have now?

But, opening up ANY business process that occurs from customer to staff to that internal software?

Why not let the customer do that interaction then?

Virtually ANY process from a customer email request for status, for a new order, or ANY process that NOW occurs between staff and customer?

You can build a customer web portal and then let customer’s by-pass that staff (and more important save that staff labor and time).

So, say you have some cool estimating software for golly, who knows what?? (Don’t’ care).

So, sales rep talks to customer.

Sales rep gets what customer wants.

Sales rep gives information to the estimating department.

Estimation department makes estimate.

Estimation department gives information back to sale rep.

Sales rep gets back to customer.

With a web portal? The customer can choose from existing projects (with known estimate values).

Or you give the customer some choices, and SEND that data right into the estimation software. That software then spits back out the estimate, and goes back to the customer web portal.

In other words?

You give me a budget to build some web software for EXISTING line of business software?

Nah – just VPN, and remote desktop or whatever – that gives you the “any place” and “anywhere” abilities. Such cases don’t need the web, nor is the cost justified.

So, at the 50,000 foot level view here?

Enabling an existing line of business application, and spending money to use the web as some nice terminal system? It gains you VERY little.

If one is to spend money on a web system? Spend it on taking ANY business process you have between customers->staff->internal computers.

This might be a simple issue of what is my project status.

Or what is my balance.

Or can we re-do the project and if minor changes – then send those minor changes and values to the estimation software. 

Use the web for customer interaction.

I just don’t believe that cost justification in “most” cases makes sense to take a good existing application and use the web interface as some really expensive and glorified terminal in place of that perfectly good software now.

And upper management NEAR ALWAYS equates “web system” with that of using software anyplace and any time.

So, in place of spending huge amounts? That company just rolled out a bunch of surface pro tables – hooked them up with VPN’s and remote desktop. The result was in a week the whole sales force was “road warrior” enabled. None of this really required nor benefited from “web enable” of that same existing application.

However, if you can find those inflection points, those connections between staff to customer to internal computer? And short circuit that process, and have customer’s by-pass staff?

You not only save buckets of staff money, you also quite much near re-invent your whole business.

So all of architecture and technology choice you want to learn about?

Well, ok, learn some of it. But unless you going to be the sole developer and coding all of this?

Then really, who cares? There is no serious group of people that are going to choose really the wrong technology stack.

But, since such technology stacks have a LONG learning curve? Then that choice will come down to what group of developers and IT people you have, or are willing to get for such projects.

But, spending money on a web system? That should be spent on customer engagement and sending business process to the customers.

This so called low hanging fruit and payback time for money spent on such software?

I not seen such HUGE quantum leaps in money to be saved here.

The LAST time I saw this gold rush and opportunity?

Well, that was when companies adopted its FIRST computer.

I seen companies use what 4 people for 3 days to do payroll at one time?

With a computer? One person in 2 hours now. And payment is sent right into each staff bank account.

But if you buy a web version of the above software? Well, it still takes the staff 2 hours!!! – You save nothing.

So, all these computer systems exist. Huge investments over the last 30+ year to build such systems. Now why not pop open that existing pot of gold?

Let customers work with that data and existing systems!

So enabling customers to interact with all that internal software, and information systems built up over the years? Well, doing that quite much will release the “kraken” in terms of how much money such a move can save the company, and how it can change the future direction of such companies.

And worse yet?

I pity the company that spends a bunch of money to turn existing software into a fancy web based terminal, and their competiros spends that same money on a customer web portal – and winds up eating their bacon.

Regards,

Albert D. Kallal

Edmonton, Alberta Canada

[joseba]

Hi Kevin; you also can use Linkar. In Linkar you can find the tools you need to do what you want in the environment you want. Next week we will launch Linkar 2.1 and the new LinkarFramework. In the framework, you will have tools to work with Unidata form .Net, .Core, java, javaScrypt, typescript, PHP, nodeJs..... etc. And a very very important point, Linkar Framework is OPEN SOURCE, yes you have all the source code and you can modify the libraries, etc. Of course, Linkar provides you a very very easy way to create a restful service, the Linkar REST API. You do not even need a web server to implement the service, Linkar does everything (of course if you want to do it, Linkar can work with IIS, Apache, etc. Linkar is very affordable, you have a Lite license that is actually free. It has some limitations (1 server connection..) and the PRO license costs $58 per database session + $14 annual subscription. Linkar also includes the vsCode Linkar mvconector for free so you can use Visual Studio Code for programming in f.i java or typescript or phyton and in MV DATA BASIC in the same environment. Take a look at kosday.com and if you are interested we can have an online meeting when you want.

[Dennis Bartlett]

Unfortunately you are comparing apples with oranges.

The words you are being 'steered clear' of are just the words used by a different community of developers. Essentially the interface that most of the world currently associates with useful data is the mobile phone/tablet. Five to ten years ago it was the web, from whence words like RESTful come, where the biggest challenge facing the developer was linking separate web / client requests / responses and a whole lot of complication ensued. With mobile apps you completely bypass that minefield, bringing us to the one word in your question that makes sense - PYTHON.

Python is a true marvel in that anything you want to achieve has already been done and all you do is import the relevant packages. That said, you cannot approach Python with a multivalue developer mindset (or rather you can, whilst defeating your purposes). Using Kite you can program in Python at around 20 times the speed of coding in Pick. So yes, learn Python but your main work will come in  converting your existing system to respond to parameters supplied, returning required values, become an API in other words.

So what am I advocating?  

Employ a software house to create a pretty front end template tool much like SB+ without the logic but written to deliver HTML5 pages from template screens, and react to a given set of Fkeys, so that you can configure the actions per screen. Make the F1 always save and exit, F2 always produce a dropdown list, F12 always brings up help, etc so that the result is consistent. Why a software house and not you? because they'll make it work and colours will be professional etc. Also you can specify that the output must work on mobile, tablet or desktop, resizing itself properly.

Then go through your system making copies of every screen generating routine, and changing the copied routine to become an API type program, which returns the value/s it would have put on screen, in a JSON array. You then pass that array to your template tool and the results are displayed on a browser in perfect prettiness. Obviously there will have to be a template drawn up for the screen layout, and hooks set up to act on specific values at specific points. Break down the big single screen routines into subroutines accepting a parameter and returning a value. This way you can arrive at any value as the HTML5 template is populated by the user, the most recent input sent to PICK routine to validate and the next output sent back to the HTML5 template etc...

Effectively the existing system will be slowly converted to a mobile app UI. You can release it in sections. The company I worked for in Dallas, Mouser Electronics, is going through a similar journey and they've chosen a homegrown python template idea. You could contact them for ideas.

El jueves, 31 de diciembre de 2020 a las 0:38:25 UTC+1, kevinsch...@gmail.com escribió:

Hello, first time caller... Joined just in time to find out GG may go away?

I recently started working for a very large multi-state company (2500 user licenses) and the interface reminds me of my first Pick job in 1981. I've worked in environments since then that were more modern.  They have been discussing updating, but as with all large companies, everything works at a glacially slow pace... especially when the higher ups have no experience in modernizing interfaces.

A little over a decade ago, I worked for a medical software house that modernized their UI using UniVerse/SOAP/Java with uniObjects.  However, I worked 100% on the Pick Basic side creating fieldtypes that communicated with it, so I'm afraid I don't have the hands on experience to provide this effort.

We are on UniData, that's won't change. My boss steered me away from Rest Services (which I quite liked) because he equated it with going to jBase. I believe that if Rest is the way to go, I can counter that.

In 2021, there are so many options... and NO, we're not interested in a "Rapid Development" "No/Little Code" approach.  What are your thoughts regarding Rest Services vs Python or SOAP (I hope I'm not comparing apples and oranges). I've explored different options, but my head spins with so many choices.  Give me the 50,000 foot overview.  

I'd also love to talk to large companies who have transitioned to a web front end, how they accomplished, what they like, what they don't like, etc.

Kevin Christensen

Salt Lake City, UT

--

You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms
---
You received this message because you are subscribed to the Google Groups "Pick and MultiValue Databases" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mvdbms+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/dbb2b745-e1f1-4b95-9ddf-25f954989ebbn%40googlegroups.com.

[Tony Gravagno]

On Wednesday, December 30, 2020 at 3:38:25 PM UTC-8 kevin wrote:

Joined just in time to find out GG may go away?

Kevin - Welcome to the group!

As a group administrator I'd be interested in a reference to whatever note you've read about GG. I cannot find any such reference. Google is notorious for under-developing an offering, getting lots of people to use it, and then deprecating it as they move on to the next shiny object. There are websites dedicated this Google habit and the death of so much (arguably) good SaaS. That last bit has not occurred yet with Groups. I believe it's safe to say Groups will be around for a long time ... as bad as it's aways been. :)

Regards,

Tony Gravagno

[Tony Gravagno]

Kevin - About your inquiry: I have been providing consultation and development for companies of all sizes for the last 20 years on exactly this topic. The discussion starts with "Our application needs modernization. What are our options?" The answer cannot be found in the limited scope of this forum thread. The list of options is often specific to the environment, and changes over time. Managers need to try to future-proof against this dynamic. You asked for the 50,000-foot view. That's pretty high so believe it or not, this is "brief". ;)

Let's separate a couple topics. Please forgive, but yes, there are a lot of apples and oranges in this basket... In brief, languages and protocols are irrelevant in a discussion about application modernization. The main challenge of modernization, the part that C-level management cares about, is related to the visual front-end. The languages and protocols are all related to the communications and back-end, which ideally can be swapped out independently from the UI.

About a modernized front-end user interface...

@DQBartlett made a really astute observation here that everyone should internalize: The browser has been recognized as the GUI destination of choice for a long time, and has been synonymous with the term "the web". I don't believe the browser is going away. But with mobile dominance, I can confidently say that a browser-only solution seems about as effective now as a green screen terminal. "Oh that's just great", say the manager and developer who are working intensely on their browser UI. Technology changes, as do the habits of users. We must learn how to adapt. Decision makers and solution providers must think outside of the box that we've been in for the last 20 years, or they will surely find themselves boxed-in to short-lived solutions.  This is not new. I've been saying this for a Long time.

About communications...

Nothing has changed with regard to client and server. The client puts a request on the wire, it gets to the server, a response is returned. The tooling used to exchange messages is not important and we should be able to replace it with whatever comes with the next wave. SOAP/XML, REST/JSON, it doesn't matter. Pick one, create an API, and go with it.

About languages...

Python? .NET/C#? PHP? Java? It doesn't matter. The answer here depends more on the values of the company. Does adopting Python require employment of new staff? Does anyone on staff already have experience with Java? Is the company already running significant resources over .NET? Where is the company on this now and where does the company want to go? Choose the technology pro-actively based on company direction - don't allow the company to re-actively move in a direction based on the comfort zone of individuals.

About built-in communications interfaces...

Thankfully I won't be the first to say this in this thread - communication interfaces built-in to DBMS platforms are frequently under-developed and/or under-documented. I've always been underwhelmed with the interfaces provided by MVDBMS providers. Unless there are significant performance benefits, there's no real logic to single-provider solutions, where we feel comfort in getting communications products from the same company that provides the DBMS. Personally I feel we do much better to get our communications tools from companies that specialize in communications. (And I don't like all-in-one printer+fax+scanners either for the same reason, or website+email, or getting a sandwich from Starbucks - but that's just me.) This also implies a reluctance to code too much into DBMS-specific interfaces, for the time when we decide that there actually is value in getting some data from outside of the MV system.

About protocols...

REST is an industry standard used in client/server and server/server interfaces. It's easy to use and therefore used more ubiquitously. Unfortunately these days everyone calls their web service "REST", when it's just an API. Again, names don't matter. Protocols can be poorly implemented but that doesn't make the protocols bad. (Don't blame the weapon.) Decide what you need to do and make it happen - don't let names sway you or management. Again, you should be able to swap the protocol out without affecting your front-end or back-end. Don't let this decision confuse the others. This is an ala-carte menu, it's not a bundle from the cable service.

Yes, and this was the "brief" 50,000-foot view.

Please permit me to hop into my salesman shoes, which I don't do much anymore. These days I offer more consultation than code. I welcome you to contact me for some free consultation. (Someone here who has done this with me might convey their satisfaction with this first encounter.) After that, if you feel that my insight is of continuing value, I would be pleased to offer more such consultation as a service.

HTH

Tony Gravagno, Nebula R&D

TG @i don't like spam@Nebula-RnD

add a .com after that

All websites currently off-line as I reconfigure my network - but email is up! :)

[Kevin Christensen]

My information on GG is strictly from what I read in the 9/10/20 thread entitled " OT: The death of Google Groups ", while I was researching any previous threads on my topic to make sure I wasn't duplicating content.

[Kevin Christensen]

Thanks everyone for your responses, there's a LOT to digest. There are some great breakdowns of of methodology as well as some assumptions made (both accurate and not so accurate) and I'll be resuming work exploring paths.  I had abandoned my research in part due to my boss dissuading me from my path and the holidays keeping me over-busy. My manager (the person between me and that boss and the person who previously worked with me in another modernization project) is convinced that the only path forward is to come up with a demo showing a realistic picture of our business to upper management.

FWIW, we do have a customer portal which makes calls to UniData via UniObjects, however most of the work is done on the client side and is the work of one developer not associated with our large team of backend programmers.

[Keith Grill]

We needed a facelift to our POS application and did not have the resources, desire or time to jump on the "software tool of the month"  bandwagon.   So, we used the tools available in Accuterm and Wintegrate to update the look and feel of our product without risking the possibility of breaking the functions of our reliable product..  We spent the real money on adding the new features and functionality our users want and need to actually make them more money.  The new face rejuvenated our position in the market's perception without introducing more opportunities for bugs and failures from 3rd parties and layers we cannot control.

--

You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms
---
You received this message because you are subscribed to the Google Groups "Pick and MultiValue Databases" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mvdbms+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/031f6c7a-7c38-41af-b2b1-61d704dea3d8n%40googlegroups.com.

[Bob Markowitz]

Hi Kevin and welcome to the group–

I have laid off responding for about three weeks. Why the no to "Rapid Development" "No/Little Code" approach? Low-code does not mean that the apps have less code than long hand coding, it means that Developers have less long hand coding to deliver a solution. Your company management must want more than just to present a pretty face on the legacy applications. The rest of the word is adopting low-code, MultiValue is slowly adopting it. Check out Forrester, Gartner, IDC, Intellyx, etc.  

Low-code platforms allows companies to modernize legacy and create apps up to 20 times faster than hand coding; receive great ROI; quickly change the apps based upon customer preferences/behaviors, technology changes and market changes – agility: some platforms create open-system solutions and tons more benefits.

Has your company (and I think I know what company you work for) asked the following questions?

• How long will it take to modernize the legacy applications?
• How many programs need to have that “new look and feel”?
• Will the chosen solution only focus on desktop-oriented web applications or will it also provide for native mobile app development?
• Is the staff “fluent” in the needed technologies or require additional training?
• Is there a requirement for hiring new technical staff (if you can find them) or outside consultancies?
• With training, can non-technical in-house staff create web applications and apps?
• Will the “new” software be easy to modify based upon changes in customer preferences/behaviors, technology changes and market changes?
• Will the solution allow for native mobile app development or will there be the need for other technologies – new learning requirements?
• Will the new modernized legacy software create new business opportunities driven by customer experience or will it just provide a pretty face?
• What planned projects won’t get started or finished?
• Including staff salaries, outside consultancies, the creation of additional IT debt, training, time to market, new technology costs – what is the total cost of the modernization project in year 1, by year 5, by year 10?

 Go to the BlueFinity website and request a demo or contact me, what has your boss got to lose? 

[izzizman]

Kevin,

After this wonderful presentation below...ask Bob about a Free Trial of Evoke and see where that gets you !

Izzi

--

You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms
---
You received this message because you are subscribed to the Google Groups "Pick and MultiValue Databases" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mvdbms+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/4fb320e0-cce9-49a0-aaf0-2a276e70e2c2n%40googlegroups.com.

[Bob Markowitz]

Gosh Izzi - didn't you see my January 4 posting? It read -  Tell you what, if you have a real opportunity that could lead to a some business for BlueFinity or if you work for a company that is looking to create new apps and wants to compare Evoke with other products or methods before becoming an Evoke user let's talk.

Oh and if you could create an app that duplicates what Amazon does and you could do it in weeks or days... Who wants a demo.

You may now get off the floor!