Matthew Oskowis

Architecture is like any aggressive business strategy and in that, if it was easy:

1. We’d already be doing it
2. Our competitors would already be doing it

Architecture translates the business strategy into a technical strategy, and then realizes the implementation. This is what makes architecture challenging.

Some examples of why architecture is hard:

Reuse across a product family: Many organizations are adopting a business strategy of leveraging commonality across products to enhance productivity, thereby decreasing time-to-market and increasing responsiveness to customers. Everyone’s done the “clone-and-go” approach (taking one product’s code base and modifying it to fit new customer base), and found that it quickly deteriorates into a nightmare of schedules slips and quality.

Now, the business strategy is translated into a product family (a.k.a. product line) architecture strategy, which is implemented as infrastructure and common components to be reused by the product family, and unique installations of products. Here, architecture is not simply the high-level decomposition of an application. The complexity goes way up, due to the widened scope of the problem:

• The technical complexity is compounded by having to accommodate the commonality across the products as well as the uniqueness in each product.
• The organizational complexity is compounded because there are greater dependencies across the organization for requirements input and prioritization, and a more diverse set of schedule-driven product developers who can derail the architecture by ignoring it, challenging it, not following it through lack of understanding, etc.

Improving Consistency and Integration Across Applications: Similarly, this objective introduces greater dependencies, for now the application groups are dependent on the architecture team and their schedules. There is also likely to be strong resistance to the loss of independence.

No related posts.