200 OK SwatantrAI

Sometimes accepting a constraint or giving up on a property can lead to a better architecture, one that is easier and less expensive to build and run. Like buses, desirable properties tend to come in threes and trying to define and build a system that supports all three can result in system that does nothing especially well.

A famous example is Brewer’s conjecture, also know as Consistency, Availability, and Partitioning (CAP), which states that there are three properties that are commonly desired in a distributed system – consistency, availability, and partition tolerance, and that it is impossible to achieve all three. Trying to have all three is going drastically increase the engineering costs and typically increase complexity without actually achieving the desired effect or business goal. If you data must be available and distributed, achieving consistency becomes increasingly expensive and eventually impossible Likewise if the system must be distributed and consistent, ensuring consistency will lead at first to latency and performance problems and eventually to unavailability as the system cannot be exposed as it tries to reaches agreement.

It’s often the case that one or more properties are considered inviolate – data cannot be duplicated, all writes must be transactional, the system must be 100% available, calls must be asynchronous, there must be no single point of failure, everything must be extensible, and so on. Apart from being naive, treating properties as religious artifacts will stop you thinking about the problem at hand. We start to talk about architectural deviation instead of principled design and we confuse dogmatism with good governance. Instead we should ask, why must these properties hold? What benefit is to had by doing so? When are these properties desirable? How can we break the sustem up to achieve a better result? Be ever the skeptic, because architectural dogma typically tends to undermine delivery. The inevitability of such tradeoffs is one of the most difficult things to accept in software development, not just as architect, but also as developers and stakeholders. But we should cherish them as it’s far better than having limitless choice and accepting tradeoffs often induces a creative and inventive result.

The support and maintenance of an application should never ever be an after-thought. Since over 80% of an application’s life-cycle is spent in maintenance, you should pay a lot of attention to the problems of support and maintenance when you’re designing. Fail to heed this and you’ll watch with horror as your application stops being the architect’s dream and becomes a vile beast that dies a horrible death and is forever remembered as a failure.

When most architects design applications they think mainly of developers, who have IDEs and debuggers in place. If something goes wrong, highly skilled software engineers debug away and the bug is discovered. It’s easy to think this way because most architects have spent most of their lives as developers rather than administrators. Unfortunately, the developer and the support guy have different skill sets, just as the development/testing environment and the production environment has different purposes.

Here are a few of the disadvantages that an administrator faces:

• An administrator can’t resubmit a request message to reproduce the problem. When you’re in production, you can’t re-issue a financial transaction against the “live” database to see what when wrong
• Once the application is in production, the pressure to fix bugs comes from customers and executives, not from the project manager and the testing team. And an angry CEO can be a lot more threatening.
• Once you’re in production, there is no debugger.
• Once you’re in production, deployment needs to be scheduled and co-ordinated. You can’t take a production application down for a few minutes to test a bug fix.
• The logging level is much higher in the development environment than in production

A few symptoms of this failure to plan for support are:

• most problems require a developer’s involvement
• the relationship between the development team and the support team is sour; the developers think the support team is a bunch of idiots
• the support team hates the new application
• the architect and development teams are spending a lot of time in production
• the application is restarted often as a way to resolve problems
• the administrators never have time to tune the system properly because they’re always fighting fires

To ensure that your application succeeds once it’s out of the developers’ hands, you should:

• understand that development and support require a different skill set
• get a support lead as early in on the project as possible
• make the support lead a core part of the team
• get a support lead to be involved with the planning for the application support

Design such that the learning curve for the support personnel is minimal. Traceability, auditing and logging are crucial. When the administrators are happy, everybody is happy ( espescially your boss)