Does Traditional Software Architecting Just Slow Down Web Development?

Architecture. Architecting. Architect.

These words conjure up particular imagery to me: blueprints, engineers, buildings and, technology. An architect's job is, alongside engineers, to create a plan or blueprint for building something and make sure it is executed per the plan. Anyone who has done any serious home renovations knows the process. Build per plan, get the inspector's OK , continue building per the plan. An architect and engineer create something stable and static based on that plan. And it makes sense — a building needs to be stable and planned, you can't decide to move a pillar at the last moment. And when that plan isn't followed, the consequences can be disastrous, resulting in demolishing brand new hotels on the Vegas strip.

But software isn't a building, and software can change on a dime if you let it. I believe a software architect, in many cases, is unnecessary and impedes the development process. Application development needs to more nimble, more flexible, more agile. The business stakeholders who pay the bills expect more from the developers within their organization. They need them to move at the speed of business.

Twenty years ago it was more difficult to visualize what the developers were building for you. End users weren't very savvy, it took developers a lot of time, and everything needed to be thought out very carefully. Web design changed that mentality. There was no more compiling large swaths of code to see a result. One tweak and review. No? OK. How about this way?

Cutting-edge organizations moved to agile development, developing in quick sprints or packages, tweaking, and moving forward. Startups started working with the concept of Minimum Viable Product (MVP). Make a simple version of a product first, to see if it makes sense, see if it has traction, if it has momentum. Release early and release often.

I recently worked on an e-commerce project where a very good agency absolutely insisted that we develop wireframes (webpage schematics) and comps (high-fidelity mockups) for every possible situation. Hover over a quickview? We need a comp. Every error message on checkout? We need a comp. In the end, all in, we had over 500 wireframes/comps to build out to cover every nuance of the site. I suggested several times that we only build three: the Homepage, the Gridview and the Product Detail Page. Everything else could be derived from there and we could tweak along the way. Well , this was not in the agency's development philosophy, so we designed the 500 comps. And guess what? When it came time for User Acceptance Testing (UAT), it didn't come close to matching anyway. And we wasted a tremendous amount of time "arranging the deck chairs on the Titanic."

I am a huge Disney/Pixar fan, and Ed Catmull, the head of animation, once said, It is better to correct mistakes rather then try to prevent them." Or put another way, "If everyone is trying to prevent error, it screws things up."

My team lives by those words.

It is so easy to stand up a version 1.0 or prototype in today's world that you should always be doing so. Trying 20 barebones ideas to see where momentum bubbles up will yield much better results than architecting one idea for six months.

Now, of course there are many scenarios where architecture is a must-have and hardware, servers and databases all require a tremendous amount of careful thought.

But when it comes to apps and Web-based tools — things that that don't need to scale to n immediately — agility should reign. And if that app you built for the marketing group grows so quickly that you start to struggle from a database perspective, well, congratulations: you built a really successful product, now go back and tweak it.

John Hazen is vice president of global e-commerce for Fox Head, the actions sports apparel brand.
This ad will auto-close in 10 seconds