SOFEA (Service-Oriented Front-End Architecture)

The what of SOFEA
Instead of server-side programs, the JavaScript simply calls a web service, gets an answer, and populates the website itself. This transfers the building of the web onto the web browser, reducing server load. It entirely separates the front end from the back, allowing them to be tested and built separately.

Implementing a SOFEA project forces the company to apply web services for every client action -- from login to search to product details -- that can pull data back. Although the most common implementations are REST and JSON, the form of service doesn’t really matter. What doesmatter is that when you are done, you’ve got an entire set of reusable components you can call from anywhere -- like the iPhone app you have to write next month, the Windows 8 app you’ve got create after that, or the app you might need to put together on the platform that hasn’t yet been invented.

Once the services are in place, writing the new app is a re-skinning process, not a rewriting process.

SOFEA has separate download, presentation, and data interchange, unlike other formats that combine HTML and data.

This model breaks apart download, presentation, and data interchange, moves presentation flow and state to the client, and supports the familiar Model View Controller Framework. In other words, it separates responsibilities. That allows work to happen in parallel.

One person (or team) can work on the services, another on the front-end, and we can reduce both time to market and debugging. This is exactly what was happening at Joe's company, with two different teams doing the work through clearly-defined service contracts.

Pros and cons
All this brings me back to figuring out what was broken: the JavaScript on the client or the back-end service data. To determine that, I became very familiar with Chrome, IE, and Firefox's Dev Tools, and how to monitor the traffic flow and examine the payload that actually came back from service requests. It takes a few minutes of extra debugging for every problem, so I guess the cost depends on how good your programmers are.

To implement SOFEA, you'll probably need a rewrite, or you'll have to convince someone to use the architecture for a brand-new, from-scratch project -- which, of course, carries other kinds of risks.

Will SOFEA be the standard architecture for all tomorrow’s projects? Probably not. One thing I can tell, however, is that whatever the architecture of tomorrow will be, it won’t be the architecture of yesterday. And SOFEA does let you cut off the head of the user interface and substitute something else: