
Windows and Line of Business Applications: No Good Options - zura
http://www.infoq.com/articles/Win8-LOB-Options
======
randomfool
Cringe, laugh or cry if you will, but LoB development has essentially moved to
the web.

Overall I think Microsoft's metro/winrt/client focus really abandoned their
position of strength in the enterprise. This essentially forces existing
Microsoft-friendly enterprises to switch technology stacks (WinRT is a non-
trivial migration target) and at the same time gives a significant boost to
HTML- the long trail of abandoned platforms should give everyone pause when
considering a new one.

I'll put much of the responsibility (blame?) of this on Sinofsky who
essentially wanted a clean slate for WinRT to ensure apps were designed for
Metro and not half-assed ports. This strategy was fairly cocky and I'll argue
could have been done with more finesse to not destroy as much marketshare-
right now Win8 needs every inch it can get.

~~~
avenger123
Agree to this. Most of the enterprise applications I have worked on in the
last 7 years have been web based.

The default question is now, why not Web? A justification needs to be made as
to why its not web based.

With ASP.NET MVC I feel there is better control of large datasets so that the
whole set isn't loaded at once which WebForms made so easy to do.

~~~
_random_
The inevitable sequence of questions:

1\. Why not Web? 2\. Why not NoSQL? 3\. Why Microsoft?

~~~
avenger123
I don't want this to start into another debate.

For most companies, its either Microsoft or Java stack. There isn't too much
in between. And frankly its not a bad stack when money is not a factor in
deciding the stack.Most companies whose core business isn't software just want
to get their job done. Microsoft works well in this space and will continue to
do so. Frankly, with Java being part of Oracle, I feel there is an even more
push to Microsoft.

Obviously this is my opinion but I don't believe I will running out of work
any time soon on the Microsoft stack.

~~~
derefr
> For most companies, its either Microsoft or Java stack. There isn't too much
> in between.

I find it odd that the "Unix stack" isn't considered a horse in this race.

~~~
ebiester
So which of them work well with Oracle, SQL Server, and DB2 drivers? Your
average fortune 500 company isn't moving to PostgreSQL for the hell of it.

They're running on top of unix, but it all comes down to the database. And the
java and .NET drivers are the best options. Rails has oracle and DB2 options,
but how many people are using them? How well are they supported? How many
people are around if you run into problems? What list of consultants can you
hire when an advanced problem comes up?

Otherwise, you're stuck with a labyrinth of ETL jobs between the main DB and
your internal app. That's not going to bode well, especially with JRuby
around.

The other option is writing your business logic in the JVM and doing rest
calls between that and your front end. I've heard multiple discussions of this
(and even seen it done a few times.) But that's not getting rid of the JVM.

------
dmethvin
Perhaps this could be retitled "Having cake and eating it too: No good
options."

Big companies want technologies they can invest in that will remain stable and
supported for a decade or more. Hell, many of them are upset that XP isn't
being supported for longer than that.

