the intersection of business and technology

Technology is useless if it does not deliver business value. Either it saves me time and hence money, or it makes me money. It has to be one or the other. Where does front end architecture fit in this picture? As the title points out, its right in the middle.

The front end is a misunderstood piece of any application, it is usually overlooked, underestimated, and belittled. Its fairly common to perceive it as "toying" around, "no/low value", etc. Its also very easy to believe that all the stuff that happens at the backend is the stuff that commands the big bucks. Unless you develop low level software such as compilers, web servers, drivers, etc. here is why you are wrong, and why front end architecture matters.

You can't deliver "customer focused solutions" if you belittle the front end

Successful front end architecture means focusing on what is important for the end user, not you the developer, nor you the SQL ninja, and not even you the business SME.
I don't know how this upside down tradition started, but I might have an idea. Application development usually starts with the back end framework, you know the Springs, and the Djangos, the Struts, and the Zends. None of these deliver any value to the user, they do add value to the delivery team and make them -in a perfect world- deliver better code, faster. So how did this tradition start? (One that focused on starting in an area that couldn't be any farther from the end user) My reasoning is that it started with equating building end user software with constructing a building. The first step of doing that, is to lay the foundation, the stuff that will carry all the weight of the rebar, steel, concrete, pillars, roof, and all the occupants and their equipment. All this stuff is as far away from the occupants of the building as possible, but it is by far more important than whether the doors open in or out. The occupants of a building are first concerned about their safety, a "customer focused solution" in the construction industry is one that is first safe for its occupants. Everything else comes later. However, when we use this analogy to building end-user software, we start out right off the bat focusing on the wrong things. A customer focused solution starts with the end user, what will he be interacting with, and then works backwards to define the solution that is required to support that end user.

You can't slap an interface on it

Okay, you can, but you shouldn't. Can you slap a steering wheel in the backseat of the car? Sure you can. Should you? probably not. Why is the steering wheel in the front? because the end user needs to see the road. Start with the end user and work backwards to the solution. A more accurate statement is actually "slapping a back end on it", or "wiring the back end to the front end". That you can do. Why? Because at that point you know what the user wants, and you know how your front end will achieve it.

Another reason why not to do this, is if you care about your users' experience, you would spend more time thinking through the front end, iterating and making it better. Forget the focus groups. Forget the design committees. Empower qualified, creative, and responsible people to make usability decisions. Have real users developers use your application, and keep your mouth shut. Don't show them how to use it, or what they're doing wrong. Observe, take notes, and make it better. Focus groups could just make you chase your own tail, as what happened with New Coke.

Phasing in features

Good back end frameworks and architecture allow you to phase in functionality as you progress in the project. A good front end architecture needs and should do the same. This means, just like a good back end does, a good front end must utilize a common framework. Today, not much focus is given to the front end. In fact it is assumed it can be completed 100% with a "big bang" approach. We don't use a "big bang" approach with the back end, why do you do it on the front end? Because you tried to slap an interface on it...

Front end components need to be thoughtfully designed, with re-use and phase-in in mind. Don't attempt a one-size-fits-all approach to these components. It might make for less development, but if your focus is "customer focused solutions" then you need to account for different use cases and different user types/roles. Also, just like back end components get re-factored when duplications occur, so must front end components. Why the double standard? because the front end gets belittled.

More data is better data

Yes, your gut can have a lot of say when it comes to the front end. However sometimes the change has no affect on your gut. Does it matter if your links are underlined? or are you just doing it because [insert your favorite reason here, ex. because my dog wags its tail when it sees underlined hyperlinks] Design your front end to be able to gather these usage patterns, because "customer-focused solutions" support their decisions on customers' actions. Don't even ask your customer whether they like A or B better, keep your mouth shut and observe. Do they use your application more? better? quicker? when A is there? or when B is there?

At the intersection of business and technology lies the role of the Front End Architect (FA). This person should be empowered and trusted to make front end architectural decisions based on supporting data that will deliver value to the end user. The FA, is not a business SME, they're not a designer, but they could be. They are a technical person, a developer with the scars to prove it. They work with the business to figure out how to deliver this end-user value. The FA also works with designers to iron out any usability issues that may affect the end-user value and can be fixed via enhancing the look and feel. They also work with the rest of the developers to keep front end components re-usable, and phase in friendly.

Do you have an FA on your project/in your organization?

On selling customer experiences

I was looking at how much of a dent an iPad will put in my wallet when I noticed the mandatory field reminder on Apple.com's shopping cart. Then I came to this realization, Apple isn't a mobile device's company, nor a computer company, its a customer experience company. So much time is spent on just tweaking and perfecting the whole cycle. From the moment you browse their online store or their mortar-and-brick store, to the point you make your purchase, including the point when you receive your product, unwrap it - perhaps even record that joyous moment - and then finally start using it and then officially become a fan boy or girl. This happened to me in 2003/2004 when I purchased my first Mac, a PPC PowerBook G4.

Sorry, I went on a tangent there. Anyway, they are a customer experience company. The developers who built this form did not have to do it the way they did. This sick tooltip reminding you of the mandatory fields could just have been a red asterisk. However, because they are a customer experience company, they didn't do what every average Jack and Jill developer would have. As simple a page it is - a personal info page - it most definitely went through multiple iterations before it reached its current state.

Another example, lets say you don't look like a pirate but have a speech impediment. I'm a nice guy. If you seem like a nice person too, I'm going to do my best to understand you. However, that doesn't apply to your website or application. Don't make your product seem like it has a speech impediment - even if it looks great. Its just going to be awkward.

Learn from Apple guys, they don't have to do their site the way they do, they don't have to finnish their products the way they do, they don't have to meticulously design the packaging inside and out. But they do. And because they do, they're in the business of selling customer experiences. That is a very profitable business, and that is why Apple's stock P/E is twice that of Microsoft's.

Here's a great TED talk on "People don't buy what you do, they buy WHY you do it":