Fit for Purpose Architecture

I struggled to find a satisfactory definition of fit for purpose architecture.

Here is the best I could come up with. Please suggest any improvement you can offer, and add links to other definitions that you found helpful.

A solution/application/system/service architecture is fit for purpose when it is acceptably and reasonably:

- fit for its intended purpose: does what it’s supposed to do (meets the requirements of its users and sponsor)
- appropriate: is aligned to the existing strategy and as congruent as possible with the target architectures and roadmaps
- of a necessary standard: adequately addresses the concerns of those stakeholders with enterprise requirements
- economically viable: implementable within a reasonable time and at a reasonable cost

Enterprise Requirement is a requirement that exists beyond the boundaries of the program. These are sometimes referred to as standards, policies or constraints. Regulatory, Security, Strategic alignment, Business Continuity, Operability, Outsourcing, Policies, etc. are examples of enterprise requirements.

Image | Posted on January 23, 2013 by | Tagged , , , | Leave a comment

Not deliverables, but architecture consumables

Posted on November 22, 2012 by
waste please

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….

Posted in architecture capability, Process | Tagged , , , , , , , , , , , , , , | 1 Comment

Architecting as a Business Capability

English: Capability management

English: Capability management (Photo credit: Wikipedia)

I think of IT Architecture Capability as the combination of people (their competencies and skills, regardless of their team names or job titles), methods, information and supporting tools that allows an organization to consistently produce IT products with a fit-for-purpose architecture, cost effectively.

I believe that Architecting IT solutions that are fit for purpose is an important business capability in many enterprises. Not strategic, in most cases, but definitively important. It needs to be done well, and it needs to be done cost effectively.

Being a business capability, I would argue that the architecture practice of an IT organisation should be run like a business, competing with other business capabilities (marketing, operations, sales, etc) for organisational resources to generate value that exceeds the cost of capital. As such, traditional technical competencies are necessary but insufficient to be successful. An organisation designing the best cars in the works, will fail without supporting competencies in marketing, production, performance measurement, supplier management, quality, and many other disciplines.

Ultimately, to be successful, an architecture practice needs to provide to its stakeholders (within and outside IT) what they need, cost effectively. Worth repeating: to be successful, your architecture practice needs to provide to your stakeholders what they need at a reasonable cost.

Aside | Posted on October 21, 2012 by | Leave a comment