Some enterprises are considering or have already taken bold initiatives to better manage their architectural debt. Architectural debt is a colorful metaphor for describing when a product, process, application, or system evolves well past the capability covered by the original architectural design.[1]
Over the past few decades, these enterprises have successfully implemented an Enterprise Architecture (EA) using various frameworks, for example, The Zachman Framework or The Open Group Architecture Framework (TOGAF). Now that Business Architectural (BA) approaches and methods are maturing, these same enterprises are expanding their EA initiatives to formally include the Business Architecture. And then other enterprises primarily focus on implementing one initiative after another without the benefit of architectural assets; a corporate behavior that may still be prevalent today. Perhaps these well intended actions are justified since it is perceived as bringing initiatives to completion more quickly and implementing them sooner, rather than exploiting and enhancing the architectural assets of the enterprise. However, the consequence of this behavior increases the architectural debt incurred by the enterprise. Sadly, at some future point in time, the enterprise will have to “pay the price” for that architectural debt through extensive redesign efforts costing enormous amounts of money.
For a moment, consider the Leaning Tower of Piza, a delightfully famous tourist attraction located in Piza, Italy, that started construction about a thousand years ago. After the first three floors were built, the structure started to lean. After waiting around a hundred years and assuming that the structure had settled, construction was then restarted.
However, the next floors were “built in an altered angle to the previous levels”[2] so as to obscure the appearance of leaning from the first three floors. And then, the tower began to lean more and more, finally requiring a major restoration effort that took several years and was completed in 2001. Paying down the architectural debt on the Leaning Tower of Piza was very expensive and time consuming. The foundation of the structure was flawed, built on unstable ground. However, instead of solving the problem of integrating the structure with a more solid foundation, the builders decided to obscure the flaw by designing and constructing one side of the upper floors higher. In the context of an enterprise, does this behavior sound familiar?
In reality today, some enterprises are increasing their architectural debt, continuing to duplicate data in existing information repositories, for example. In other situations, many enterprises use the business function/process model or some other functionally oriented model as some sort of pseudo Business Architecture. However, 21st Century enterprises have evolved well beyond the design limits imposed by a functional paradigm; they require a customer centric model organized around value streams. And also realize that the functionally oriented models more closely resemble a “corporate warehouse of processes” rather than a true architecture. Here again, perhaps this corporate warehouse mindset coupled with the focus on “implementing” inadvertently leads to the unintentional creation of duplicate or redundant processes in the corporate inventory. And the duplication does not stop here; consider some of the technology and hardware options, not to mention cloud computing choices. With this “implementation imperative” is it any wonder that the enterprise has duplicate or multiple information repositories, business processes, applications and technologies that wastefully consume enormous amounts of time, energy and resources to integrate and maintain?
One of the byproducts of a functional mindset is architectural debt and it appears to grow and grow! Just how much goes into discovering and building interfaces between the old and the new business processes and supporting systems because the architectures are so unstable, incompatible or unknown? It must be immeasurable! Funny thing though, these costs, time and resources are not clearly documented, but hidden or obscured from view, and represent a significant architectural debt. And of course, there are unintended consequences in this course or action! This architectural debt is neither fixed nor bounded, but when a quickly implemented solution evolves well past the capacity of its limited design, the architectural debt increases even more. To coin another colorful and often used expression, “the enterprise is just kicking the can down the road!”
Consider the example of a retailer that sold their products through their “brick and mortar” stores and also through a periodically produced brochure and catalog. When they finally made the decision to open up another sales channel through the Internet, they focused the initiative on “building it so they (the customers) would come.” The ultimate result was the triplication of the product repository containing the prices sold through each channel – in the stores, through the catalog and over the Web. Needless to say, maintaining the pricing information in three different product repositories required considerable upkeep, and increased the architectural debt! But this additional cost was never reflected in any future initiatives dealing with enhancements to the three sales channels; it was just another ever increasing maintenance expense. And finally, when the three product repositories were consolidated, these costs were not associated with the resources previously expended in the catalog and Internet sales channel initiatives. How convenient!
Building, implementing and maintaining a customer centric Business Architecture is very demanding. However, it does not conflict with the “implementation imperative” just discussed, but it does bring additional factors into consideration and presents a more comprehensive approach for developing each strategic initiative’s business case and understanding its true costs. It requires exemplary corporate leadership, collaboration between all enterprise organizations, and visionary designers. It is not a project type initiative with an estimated start/stop date and fixed budget, but a new corporate behavior and way of life. It is a hard sell, since it will expose some costs and expenses that were hidden from view in previous strategic initiatives. So, will you take the lead in this endeavor and will you begin paying down the architectural debt of your enterprise? I believe you can!
References:
- Electroiq: Solid State Technology
- Benchmark Projects: The Tower of Pisa What We Learned.
