How Well Does Your Architecture Accommodate Change?

Designing and maintaining a flexible architecture is the grail of the IT, application development and business triumvirate in a company. A flexible architecture allows:

• Rapid addition of new, and extending existing application features.
• Enhancing applications by including data from internal and external sources.
• Exposing application data to a wider variety of devices and audiences.

With this flexibility, the business can pursue opportunities with minimal impact to baseline infrastructure.

The sad part: many architectures evolve (or mutate) over time, adding new, function-enhancing components to existing components as afterthoughts. In short, this is not an ideal scenario. The company may have achieved short-term business goals, but in an inflexible (and risk-ridden) way.

Without a flexible architecture, we see more than technical challenges: we see friction in company units:

• IT and development can be seen as blockers, while the business is viewed as making unreasonable demands.
• Time-to-market, and therefore, potential competitive advantage is lost.
• Development cycles can be disrupted, adding significant expense to projects and products .

How do flexibility constraints manifest in the enterprise?

• Physical and IT: not enough servers and / or not enough time / resources to deploy them.
• Development of new features takes too long to code, or application / IT infrastructure won’t support enablement without changes to underlying components.
• Access to internal and external data is restricted by policy, especially if business requirements require enhanced security levels in light of the modern online world.

If poorly-supported changes are implemented, success can become company’s worst enemy. Launching a product or feature atop an architecture that isn’t ready creates a new set of issues:

• End user impact: users have a less-than-positive experience with your product.
• Competitive risk: your great and game-changing ideas are exposed to the world before your application is ready for prime time.
• Unanticipated downtime / impact on other systems: ‘bolt-on’ additions to an existing architecture can pose risks to the original components.

Avoiding issues and achieving success requires planning, execution and resources. The first two are wholly depending on an organization’s ability to complete IT and development projects. The last item is a hardware and resource issue that extending components into a solution that includes cloud computing (even if only on an interim basis) can help manage. Identifying your business goals and performing an inventory on your current state is an excellent place to start; a skilled architect can help you describe the future state and a migration path to your grail.