If as a big company you had been a leader and built a web-based app in, say,
2005, it would most likely be a mess of hand-built DOM libraries that sniffed
for specific browsers and most likely were wired to IE6 or IE7 (remember,
jQuery didn't even exist yet). The "good options" that corps are choosing to
use today mainly involve forcing newer versions of Internet Explorer into IE7
or IE5-Quirks mode so they don't have to lift a finger to change that
festering pile of custom JavaScript.

I'm not convinced that any technology exists today that will be so set-it-and-
forget-it wonderful that companies should plan to build it now and leave it
the hell alone for a decade. But that's what they've demanded of the last
generation of apps they built.

~~~
bradleyjg
> I'm not convinced that any technology exists today that will be so set-it-
> and-forget-it wonderful that companies should plan to build it now and leave
> it the hell alone for a decade.

Perhaps not, but there probably should be. A lot of LoB applications don't
really need to keep up so to speak. Employees learn how to use them, and they
accomplish whatever business process goal they are supposed to accomplish. Yes
maybe they look or feel terribly old fashioned (curses anyone?) but as long as
they get the job done, why should they need to be re-written every 10 years at
considerable expense and risk?

------
daigoba66
Many of these technologies are certainly supported (WinForms, WPF,
Silverlight, etc). It's just that there isn't and won't be any new development
on these products in the future. Microsoft is putting all of their focus into
WinRT and Web development. On the one hand, yeah it kind of sucks that the
platforms they built over the last 10-12 years are obsolete. On the other
hand, they're moving an incredible pace around developing tools for WinRT and
Web development (especially Web, which I keep up with in my day job).

~~~
Pxtl
MS went through a terrible process of whipping up and discarding frameworks a
few years back... the churn of Linq2SQL being abandoned almost as soon as it
was launched, Silverlight, all those rapid-fire dead-ends. Plus there were
some horrible false-starts - EF3.5 was nightmarish, as was ClickOnce, and I've
been less-than-impressed with SqlCE. I love the newish linguistic features of
C#, but I've seriously slacked off in learning the new libs after being burned
so many times. I still use WinForms for Pete's sake.

Has it settled down enough? Is it safe to start learning about WinRT? To
actually figure out how MVC actually works instead of doing my best to ignore
it while I do everything in Javascript and the Controllers?

~~~
daigoba66
All of the web stuff (ASP.NET MVC, etc) has the advantage of being open source
(real open source, Apache 2 licensed, and accepts contributions). The team is
also very open with the community and releases frequently. They're also
working with with the OWIN ([http://owin.org/](http://owin.org/)) standards so
that these projects don't have to be tied to Windows/IIS. It all moves very
fast however, which might not necessarily be a good thing for LOB developers.

I can't really speak for WinRT. I've never touched or looked at the developer
tools. And I've not ever really used an app as a user. The only reason I think
it's here to stay, for a little bit anyway, is that it's the _only_ way to
develop software that runs on Windows Phone or Windows RT tablets (other than
Web apps).

------
ZanyProgrammer
WinForms are still an option in VS 2012-how are they not supported? Is this
just an alarmist piece of writing, or are WinForms no longer around in VS
2013?

~~~
Spearchucker
WinForms is still there. I don't understand why the author dismisses WinForms.
I also don't understand why the author feels WinRT is the way forward. Sure,
WinRT confused people about Microsoft's strategy, but saying this is the only
route left is, well, stupid. Especially when you consider the huge industry
investment in legacy tech (WinForms and WPF). There's no way Microsoft will
just abandon support for it.

------
IanDrake
So many problems with this article. For starters, he gives apple way too much
credit. He also nitpicks about RT not being able to run .net apps. So what?
Get a non-RT tablet. Can you run mac programs on any iPad version? No.

~~~
scj
Enterprises need a platform that they can invest thousands, if not millions,
of man-hours in. Explaining to upper management that a very expensive
application will no longer work due to an upgrade that doesn't benefit the
company is a career limiting event. Not to mention why there are some
instances of Windows 98 still running.

Even though it is only implied by the article, Microsoft's business model is
in jeopardy if the most future-proof method of application
development/deployment becomes the web.

The phrase isn't "Nobody has ever been fired buying Apple." Apple is
unapologetically a consumer-oriented company. Which allows them to behave
differently than Microsoft.

~~~
at-fates-hands
>>>> Apple is unapologetically a consumer-oriented company. Which allows them
to behave differently than Microsoft.

This a thousand times.

Microsoft is essentially stuck between servicing the enterprise segment whilst
still trying to behave like Apple. They're trying to build a walled garden and
shim everybody into it - including their enterprise products and customers.

In short, they are in the midst of a HUGE identity crisis.

~~~
SigmundA
The sad part is Apple has a more consistent message even between iOS and
MacOS, that is Cocoa, and they show no sign of abandoning it anytime soon for
a new framework.

------
spo81rty
I don't think it takes 3-4 times longer to do something in a web app versus a
WinForms app. It all depends on what you are doing of course. Simple grids and
data entry type input stuff is simple to do in web apps.

~~~
Iftheshoefits
> Simple grids and data entry type input stuff is simple to do in web apps.

Well, for an appropriately narrow and trivial sense of "simple" I'd agree. I
mean, if all you're talking about is "input number/text into box, press
'Save'" then sure, that's "simple."

I don't think I've ever witnessed a business web app with such trivial
requirements, though. After they've been through the "me, too!" (e.g., for
"visibility", people will insist on the inclusion of feature X, even if it's
not really necessary) and political/gossip/clique infighting grinders most
such apps have ridiculous requirements that blow the complexity way up.

~~~
Silhouette
_Well, for an appropriately narrow and trivial sense of "simple" I'd agree._

I think the biggest lesson we've learned from the rise of web apps is that
most business applications _are_ simple. They come down to some sort of
database, some sort of guided processes for using it, and some sort of
structured user interface for data entry and reporting. These systems are
inherently centralised anyway because of the shared data store that they are
built on, so running the whole thing centrally and using dumb(ish) clients is
a natural fit.

This doesn't mean that all business software is suitable for running as a web
app. If you're creating material rather than merely entering data -- writing a
report, drawing a diagram, anything like that -- web apps are still many years
behind native applications in what they can do. The more significant the
creation, the more this effect takes over: when was the last time you saw a
professional architect or engineer doing their CAD and rendering work in a web
app, or a programmer working on a million lines of code in Google IDE? But it
turns out that a lot of what people do with computers is more about simple
data entry and then information consumption, and you don't need all the
downsides of native applications for that.

In a way, Microsoft and the like decided their own fate, because they made
deployment and maintenance of native applications so onerous. If they'd had a
standardised and robust deployment/upgrade facility for third party software
on Windows years ago, including good support for centralised management by IT
departments in the professional levels of Windows used by organisations, we
might have had a different picture today. If they'd also maintained the focus
they used to have on trying to provide backward compatibility at almost any
cost, and developed new technologies incrementally rather than making big
announcement where you just assumed their new thing would be dead in 3-5
years, I'm pretty sure they'd still be a leading business in the software
industry. But they didn't, so the Web and the iPad came along, and now
Microsoft are just trying to keep up.

~~~
Iftheshoefits
> I think the biggest lession we've learned ....

True, but in that case an Excel or Access "front end" is almost certainly more
than sufficient and where it isn't, whatever built-in system for writing
"front-end forms" for the DB backend would be.

Web applications are certainly overkill for these use cases, and native
applications are even more so. However, few who use these applications are
interested in thinking of their jobs as rote and easily automated, and even
those who recognize and are comfortable with it will likely have managers who
want to increase their visibility.

------
polskibus
Why are winforms no longer an option? Surely, as long as WinAPI exists, there
will be a .NET layer for it.

------
gum_ina_package
I think the author is experiencing and commenting on the challenge of building
business apps for mobile in general - not just Windows/WinRT. WinRT suffers
from the same limitations as iOS and Android when it comes to servicing
business' needs. The good news is that WFP is going to be supported and
improved upon (despite what the author says) until WinRT is a viable
alternative.

In the future I can see a small business owner linking all his computers
together with a master Microsoft account and then buying a POS app that's
downloaded to all of his computers linked under that account. If that can be
done, it'd be a major leap from where we're at right now.

------
pjmlp
Why do developers keep mixing WPF, Silverlight and XAML?!

XAML is what counts in these stacks and it is still there.

~~~
_random_
Because XAML: 1) is a limited subset of WPF; 2) an intentionally chosen
confusing name; 3) can't be used for desktop development (AFAIK) - and that is
what a typical enterprise wants.

