A primary function of IT architecture is managing change. This change happens at varying rates in and between levels of abstraction (think of wind moving at different speeds at different altitudes). So we can think of “horizontal” change — change in time within a particular level — as well as “vertical change” — the relationship between one level and another. A robust IT architecture maximizes the potential for improvements in all levels while minimizing the negative impact of change between levels.
Sometimes IT architecture emerges through acquisition. In the old days, vendors imposed architecture that was bundled with their software development products. (Why would anyone have otherwise considered something like systems application architecture [SAA]?) As many IT shops moved toward packaged software (e.g., SAP), they inherited the architecture expressed in their applications purchases. In doing this, they traded off vertical flexibility for development cost.
When an architecturally dominant application is added to an existing portfolio, some organizations respond by gradually conforming all their other applications to the dominant architecture. This has the purported benefits of “seamless” integration, allowing every application to gain advantages of infrastructure improvements as well as reduced support costs.
While this behavior is understandable, it brings risks that are often unaddressed. In the worst case, the selected vendor fails or is bought by a larger competitor and a complete migration to a new vendor architecture is required. This is fine if the risk is quantified (and perhaps insured against) up front, but it’s not so nice when the forced migration comes as a surprise.
One way to mitigate this risk is to create an architecture that allows the dominant application to coexist with “foreign” applications — SOA is a modern instance of this approach but is subject to the risk described above if a vendor-supported application bus is used for integration.
Embracing a vendor’s architecture implicitly without risk planning is an example of “Potemkin architecture”. (As the story goes, when Catherine II visited Crimea in 1787, her minister Grigori Aleksandrovich Potemkin ordered facades of villages constructed along the banks of the Dnieper River. Some historians suggest that Potemkin did this to increase his standing with the empress by enhancing the perceived value of her new conquests. His techniques have been used subsequently by every real estate promoter with swampland to sell.) As applications vendors become more successful, the justification for internal IT architectural work to a budget-conscious manager becomes that much more difficult. A cynic would argue that this is because the benefits of IT architecture accrue over a period that is well beyond a senior managers tenure.
For custom systems, IT organizations produce products that reflect the tools and design fashion of their time, from host database to client-server to n-tiered to SOA to whatever will inevitably come next. Here, a robust IT architecture allows functional capability to be added without forcing change throughout every level and across every system. Every new design approach promises this benefit but usually in ways that contradict previous approaches. For larger organizations, a more typical situation is a heterogeneous mix of customer applications and vendor software, spread across multiple operating systems and physical locations. The need for IT architecture only gets stronger as this complexity increases. Sometimes sound architectural principles are at odds with the trend toward consolidation and standardization; it is the brave IT architect who argues for IT “genetic diversity” in the face of obvious benefits and less obvious risks of standardization.
Many times, the largest IT organizations will fold under intense external pressure and ignore architecture issues completely. The results are a “software shantytown,” where their crafty leaders erect a Potemkin architecture in front to hide the mess. Potemkin architecture masks risk; it should be considered IT malpractice.