Capabilities, reference-models and job-descriptions

Back to enterprise architecture, with a cross-link to another previous discussion on capability.

Reference-models are a key deliverable for many enterprise-architecture processes – for example, the Business Reference Model (BRM) or Performance Reference Model (PRM) in FEAF, or the Foundation Architecture Technical Reference Model (TRM) in TOGAF. But I’ve been thinking for quite a while now about how we actually use those reference-models in practice, because there’s no point in defining a model unless it has some practical business purpose.

Strikes me that what we’re really doing in a reference-model is defining a set of desired capabilities; and that to put that into practice, the closest analogy elsewhere in business is the job-description, because that too is a summary of skills and experience – capabilities and ‘response-abilities’, in other words – that are deemed to be necessary in order to do a specific set of business tasks.

That point here is that a job-description defines what we want – which is rarely identical with what we’re likely to get. In practice, real-world candidates will usually have both less and more than we say we need for the task: they will have some of the skills and experience that we need, and will also have other skills and experience that may be relevant elsewhere in the enterprise. (Unlike most machines, they can also learn new skills if and as required!) We use the ‘required skills’ section of the job-description as a risk-management tool, a filter to constrain the list of candidates to those most likely to match the immediate task-requirement; but we then also use the job-interview as an opportunity-management tool, to identify each candidate’s potential to act not only as a specialist for the task in scope, but also as a generalist providing links for end-to-end processes across the enterprise silos and hierarchies.

The reference-model describes what should happen in an idealised world, within a constrained scope – the ‘to-be’ of a portion of the overall enterprise architecture.

The way we use the reference-model is as a guideline to describe the capabilities that we believe would best fit the identified business-need. We then assess candidates for those capabilities against the reference-model, using both risk-management – “how well does the candidate fit the requirement?” – and opportunity-management – “what opportunities does this candidate provide for enhancements, for innovation, or for greater coherence across the whole?”.

What we don’t try to do is demand that everything should fit exactly to the reference-model definitions. The reference-model describes an imaginary ideal that doesn’t exist in the real world: trying to force the real world to fit an imaginary ideal is a guaranteed recipe for frustration, futility and failure. Instead, just as with job-candidates, we need to accept that there will always be exceptions, things that ‘don’t fit’ – and that there are many opportunities that arise from that ‘don’t fit’, too.

So how does this work in practice? Perhaps the simplest way to describe this is to summarise in terms of the FEAF stack:

• The Business Reference Model (BRM) describes the layering of what and how we expect to deliver to our end-clients – ‘services to citizens’, in a FEAF-style government context, or partners and customers in a commercial context.
  • Risk-management: do we have the business-capabilities to deliver those services?
  • Opportunity-management: what other services could our existing or amended capabilities enable?
• The Performance Reference Model (PRM) describes how we will monitor service-delivery, and identify ‘success’ in the BRM’s terms.
  • Risk-management: do we have the right metrics and correct capabilities to monitor and validate performance.
  • Opportunity-management: what else could those metrics and capabilities imply?
• The Service Reference Model (SRM) is slightly more problematic, because it describes a ‘bundling’ of capability and function into a pre-packaged service.
  • Risk-management: do we have the right capabilities to deliver the BRM’s services and PRM’s metrics, and are they bundled together with appropriate business-functions or other functions to create the right services? In what ways do or could we ‘slice and dice’ different technologies and delivery-techniques to provide the full set of required services? How do we cover the gaps in service-delivery that are not addressed by any of our candidate technologies?
  • Opportunity-management: what other ways could we combine our capabilities and functions, and what else could those alternate services deliver?
• The Data Reference Model (DRM) describes the layering of data, information and (in principle) knowledge needed for each of the capabilities and services.
  • Risk-management: do we have all the data we need, when and where we need it, and the right IT-based, human and other capabilities and services to transform that data to the required information? How do we fill the gaps in knowledge-management, especially those that cannot be covered by any available technology?
  • Opportunity-management: how else could we use and re-use that data, information and knowledge?
• The Technical Reference Model (TRM) at present usually refers only to IT, but could and should cover all forms of technology used within the enterprise.
  • Risk-management: what capabilities, functions and services does the candidate technology provide? How do we fill the gaps that cannot be covered by any available technology?
  • Opportunity-management: What other capabilities does the candidate technology enable? What new services could be created via ‘mashups’ of those capabilities with other already-available technologies in the enterprise?

Each person enables their own unique ‘mashups’ of different capabilities and services, through their own specific ideas, relations, experiences, skills and capabilities; it’s the alignment of these with the needs of the enterprise – the risks and opportunities for the enterprise – that we assess in a job-description and job-interview.

So it’s useful to think of architecture reference-models in the same way: they form the ‘job-description’ for a set of capabilities in some context within the enterprise, whilst the architecture-assessment is the analogue of the ‘job-interview’. In the real world, it’s rare that we would find a job-candidate who has matches every detail of the job-description; in much the same way, it’s rare to find a set of technologies that match all of our expectations – and if we did, it would probably prevent us from seeing other opportunities that those ‘not-quite-right’ technologies could enable.

Architecture provides a means for both risk-management and opportunity-management: reference-models perform part of that function. But we do need to be realistic about it, just as we are with job-descriptions and job-candidates: in the real world, a reference-model can only ever be a ‘recommended guideline’, not an instrument for delusory attempts at ‘control’.

And the ‘why‘ of architecture also comes to the fore here: whenever we vary from the recommendations of the reference-model, we need to be clear as to why we’re doing so, and what risks and opportunities that variance implies. If we don’t have an enterprise-architecture in place – a real ‘architecture of the enterprise’ as a whole, not solely an incomplete architecture of the enterprise IT – we’d be unlikely to have sufficient understanding of that ‘why’ and its implications across the enterprise… which could lead to dangerous assumptions, unnecessary constraints, many unnecessary risks, and many, many lost opportunities. Architecture matters.

Reference-models are the ‘job-descriptions’ for the capabilities of the enterprise as a whole. What difference does that make for your architecture practice, and for you as an architect, if you rethink your reference-models in this way?