Re: Elevator speech on DB2 development and web enablement?

Kelly

as I wrote - IBM I can be anything - it is the people behind it that
desides its
role - it is a simple a that.

In your case you have a cobol team that has no knowlegde of web development,
you hav a .NET team that apparently (looking at your web site) hasen't come
up
to speed in responsive design.So both teams are in back level and no one is
close to make an cross devise app ;-)



On Sun, Oct 4, 2015 at 3:49 PM, Bradley Stone <bvstone@xxxxxxxxx> wrote:

Kelly,

This statement interested me:
"This has been due to .NET having it's foot in the door, thanks to our
corporate web site, and no one knowing how to develop web and mobile apps
using IBM i technologies."

This (mainly that latter half of the statement) makes me think that
application developers these days rely too much on "middleware".

If anyone understood what makes a web application "mobile", "responsive",
etc they'd realize in the end it's just HTML/JS/CSS. And with all the
frameworks available today there's no reason to pick one over another.

In fact, when I was playing with bootstrap a while back I thought.. hey
this is ok. And then I realized why most blog sites look the same (to
varying degrees) today and decided to handle my own CSS for the most part.
:)

The biggest issue isn't what we "call" the IBM i... it's the perception of
what it can do.

When we here .net we think web apps.
When we here IBM i we think green screen.

That's the problem. :)

Brad
www.bvstools.com

On Sun, Oct 4, 2015 at 8:05 AM, Kelly Cookson <KCookson@xxxxxxxxxxxx>
wrote:

Hi Henrik,

One thing I would have expected to find in a logistic and

redistribution

company was a strong emphasize on EDI communication...

We have a team devoted exclusively to EDI. Our team has been involved in
some industry leading projects in foodservice distribution:

https://www.dotfoods.com/who-we-serve/your-resources/ecommerce/suppliers/

Although one of the 3rd party vendor packages used by the EDI team runs

on

the IBM i, our EDI team has no IBM i COBOL developers. They don't do IBM

i

development.

What I also am missing in your description is what the current status
is and what the goal of the technical exercise is e.g. run your web
technologies primarily on .NET with IBM I as a backend delivering raw
data or let the IBM I have a more active role in the overall web

application

delivering runnable components to the overall web application.

You're missing this because this is precisely the question I want to

raise

in my company. Right now, when it comes to web and mobile apps, we're

only

using the IBM i as a database at the very back end of web and mobile apps
(a backend delivering raw data to borrow your words). But this has been a
deliberate decision. This has been due to .NET having it's foot in the
door, thanks to our corporate web site, and no one knowing how to develop
web and mobile apps using IBM i technologies.

I want to raise the question of where this positions our IBM i servers in
a world of web and mobile. Do we really want to position our IBM i

servers

as nothing more than databases at the very back end of web and mobile

apps

that otherwise run on Windows? Or do we want to develop web and mobile

apps

that are hosted by the IBM i (i.e., that use programming languages native
to the IBM i and web servers on the IBM i)?

And, hence, the motivation for this post: What if our shop decides to
deliberately position our IBM i servers as databases at the very back

ends

of web and mobile apps? Should our IBM i COBOL developers be doing things
differently? For example, should they become data-centric developers?

What

can they do to best leverage the IBM i as a database sitting at the very
back end of web and mobile apps?

Thanks,

Kelly Cookson
IT Project Leader
Dot Foods, Inc.
1.217.773.4486 ext. 12676
kcookson@xxxxxxxxxxxx

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.