Redesigning a corporate web environment

The Challenge

I’ve got this friend who is responsible for a corporate front-end web environment with almost a dozen browser-facing web applications. Pretty much all he can do at the moment is change static content in the antiquated and wildly inappropriate CMS. Changing anything significant requires implementation of an expensive one-off SDLC waterfall-type project with a business case, requirements-gathering, PM, BA, dedicated test-resource – the whole box and dice. These projects often under-deliver, with scope being reduced en route to avoid budget and deadline blowout.

He’s not happy with the way things are.

He’s got it into his head that it would be far better to create an easily-manageable front-end, with a unified, standardised UI under the control of his front-end web team. Key aspects are simplicity, speed, cost-efficiency, and trust – none of which can be used to describe the current state of affairs.

Some ideas

I was talking to my friend, and he said that at a high level, he’d like to abstract the various applications from the UI, where possible, by means of API/Web Services/etc. On the front-end would be a web application framework – He’s thinking Symfony or similar. He believes he has sufficient developer resource on his team to build/maintain/support this.

Some other ideas he’s been tossing around, in no particular order:

  • Source repository. (He doesn’t have one at the moment). svn or git? Stable trunk policy?
  • Continuous integration. (thanks Mike!)
  • Test-driven development.
  • Automated processes.
  • Security.
  • Content management.
  • Performance. Code-efficiency, caching, etc. (Although he’s heard it said that performance shouldn’t become an issue until performance becomes an issue)
  • The database. Does CouchDB lend itself to supporting a content-driven web application?
  • Will it blend scale?

More ideas…

… are welcome. He needs all the help he can get. While it’s all very bluesky (with pie) at the moment, he needs to turn it into a watertight, bulletproof, business case. And soon.

This entry was posted in Commentary, Design, User Interface. Bookmark the permalink.

5 Responses to Redesigning a corporate web environment

  1. Glen Barnes says:

    Git all the way – It just seems to make sense more than SVN. Also GitHub is a great place to store your repositories if corporate IT is being a little slow in getting things set up for you.

    Also look at automated deployment. Deployment shouldn’t be a manual process – It should be a single command for most deployments. You may have DB chanegs, etc. that may require extra steps but most deployments should check out of a Git branch and run any pre and post deployment scripts (I use Capistrano but there are others). If you automate this step you should be able to push changes several times a day if needed.

  2. microsite says:

    Hi

    There is a really good open source tool called ‘Word Press’

    It’s mostly used as a blogging platform, but it can be used as a full blown CMS

    Good luck to your friend.

  3. Rob Coup says:

    +1 around continuous integration and automating testing and deployment. As your software moves from a monolithic beast into separate distributed components (eg. web services, frontends, CMS, …) its almost essential to have tools to manage all this.

    Capistrano is a simple deployment tool (and totally works without rails) and cruisecontrol.rb is pretty simple for continuous builds/testing.

    CouchDB is awesome for some applications, but I wouldn’t use it just for it’s own sake. You’ll know when your DB schema becomes a nightmare that the time could be right :)

    Feel free to get in touch if he wants help with web services or operations-related stuff.

  4. Harry Fuecks says:

    To me the most telling part is here;

    > Changing anything significant requires implementation of an expensive one-off SDLC waterfall-type project with a business case, requirements-gathering, PM, BA, dedicated test-resource – the whole box and dice. These projects often under-deliver, with scope being reduced en route to avoid budget and deadline blowout.

    …followed by…

    > Source repository. (He doesn’t have one at the moment). svn or git? Stable trunk policy?

    IMO geeks often tend to see things in terms of implementation detail and all the great things that are possible with technology choices, ignoring facts staring them in the face.

    In a corporate culture that doesn’t even get the point of having version control, there’s absolutely no chance of pulling off a project as ambitious as this from the inside. Trying will just lead to frustration and bitterness for your friend – better put that energy into further education, like a part-time Masters or similar.

    Only way I could see a project like that having any chance of succeeding would be externally, with some small, specialised agency packing clever project managers.

    But may be that’s just me ;)

  5. Lance says:

    I agree with Harry – the technology is the easy bit, and the corporate culture is the much harder piece for your friend to crack.

    My advice to him would be to start small, and get one sweet website or application launched and quickly. You may need to get a small external shop to help you, or carve out a small team within your team. Don’t tell anyone you are doing it – but just get it done and present the result when all you need to do is hit the deploy button. Then do the next one.

    Find someone in marketing that you trust, get stealthy support from other parts of the organisation – the twitterers, key operations folk and a heavy hitter or two to provide air cover. Build a groundswell of support for a series of new sites – but most of all make sure he continues to deploy new stuff regularly. Your friend’s customers are no doubt wildly frustrated with his company’s antiquated crap of a website, and they can’t wait to see any sort of change.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>