Fire Proofing Architectures

April 14, 2010

Architecture fire proofing is making the right decisions when establishing the fundamental controlling principles of a technology solution. A successful  architecture will be cost effective, easy for available developers to work with, will scale well to defined future need, provide sufficient performance and be secure. A bad architecture can be very clever, use all the big name technologies, cost a fortune and fail in every practical way.

General Fire Proofing

There is no magic solution, no technology panacea, no standard that will guarantee success in the terms defined above.

Understand the Problem

Involve Senior/Client Friendly Architects early and get them in front of the client.

Architects need to understand the business problem they’re trying to solve in some considerable detail. If the architecture team prefer each other’s company to that of the business, that is a significant red flag. If an architect’s appreciation of the challenge is too shallow, the resulting architecture may work fine for some requirements but become unwieldy in more complex situations. This may lead to longer development times and higher maintenance costs.

Give architects a clear scope of functionality for this and future projects.

The architecture team also need to understand the business context of the project. A common failing is to try to build in too much flexibility to cope with requirements that nobody can say for sure will be needed. It’s the classic problem of trying to build a car that can transform into a kitchen sink at the press of a button (read 1 million lines of config).

Deal with Not Invented Here– Don’t Build Frameworks

Assemble powerful existing frameworks.

Completed applications deliver value. Building frameworks created potential value or potential cost / time save. In practice, realising those benefits is difficult.

Some developers love building frameworks. It’s a pure process that can perhaps be done in relative isolation without need to understand vast swathes of client requirements. Or spend time getting into the mucky reality of the business.

There are now a wide range of high quality frameworks that if adopted allow developers to spend much more time focused on client requirements.

No one framework is perfect for all occasions, but developers can now spend more time assembling and less time building.

Be Introspective

Have a realistic view of how your internal systems can be combined to synthesise new functionality.

Don’t assume systems will easily integrate.

Untested assumptions about the capability and ease of integration of systems can lead to massive problems down the line. It’s too easy to draw two system boxes on a piece of paper and link them. That simple line could turn out to be a huge can of worms.

Don’t Architect for Super Hero Developers– Unless you have them

Architectures need to be understandable and usable by the target development team.

A perfectly technically correct architecture is of little use if the development team can’t implement or use it (properly). This situation can come about for various reasons, but a common cause is architecture ivory towers where Architects can conceive something that is way beyond what the company’s mainstream development teams are skilled to use. It’s an impedance mismatch. Either get the architects to work at a lower level, get different architects who will, get the developers to step up or get different developers. None of these are easy choices.

Technology Standards are a Double Edged Sword

The company standard may not be the best option for certain types of problems. Be prepared to make a case for why something else is better.

For application development, the choice of stack is no longer as simple as Java or Microsoft. The emergence of technologies like Groovy, Python, Clojure, Scala (to name a few) offer significant, robust alternatives that may solve certain types of problems with far greater aplomb.

Get Specialists Where Needed

Get people who really know your technology of choice, not people who’ve just converted.

Modern, popular procedural languages have many similarities. It should not be difficult for an experienced C# developer to cross train to Java. However, fluency and elegance in use of libraries can take a great deal longer to acquire. Be aware of that in planning and consider injecting expert resource.

When Trying to Break Records, Get Test Pilots

Know when you’re stretching the limits of the technology and get people who know how to fly it to and beyond its limits.

If you’re going to do something that’s outside the normal operating envelope of a technology, you may need high end skills to get it set-up, before handing back.

Don’t Use Technology Because it’s Cool

Just because it’s new and being hyped up by big names does not mean you should use it.

Some architects and developers will be attracted to the new because it’s exciting and shows promise of solving hard problems easily and with greater style. In some cases, the risk of taking the new technology may be worth it because solving the problem in a more traditional way may be massively more labour intensive. However, some technologies can tend to be over-sold and disappoint.

Be prepared to scientifically pilot technologies to know if they’ll do what they claim or come with a lot of limitations.

Recognizing a Failing Architecture

Does everything seem to take forever?

How much work does it take to implement a ‘simple’ piece of functionality? If vast amounts of ‘plumbing’ have to be written for every small piece of business logic, the architecture (or choice of technology, or the developers) may not be sufficiently well oriented to the problem.

Inadequate performance can mean a death sentence for an application. Study performance and see if the application is giving good response times under real world user volumes. Pervasive bad performance can have many causes but it can be a pointer to either a bad implementation (in places at least) or a correct implementation of an architecture that will be difficult to make perform.


Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: