Wednesday, March 9, 2011

Taxing and Permitting - Architectural Levers

As architects, what levers can we pull to align potentially risky technology decisions with timely technology delivery?

Architects are on the hook for planning the portfolio of technologies that our businesses and customers will use to perform their activities.  To be successful and to remain competitive, our customers must be able to rely on technology that is aligned with business needs and leverage said technologies in a timely, flexible, and cost effective fashion.  And they (our customers) cannot afford to spend time understanding the technologies or how they are implemented.

Often competing with timeliness and flexibility is the need to develop sustainable and extensible architectures.  In fact, if done correctly, these architectures will result in the ability for our technologists to be more timely and flexible.  A mature architecture simplifies (at least helps) the process of IT service delivery and technology adoption and implementation.  It is the immature architecture or architecture in development or transformation (larval stages) that can actually hinder progress and delivery.

There are times when the business just cannot wait to have IT do it right; instead, they just need us to do it right-now.  It is at these times that architects and architecture are discounted the most.  It is also here that we routinely introduce technical debt.  Sooner or later, we (IT, IS, pick one) do something right-now that leads to an unsustainable platform that can no longer be incrementally extended.  At that point we have tech-sand.  At a minimum, we now have to replace, rewire, or rewrite major components or subsystems to continue to meet our customers' needs.  Our customers may also have to exercise their own process workarounds until we can remedy the situation.

I submit that as long as IT does not control the business' decisions this cycle is inevitable.  We all have legacy systems and code-bases that are not as flexible as we would like them to be.  How did they get that way?  Was it a conscious decision that led to this situation?  Was it a series of uninformed decisions that led to disconnected results?  Did we plan for how we would get out of this technical debt?  Regardless of architecture maturity (or immaturity as the case may be) organizations should plan for how they will overcome bad architecture decisions and potentially self-destructive behavior.  The approach that I like is Taxing and Permitting.

If businesses are going to make decisions that disregard sound and established architectural guidelines, then we should also plan for how we will fix the unsoundness that we introduce.  Yes, there should be a architecture tax.  I heard about this concept in a webinar given by Data Blueprint's Peter Aiken.  This was a great session on the importance of Data and Information Architecture.  Data Blueprint (and Peter) have several webinars scheduled for the coming weeks.

This architecture tax would be part of the building permit process that I spoke of in September 2010.  New projects that require IT services should go through architecture reviews.  During these reviews, potential solutions would present architecture building permits to the architecture committee.  To facilitate this process, presenters would follow guidelines for completing building permits.  Depending on the size and complexity of the needed IT solution, the building permit process would have different levels of required business approval and architecture scrutiny.  The building permit process would also prescribe technologies and methodologies that should be used for solution types.  In this way, architecture would simplify the process by reducing the potentially bad choices that technologists could make, while providing a directed approach to architecture approval.

At the end of the day, IT architects are charged with many tasks, but these two seem most important to the scope of this problem:
1.  Make it simpler for IT to deliver faster
2.  Keep the supply of junk in our solutions to a minimum

If the business wants to override architecture guidelines, they should be made to relinquish a portion of the cash flows that they plan to reap as part of the project that led to this decision.  Considering that the majority of most IT budgets are used for maintenance and support, this architecture tax could be used to offset the technical debt incurred by a bad technical decision.  The building permit process would prescribe the tax needed to gain architectural approval for a known substandard solution.  This tax could be realized in a weighted risk or technical debt increase to the cost of capital or hurdle rate that the project must ultimately satisfy to be approved.  Just as some organizations ratchet up their costs for capital based on risk and project type, these hurdles could also be increased based on estimated cost of technical debt remediation.  At this point, architectural approval becomes a gate that the project must make it through to survive.  During the phase gate process, the technical debt and tax get documented as part of the architecture review process.

Of course the entire organization must agree to this type of cash flow weighting, and financial departments would have to understand how to account for and accrue these "taxes" so that they can be used at the discretion of IT to support such poorly designed solutions.  At the end of the day, IT must prepare their slice of the business budget to be able to accommodate potential rework introduced by business decisions that opposed architectural effectiveness and contributed to technical debt and even tech-sand.

No comments:

Post a Comment