~~~
pjmlp
XAML is the layout engine used in Silverlight, WPF and WinRT.

There are only differences in the amount of C# and C++ code in the XAML stack,
and the set of available UI components.

~~~
SigmundA
XAML is not a layout engine, it's a language for instantiating objects. It
does not even have to be used for GUI objects, just look at workflow
foundation or BizTalk transforms.

~~~
pjmlp
XAML is not _only_ a layout engine, yes I know.

We are discussing its place in GUI Frameworks.

~~~
SigmundA
No its simply not an engine, you are wrong. WPF or WPFe (Silverlight) or WinRT
have layout engines, XAML can instantiate objects that call into the
respective layout engines. Those same object can be created with normal code
as well, no XAML at all.

------
programminggeek
Um, there is Adobe AIR which seems like a very reasonable option for building
Line of Business Apps on Windows, Mac, Linux, whatever. I know it's not cool
to like Adobe AIR/Flash but it would certainly get the job done and allow for
easy updates, etc. outside of the Windows Store.

------
memracom
You could always build your apps in IronPython with GTK#.

Or even straight Python with QT. Or Java or Groovy or...

If Microsoft doesn't provide a tool that does what you need, then choose
another tool. There are an awful lot of choices out there and you gain greater
control over your destiny.

~~~
toddan
Yes you could do that but then you would face a bunch of hard problems. Like
support, deployment or where to find all these python/qt programmers.

