History of the Web Application

In almost every business, we have the same problem; our users, in the intricacies of their varied roles, are forced to swivel chair between many alternating user interfaces. Adaptable as they are, undoubtedly there is fallout leading to:

• slower execution of tasks
• disconnected workflows
• in-congruent decisions (and data!)

The last two decades delivered many attempts to *unite* these quickly growing/splintering businesses. Not to suggest that they haven’t succeeded, as many of these inventive solutions have paved the way for the delightful technology-driven universe we live in today.

Just a little reminder of where we have been…

Desktop Applications

Once the “only way”, our users lived by <ALT><TAB>… while our support staff died in remote support hell. Imagine endless calls coaching users through installs (and then re-installs, when all inevitably goes sideways). Effectively the “blind leading the blind” through the worst of updates, configuration, and troubleshooting. For large organizations, this could mean flying weekend teams to remote offices all around the globe to manage upgrades and new roll-outs.

Wild West of the Web

The dawn of the web application brought a whole new world. Accessible from any device having a browser. No downloading or installing new programs, and often centrally managed without ever touching the end user’s machine. But the limitations in feature, often outweighed benefit.

While html/javascript was still slowly grooving into modern day magic, we started with a page for every function and forms at every corner. It was unlikely that any page performed more than its dedicated task, nor had access to data outside of its given business domain. Data access was complicated, security non-existent, and Apache/CGI was king. Endless bookmarks and intranet homepages filled with links to every operation of the business. At their best, we glued together disconnected views with a word that should be forever forgotten: the iframe.

Portals & Portlets

Web portals and portlet web apps made the first move towards integrating the many domains into a seamless expression of the business. Finally a way to give the user every tool in one view! The new challenge of the developer was to squeeze the whole world into tiny spaces, while the user was left playing “Where’s Waldo” in a sea of information. It was quickly realized that “one size fits all” could never meet the complexity of the business, and spawned unique apps for each individual business organization from Sales, to Technical Support, to Customer Care, and so on.

Now enters the latency of server-side rendering, along with the stability woes in taming the wild beast of dependency… Countless data sources, tightly coupled systems, and synchronizing state between servers - erupts into the Production chaos of hung threads, memory leaks, long-running queries, and indeterminable root causes. How many of these applications survived by monthly (or even nightly) restarts? And clustered deployments could take hours of down time during maintenance.

Service Oriented Architecture

The Enterprise Service Bus introduced a way to quickly build small, interdependent services and deploy them with ease. It abstracted the data sources from the application view, allowing role separation of the UI developer from the Integration developer. Typically a server was stacked with an ever-growing catalog of web services. Each new service could be intertwined with next. Web server, routing, configuration and common utilities live IN the platform, and packaging even “hot deployable” for continuous uptime!

Unfortunately these solutions were yet again plagued with scalability issues, and stability limited to your least capable developer. A single poorly designed SQL (or infinite loop) would take down your entire organization in one shot. Because the platforms were a shared space, the larger they grew… the harder they fell.

Single Page Applications

With the introduction of jquery and ajax, Web 2.0 finally replicates the desktop applications of the past! Rendering can now take place browser-side, giving the perception of lightning speed. Though often complicated to develop without careful thought, cross sectioned state management would quickly boil a full pot of spaghetti code! On the bright side, the decade introduces frameworks like Angular, React, and Vue with design formats encouraging quality state management and maintainable, modular code.

With this advent, the ease of running your application fully in the browser, adding responsive designs to fit any screens, and even manage “offline mode” could keep users active on any device, any time, and anywhere. Finally, all the conveniences of the web, with performance and function of a desktop app!

Micro Services

The promise of web services delivering loosely coupled, reliable resource management might finally prove viable as rigid SOAP definitions shift to RESTful API’s, and SOA swiftly slides into containers. Developers blindly leap into the unknown that MUST be better than where we’d been.

Docker and Kubernetes at the heart of this new methodology bringing isolation, scalability, stability, and operational management to their peaks. As the old idea of a platform fades away, the developer no longer handcuffed to operations in the design of deployments, platforms, or servers. We finally reach the ultimate delivery mantra of code, deploy, repeat!

Workflows & Machine Learning

Too many options leave even the most senior of users bewildered traversing the enterprise of activities. The single page application now *can* seamlessly present everything, but should it? How do we reduce the on-boarding and training of new hires? How do we keep our customer experience consistent and “on rails”? How do we train the user that you have to do A before you can do B, but NOT when C is enabled? Workflows may not be new, but inherently hard to develop as the code paths and permutations grow into the thousands.

After years of growing the data behind all of our many applications, analytics become automated, and workflows can swallow their analytics to become self-decisioning (and self-improving). Additionally we aim to deliver the workflow control directly to the business as it changes faster than technology can design, develop, and deploy.

What’s next?

We have given up on the “one size fits all” mentality and broken up our apps into varying lenses of the business (Sales vs. Support vs. Customer Care). We now have the stability and modularity of micro services. We have maximized performance with browser-side applications. We have introduced business controlled, data-driven workflows to our users, to reduce training and promote consistent experiences. So what’s left? Where do we go now? Back to the future!

Personally, my only remaining concern is the mangled team designs that inevitably follows years of technological maturation. While no business has the exact same faults, I would imagine we have some commonalities. Cross team “overlap in ownership” of the business, or the similar problem of teams becoming “jack of all trades”, both seem to derive from the same cause:

…organizing by technical function, rather than business function…

Think “Architecture” vs. “Business” vs. “UI” vs. “Integration” vs. “Data” vs. “Project” vs. “Operations”. All leading to problems like:

• multi-team dependencies in delivery
• lack of specialized domain knowledge in key areas (UX/Data Modeling/Analytics)
• inconsistent expectations between divisions
• turf wars over solutions

Organizing by function was a necessity in the old world where we required so much specialization in the technology itself. But now that we are code, deploy, repeat…

What if we could truly organize our technology teams by business domain, while collapsing both business and technology into one shape? What if we could define teams as the full stack, comprised not homogeneously, but diversified arrangements of:

• architects
• analysts
• developers (UI/API/Process/Data)
• project managers
• engineers
• operations

All while reconciling dysfunctional agile practices, and creating expertise and specialization? I think you might agree speed to market is an effortless for a development team specialized in their domain, independent from inter-team coordination, and armed with automated delivery. It is the same reason we see small companies turn on a dime, so why not follow their lead?

Widget as a Service (Micro Frontend)

While widgets are not a new concept, and micro frontends have been slow to gain traction, just imagine developing a UI like a micro service:

• modular
• light-weight
• minimal dependencies
• specific in function
• loosely coupled

All of this while interacting within a broader UI context.

I recently developed a widget specifically for payment management using React.js in the browser, Node.js on the server, contained by Docker, managed by Kubernetes, backed by a series of Spring Boot based micro services, and Oracle DB to store our data. The widget itself was delivered as a Web Component (aka custom HTML element). Any of our many web applications could import and insert into their layout with just 2 x lines of html or javascript. The application context delivered through standard HTML attributes parameterized to load in line with the hosting application’s session.

I was determined to deliver complex, reusable payment functionality in 5+ unrelated web applications of varying user bases and experiences, with minimal development by the hosting app developer. And since the HTML was rendered in the hosting application’s own page, the styling was completely inherited, guaranteeing a completely native look and feel. Some applications presented full layouts, others presented workflows, and still others only concerned with the most minimal of use cases. The larger user experience was broken into their smallest divisible parts as micro apps. Using custom browser events, these otherwise independent widgets were fully inter-connected and interacting within a single page.

For more on this topic, see: How to build a Widget as a Service.