Buck,
Our development teams are organized along lines of business. We have two main developer pools, IBM I COBOL and ASP.NET. But the developers in those pools are distributed across teams that support particular lines of business (i.e., particular departments for the most part). Each team has to develop end-to-end applications for the lines of business it supports.
Thanks,
Kelly
-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Buck Calabro
Sent: Thursday, May 28, 2015 11:50 AM
To: web400@xxxxxxxxxxxx
Subject: Re: [WEB400] Single Page Applications
On 5/28/2015 11:41 AM, Kelly Cookson wrote:
The question I'm being asked is why would we want to have two ways of developing web and mobile applications? That means we will have to maintain two sets of legacy applications and maintain sufficient staff with the right skills. Add that to the demonstrated success over more than a decade at using the ASP.NET approach. So why in the world would we want to add COBOL CGI to the mix? That's the obstacle I have to overcome to sell a CGI COBOL approach, or an IBM i Integrated Web Services approach, or any approach other than ASP.NET.
I fight that here. The problem is that management is hung up on the TCP/IP protocol rather than the user. The actual situation is that there are already two development staffs; one for the external customers
(web) and one for the internal customers (5250). Does it really make sense that the same over-stretched outside group be tasked to handle inside chores too, just because the end result will appear in a browser?
Or is the plan to add to the web team to support the additional workload? That's a real cost to the business for enforcing a 'one web team to rule them all' strategy.
--
--buck
--
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.
midrange.com
