Farewell Windows?

Not quite, and not for a long long time. In my house we run 4x laptops with Windows 10, we have a small office computer running Windows 10; then there is the Music Server in the basement, and the media laptop buried in the TV cabinet, they also run Windows 10. So it will be a long time before we stop using it.

However, in an excellent summary of what’s been going on at Microsoft, Matthias Biehl also makes a number of organizational truisms. It’s well worth a read. Also, do yourself a favor and try the Microsoft To-Do program, I use it on Windows and Android, it’s excellent.

culture flows from success

The End of Windows https://t.co/TtnUwsk1ct

— Matthias Biehl (@mattbiehl) August 30, 2019

 

API’s and Mainframes

I like to try to read as many American Banker tech’ articles as I can. Since I don’t work anymore, I chose not to take out a subscription, so some I can read, others are behind their subscription paywall.

This one caught my eye. as it’s exactly what we did in circa 1998/99 at National Westminster Bank (NatWest) in the UK. The project was part of the rollout of a browser Intranet banking application, as a proof of concept, to be followed by a full blown Internet banking application. Previously both Microsoft and Sun had tackled the project and failed. Microsoft had scalability and reliability problems, and from memory, Sun just pushed too hard to move key components of the system to its servers, which in effect killed their attempt.

The key to any system design and architecture is being clear about what you are trying to achieve, and what the business needs to do. Yes, you need a forward looking API definition, one that can accept new business opportunities, and one that can grow with the business and the market. This is where old mainframe applications often failed.

Back in the 1960’s, applications were written to meet specific, and stringent taks, performance was key. Subsecond response times were almost always the norm’ as there would be hundreds or thousands of staff dependent on them for their jobs. The fact that many of those application has survived to this today, most still on the same mainframe platform is a tribute to their original design.

When looking at exploiting them from the web, if you let “imagineers” run away with what they “might” want, you’ll fail. You have to start with exposing the transaction and database as a set of core services based on the first application that will use them. Define your API structure to allow for growth and further exploitation. That’s what we successfully did for NatWest. The project rolled out on the internal IP network, and a year later, to the public via the Internet.

Of course we didn’t just expose the existing transactions, and yes, firewall, dispatching and other “normal” services as part of an Internet service were provided off platform. However, the core database and transaction monitor we behind a mainframe based webserver, which was “logically” firewalled from the production systems via an MPI that defined the API, and also routed requests.

So I read through the article to try to understand what the issue was that Shamir Karkal, the source for Barbas article, felt was the issue. Starting at the section “Will the legacy systems issue affect the industry’s ability to adopt an open API structure?” which began with a history lesson, I just didn’t find it.

The article wanders between a discussion of the apparent lack of a “service bus” style implementation, and the ability of Amazon to sell AWS and rapidly change the API to meet the needs of it’s users.

The only real technology discussion in the article that I found that had any merit, was where they talked about screen scraping. I guess I can’t argue with that, but surely we must be beyond that now? Do banks really still have applications that are bound by their greenscreen/3270/UI? That seems so 1996.

A much more interesting report is this one on more general Open Bank APIs. Especially since it takes the UK as a model and reflects on how poor US Banking is by comparison. I’ll be posting a summary on my ongoing frustrations with the ACH over on my personal blog sometime in the next few days. The key technology point here is that there is no way to have a realtime bank API, open, mainframe or otherwise, if the ACH system won’t process it. That’s America’s real problem.

IoT App hell of the future

On the day after it was revealed that some models of the Google Home Mini speaker was revealed to be recording voices 24/7 due to a defect, Danny Palmer has a thoughtful piece on ZDNet about the toxic legacy of IoT devices.

Danny is spot-on about the social and technological impact of connected devices past their support date. While I’ve complained in the past about constantly updating apps, both adding function that slows the original device, and removing function that changes, often destroys the original value proposition of the device. It’s perhaps when the devices stop getting updates we have the most to fear from?

