Architectural Components to Plan For From Day 1

Businesses rely in part, on technology, to differentiate themselves. There is no cookie cutter solution that allows a business an exclusive chance to be better and faster at serving customers. Simple solutions are already used by everyone, so there is no edge to be had. As a result of this market force, custom software is constantly being asked to bridge the gap.

Custom projects are often started from scratch and serve a unique purpose. Within that project, a tension exists between building the prefect thing, and launching on time within budget. The hidden part is, architectural factors that align with business needs should not be cut for the sake of the schedule. If these corners are cut, what you have is a time bomb. That might not be a problem, but a core tenant of mine is communication. Getting these ideas out there from the start is key to expectations management.

Striking the balance between architecture and delivery is a real art form.

So, how can the success of such a project be helped over the next 1-2 years and beyond? Getting this right involves understanding the business, understanding the customer, and understanding the technology that will bridge the two.

1) Understanding the Business:

Get the team together and discuss the business model the software addresses.

  • Where is it going in 1-2 years?
  • What features are wanted in 2-3 months, in 1-2 years?
  • How could the plan change?
  • What are the primary deliverables (must have), vs the secondary deliverables (nice to have).


2) Understanding the Customer or User:

It really bothers me that so many software professionals ignore or even despise the customer. Having empathy for the customer is a number one priority when it comes to ease of use, and thus success of a project.

  • What does the customer care about?
  • In what ways can the process, or user interface be simplified?
  • How important is the look and feel of the software? If this is very important, make sure a designer is part of the project.

3) Understanding the Technology that Bridges the two:

The following is a list of concepts to consider before writing code. It is MUCH smarter to delay the first launch by a few days and include architectural foundations, rather than try to compensate for them later across 500 places in the code.

  • Platform and framework:
    • This will determine many of the initial constraints, like what kind of servers your system runs on (linux vs windows), how well the system will scale, what kind of skills will be needed in the future, and what kind of technical challenges to expect.
  • What environments or clients are involved for now, and possibly in the future?
    • Desktops
    • Mobile phones / tablets
    • Offline mode?
    • 3d goggles?
  • Internationalization
    • Are your users in different timezones?
      • Recommendation: set the server to UTC, store all times in UTC. Even if you think you don’t need it, UTC makes a lot of sense in cloud hosted environments.
      • Let each user set their timezone preferences and display the local time by converting from UTC.
    • Does the system need to support multiple languages now or someday in the future? For example, does the application need to accept special characters like ö, or Japanese characters? Does the login page need to work in English and in Chinese?
  • Transactions:
    • What if data gets lost, how big of a deal is that?
    • Transactionality is expensive to implement after the fact. Some platforms do not support it, especially open source, so be careful there.
  • Durability:
    • How should the system react when something goes wrong?
      • Your users might tell you the site is having a problem – if you are lucky. When a site is down for me, normally I leave and never come back.
      • Fault tolerance needs to be anticipated for.
      • Geeks will want to adds lots of dependencies, but they don’t usually think in terms of what happens when one of those dependencies is not working. You want to design the system so that if one dependency is not available, the system continues to operate normally from the customer’s perspective.
  • Recording of Events and Historical Data:
    • Setup a way of logging the key events in the system so you can reconstruct what happened.
    • Use try/catch blocks to trap for conditions, log, and compensate accordingly. These can even be done in languages like PHP and JavaScript!
    • It could be advantageous to setup a full change history for certain types of records.
  • Re-usability model:
    • SOA – Service Oriented Architecture is worth looking at, especially if many different types of users connect to and consume the application.
    • API – Application Programming Interface, very handy to build in if integration with 3rd party systems is expected.


Closing Thoughts:

Your team needs an architect level person who understands these three issues. Developers will have to be told to build these items in, since they won’t have the same grasp of the big picture.

When it comes to getting it all done, breaking up the work into releases plays a major role in striking the balance between good enough and perfect. Focusing on the near term deadline avoids the temptation to gold plate the code.


This entry was posted in For New Developers, Work and tagged , . Bookmark the permalink.

Comments are closed.