waste please (Photo credit: blakley)

Let’s face it: IT architects produce a lot of what I would call “architectural waste”. Too often, the focus is on architecture deliverables. We deliver them, and then we start working on the next deliverable.

Unfortunately, architecture deliverables that remain “unconsumed” are not generating value: yes, it’s architectural waste! Think of the IT Value chain: what we produce should be consumed by the next step in the value chain to ultimately generate value to the firm. Another useful metaphor is that of intangible assets in a balance sheet: an architectural asset is such only if has a value and can be turned into cash! If the cost of acquiring the asset is greater than the actual value, you will need to write off at some point in the future.

A roadmap that remains on a powerpoint slide, a solution architecture ignored by the project delivery team, a too abstract corporate data model, an unrealistic target application architecture, a forgotten architecture vision: these are all examples of architectural waste. To avoid this, we need to make sure that they are considered as assets and therefore consumed by the next step in the value chains, and eventually become value delivered to the firm.

We should stop thinking in terms of architecture deliverables, and start thinking in terms of architecture consumables. Here are a few tips on how to do that:

1. Make it clear what type of work products you are planning to produce; there is only a few possible of types: 1) a strategy or position paper; 2) a plan or roadmap; 3) a (current or target) model; 4) a gap analysis; 5) a technology evaluation paper; 6) a policy or standard; 7) a service definition; 8) a service or application. Granted: this is not a complete list, but you get the idea…. A good architecture practice will produce a healthy mix of those consumables.
2. Make it clear how your consumable fits in the overall IT value chain. In other words, be explicit on who your consumer/customer is (within IT or business). Simple rule: no customer, no value!
3. Think and communicate what the purpose of the work product is; why will be be useful to those consuming it, in other words, what’s the value proposition.
4. Be explicit on the planned completion date. Be realistic and explicit (too many architectural efforts go on, and on, and on…)
5. Communicate the dependencies (in other words describe what’s the previous step in the value chain), but expect to be challenged.  There will always be dependencies, but you have to make a call on whether you enough data to proceed with your work or not.
6. Define the success measures. A very important measure is probably your consumers/stakeholders’ satisfaction, but you should be able to have other measures too. For example, for a plan or roadmap securing the funds for its execution is a good success criteria. For a standard, its degree of adoption (anyone can define a standard that nobody follows…).

No more deliverables, but architecture consumables….