I have a Netgear NAS that is out of support, in fact, since I have an identical NAS that wakes-up Tuesdays at 2am and backs-up the primary NAS, I have two of them. While they are out of support, Netgear has been good at fixing urgent vulnerabilities. Of course, since I can’t see the source, I don’t know what vulnerabilities they have not fixed.

Kate and I went to see Blade Runner 2049 on the opening day at the local AMC cinema. It’s a bit of a thing of mine to sit through ALL, and I mean all of the end credits, As we left the theater, there it was, right at the very bottom of the screen, unseen from the seats, the Windows XP Start-button. I have no idea what projector they were using, but yes, many projectors did, and obviously still do run Windows XP.

Woe are apps

As a follow-on to my recent app post, a couple of interesting udates. First up, marketplace.org ran an interesting piece on apps on June 9th. Sabri Ben-Achour covered the Apple iTunes announcement by saying:

• It’s hard for app developers to get noticed(thats a “no shit sherlock” moment)
• It’s hard to make money (thats NSS #2)
• There are 1.6 million apps on the Apple store, the search function isn’t that great
• There have been 75 billion app downloads, but the average user downloads zero apps per month.

Apples answer? Paid promotion within the iTunes store. Of course if apps didn’t exist and companies and developers were using the power of mobile through web, css etc. their sites would be found in context of content and SEO. They could focus their efforts in a single way to promote their content and the web UI to access it.

Also new, to me, I went to use Skype to contact one of my kids in Europe the other day and was surprised, and more than a little disappointed to find the Skype app was no longer working and no longer available. It’s not clear if this was a business decision, or a technology one. The app was the only one I ever used on the Samsung SmartTV that used the camera. Yeah, I know I should have taped over the camera.

That’s the problem with apps, you wait for ages for a platform that makes sense, and then two or more come along at the same time. You better hope you pick the right one. There are some 137 pages on a single thread on the Skype Community forums debating if either Skype or Samsung was the wrong platform.

The app hell of the future

Just over 5-years ago, in April 2011, I wrote this post after having a fairly interesting exchange with my then boss, Michael Dell, and George Conoly, co-founder and CEO of Forrester Research. I’m guessing in the long term, the disagreement, and semi-public dissension shut some doors in front of me.

Fast forward 5-years, and we are getting the equivalent of a do-over as the Internet of Things and “bots” become the next big thing. This arrived in my email the other day:

This year, MobileBeat is diving deep into the new paradigm that’s rocking the mobile world. It’s the big shift away from our love affair with apps to AI, messaging, and bots – and is poised to transform the mobile ecosystem.

Yes, it’s the emperor’s new clothes of software over again. Marketing lead software always does this, over imagines what’s possible, under estimates the issues with building in and then the fast fail product methodology kicks-in. So, bots will be the next bloatware, becoming a security attack front. Too much code, forced-fit into micro-controllers. The ecosystem driven solely by the need to make money. Instead of tiny pieces of firmware that have a single job, wax-on, wax-off, they will become dumping ground for lots of short-term fixes, that never go away.

Meanwhile, the app hell of today continues. My phone apps update all the time, mostly with no noticeable new function; I’m required to register with loads of different “app stores” each one a walled garden with few published rules, no oversight, and little transparency. The only real source of trusted apps is github and the like where you can at least scan the source code.

When these apps update, it doesn’t always go well. See this picture of my Garmin Fenix 3, a classic walled garden, my phone starts to update at 8:10 a.m., and when it’s done, my watch says it’s now 7:11 a.m.

Over on my Samsung Smart TV, I switch it from monitor to Smart TV mode and get this… it never ends. Nothing resolves it accept disconnecting the power supply. It recovered OK but this is hardly a good user experience.

Yeah, I have a lot of smart home stuff,  but little or none of it is immune to the app upgrade death spiral; each app upgrade taking the device nearer to obsolescence because there isn’t enough memory, storage or the processor isn’t fast enough to include the bloated functions marketing thinks it needs.

If the IoT and message bots are really the future, then software engineers need to stand up and be counted. Design small, tight reentrant code. Document the interfaces, publish the source and instead of continuously being pushed to deliver more and more function, push back, software has got to become engineering and not a form of story telling.

The app Internet…

Next big thing, the current tech gold rush, the perfect companion to your mobile device, or something more evil?

Yesterday was the quarterly Dell Executive meeting, hosted by Michael Dell. We got some great internal news and direction, company progress on the companies’ transformation. Michael invited George Conoly, co-counder and CEO of Forrester Research along for a Q&A session with Michael at the end. They effortlessly flew through a number of subjects, it was a great session.

When it came to the open Q&A, I got to ask the first question. which was on the subject of the “App Internet”. Rather than try to rehash the conversation here, I went looking for George’s blog and appropriate commentary to link back to. There is an entry here which doesn’t quite capture George’s cup-runeth-over-enthusiasm for the “App Internet”. What follows is my open reply to George.

It would have been fun to explore this subject further, maybe we can do it online, but lets start with what we agree on:

1. the app Internet provides a rich user experience and good response times for local data and actions
2. Because of this users are “thirsty” for Apps rather than zooming in and out of random, dissimilar webpages, using a brower which doesn’t really integrate with your “platform”. This makes app stores a great way to make money, and provide a key opportunity to “lock-in” the user, if you control the platform, and the download utility, you control both ends and the middle. Think your local cable company, great model, eh? 100% lock-in, your device and apps are just like cable boxes, as soon as you terminate your contract, you risk losing access to your service, your “cable box” and your secret stash of data on the cable DVR.
3. Apps are the current tech’ wild west; the new gold rush; because of the effect of 1. and 2. and the democratization of platform app development, anyone can do them.

While there are some limits in place to control what apps do and validate them before they make it onto the store, after that its open season. Until the mobile platforms implement at least Facebook app Privacy-like controls(*1), no one, except those wanting to make a fast buck should touch them. Google Chrome browser apps have paid some design attention to this, but unless the browser app/extensions is stupidly simple, you’ll end up getting prompted to give access to all data, never anything else. So, before I download any app for my platforms I always think, do I trust the provider, the platform and what is the worst it could do?

The problem is that currently none of the mobile app platforms(except Blackberry which uses a legacy server redirect structure) allow you to intercept marketplace calls; white list apps; block downloads; scan downloads for known problems; block installs; automate post install cleanups, or provide you any real hooks to do any of these things. You are left trusting the marketplace, and at least for Apple, Microsoft, RIM and some of the ereader/ebook type devices, there is ONLY one marketplace, to ensure the validity of their apps.

Once you’ve got the app you have no real idea what data the app is accessing, what it’s keeping, what it’s downloading, more importantly, what its uploading and why.

Now, hopefully there are a fully set of rehearsed comebacks on these points. If not, then beware, make sure you know how what your platform is and how to change when the time comes. Jim Louderback has a good perspective posted in response to Colonys blog.

I’ll write a follow-up on some of the miscoinceptions about HTML5, and mobile apps, which are mostly because people are working with a pure browser, non-platform integrated model when they start their dismissal. I’ll close with this quote from my 1989, Enterprise Workstation Management from Chaos to Order presentation, available on slideshare.net

“A Workstation is a platform where people sit and wonder when the train will finally arrive. After a while they get anxious and start wondering whether they are on the right platform after all”

(*1) Who’d have ever imagined a world where you’d hold up facebooks privacy model as something you’d actually want? Think about it though, wouldn’t it be nice to have a settings/privacy page on your phone that showed you what apps had been run when, what level of access they had, what websites/addresses they’d accessed(*2) and allowed you to selectively block access, block the app or remove or reduce it’s privileges. Great eh?

(*2) Actually facebook doesn’t provide this, but heck at least any server side app should be tracked and optionally logged…