Windows and Line of Business Applications: No Good Options
infoq.com
infoq.com
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.
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.
1. Why not Web? 2. Why not NoSQL? 3. Why Microsoft?
Large teams drive make typed languages attractive and C# does it without leaving behind a lot of the functional (like) and dynamic (like) features.
C# and Office are the reasons there is still a microsoft, but those are pretty decent reasons.
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.
I find it odd that the "Unix stack" isn't considered a horse in this race.
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.
Now everybody is doing html5. There are even good tools for LoB(like alpha five) on html5 , so lightswitch has little advantage.
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.
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?
I think you're making an implicit assumption that a LoB application must be built with a single technology.
The recent fast pace of technology development has demonstrated that specifics come and go, but foundations can remain stable for much longer. Data portability matters more than code portability. Open formats matter more than open source. Communication protocols matter more than whatever is on either end of them.
If I were trying to implement a major LoB application with reasonable longevity today, I'd go back to basics and plan the software architecture with that goal in mind. Ideas like modular design and separating interface from implementation might not be trendy in a world of web frameworks and "living standards" and processes that are described as "Agile" but really just mean not bothering to plan anything properly. However, those basic principles are as valuable today as they ever were.
There is no reason an LoB application using a SQL-based data store running on Linux servers and accessible using tried and tested mechanisms like sockets shouldn't easily remain viable for decades. Probably the most you'll ever have to do is upgrade some front-end technologies to keep up with whatever devices and software platforms your people use to access the system, but that's easy.
The problem with a lot of these legacy intranet applications that have relied on successive generations of proprietary browser plug-ins isn't the dependence on the plug-ins themselves, it is that they didn't really have that kind of clean separation of responsibilities. Business logic was coded up in the front-end, so when the plug-in became obsolete, a core part of the application's logic was left in limbo. Communication was done by sending custom formats over home-grown protocols, so when new technologies came along, all of these formats and protocols had to be reimplemented from scratch and often without a proper spec.
It's not like it's ever been a secret that these tactics were likely to cause maintenance problems sooner or later. The people who planned ahead still have in-house applications that work just fine. Hopefully the people who didn't will at least learn from their mistakes and know better next time.
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?
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).
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.
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.
Luckily, if you compare the life of the article to what would work reliably on the web, we're talking an order of magnitude difference.
I just checked : a win3.1 .exe runs fine on my win8 test VM, and displays exactly as intended (well, a bit smaller than intended I guess due to the ridiculous resolution of my screen, oh well). A webapp made just 3 years ago doesn't display correctly on anything more recent than IE7.
Seems like windows tech is still by far the safer bet.
But it still couldn't compare with the simplicity of the web. It could have been because I was trying to write a WPF app that acted like the web app. WPF can be nice, and it's definitely nicer than winforms, but web apps are so incredibly simple that I really don't see an advantage. Especially when you consider deployment issues (WPF you need to keep deployments synchronized etc. Web app => single deployment and done).
But still, there was a lot to like in the simplicity of OOP Widgets.
I jumped into web development with both feets back in 2000, nowadays I jump of joy every time we get to do a native application.
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.
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.
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.
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.
XAML is what counts in these stacks and it is still there.
There are only differences in the amount of C# and C++ code in the XAML stack, and the set of available UI components.
We are discussing its place in GUI Frameworks.
Saying "XAML is what counts" is like saying "XIB is what counts" in the Apple world.
However, it does share quite a lot across all frameworks where it is used.
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.