Develop Capability Not Architecture: the next frontier in ICT delivery Reply

In our previous blogs we outlined the key problems facing enterprise architecture, namely:  (a) overwhelming complexity, (b) poor integration of concepts, (c) lack of financial relevance, and (d) poor program choice.  The real problem with enterprise architecture is, however, architecture.  Rather it is the focus on architecture, equipment, kit or stuff which is the real problem.  Engineers do what engineers like to do best – build things.  Yet, in focusing on structures enterprises fail to take heed of the things that matter financially – functions.

In order to deliver benefit and value enterprise architecture must create a language whereby the ‘objects’ of financial analysis may be moved directly to the design community within a single model.  This may be as simple as the numbers on a spreadsheet or as complex as objects within a UML model.

One solution is through capability.  Capability provides us with the means to bridge the gap between the design structures of an organisation/enterprise and its functions – the primary functional model being the value chain.

The first level of decomposition from the value chain is the set of Value Activities (Porter provides no further guidance on decomposition and cost allocation).  A value activity is the key to differentiation, i.e. by arranging value activities in a unique way companies achieve a competitive advantage through differentiation of their value chains.  The specification of a value activity, however, is a capability.

Capability is already accounted for within defence architectural frameworks such as MoDAF and is defined as “the specification of an enterprise’s ability to do something.” Capability is the sum total of all people (roles), processes, systems and infrastructure necessary to perform a function.

Companies and government departments/agencies have many capabilities but all of them should be described at the same level (i.e. primary capabilities) and seen as the instantiation of value activities.  Otherwise, the term capability may inspire higgledy-piggledy capability and sub-capability definition.  It is our experience that deriving them directly from value activities is the easiest and most efficient means of capability definition.

Once performed, capability definition may be visualised similar to Figure 1.  Capabilities stretch over many functions and may not necessarily include all in between.  Moreover, once performed, capabilities mustbe checked against financial cost allocation to ensure that they match.  There is little point coming up with an ontologically correct definition of an operational asset if the finance department have assigned its costs elsewhere.  Given that the primary means of a capability model is for the efficient investment of capital it is best that the work is performed in conjunction with the CFO’s office.

Capabilities are powerful concepts yet poorly understood and implemented worse.  Capabilities have the ability to empower enterprise architecture and finally make it commercially relevant.

Enterprise architecture will fail to gain any traction within the corporate environment so long as it cannot achieve a meaningful link between finance and ICT.  When it does, enterprise architecture will hold the key to dealing with commercial complexity and organisational entropy.

How to do “Anti-Law” (What is “Anti-Law” – Pt 2) Reply

THE BIG IDEA

Designing legal clauses should be an extension of the architectural process.  The contract then should be about 75-85% by design directly from the business and technical architectures and the taxonomy (terms).  The rest will be terms of art (contract construction, jurisdiction etc).

WE ALREADY DO IT

The first thing people say to me when I set out this proposition is that it’s obvious and sensible.  So, why isn’t it done already?  Well, to a certain extent it is, we just don’t know it.  Secondly, it’s not intuitive – it’s not the logical next-step when we’re doing the work.  Firstly, we do already do it:  most commercial and technical managers already understand a great deal of the law surrounding their areas and simply design around it. Secondly, commercial architecture – cost models, program plans etc which are just the attributes of the other architectures – have no spatio-temporal extent.  We can’t see, feel or touch them like we can the stuff we’re engineering and therefore our understanding is governed by how we construct these concepts and thoughts in our mind (Wittgenstein).

THE COUNTERINTUITIVE BIT

The counterintuitive bit is that many commercial entities are actually separate things  – they are relationships to an entity.  In ontological terms they are ‘tuples’ and instantiated on their own.  In the same way that a packet of cornflakes has a cost and then the manufacturer puts a price on it.

The price is a different thing but related to the cost. We know that the price, in turn is related to their profit margin which in turn is related to their overheads which in turn are made of R&D costs, admin, advertising etc.  All these elements are part of the business architecture which influences the commercial (financial and legal) architecture of the given project.

WHAT RELATIONSHIPS

Risk is the key relationship we are modelling.  It is best to see risk as a relationship rather than a property.  Widget A does not have risk in and of itself.  Widget A does have risk when used in a certain machine, in a certain contract.  This is important to note because in later whitepapers I will talk about the need to separate the logical and physical commercial architectures in order to make trade-offs and impact assessments.

ARCHITECTURAL RISKS

Risk links to architecture through a series of relationships.  Ultimately, if we look at components in a database then the relationships I would draw would be:

REQUIREMENT > ELEMENT > CONTEXT > RISK > MITIGATION > MITIGATION INSTANTIATION > CONTRACT CLAUSE.

In the above the ‘context’ is the domain architectural instantiation (the physical architecture) we are modelling, for instance, Architecture A or 1 etc.  This allows us to compare risk profiles across different possibilities and then make trade-offs.  The difference between the ‘mitigation’ and the ‘mitigation instantiation’ is merely logical v physical.  Logically we might wish to insure against a risk but when it comes down to it physically we are insuring part, funding part with a bond issue and hedging against the rest. The point is to identify clearly in the model what is mitigated and what is not.  In a large and complex model of thousands of elements we will want to make sure that all mitigations are accounted for and their are no overlaps.  If we’ve overlapped mitigations (insurance, loans etc) on a number of parts then the cost could be astronomic.  The calculations will be clearer in later whitepapers when I explain how to aggregate derived risk.

PHYSICAL MITIGATIONS

The physical mitigations are the most important things to agree on.  These are the processes and the structures that the business must agree on.  This will be a collaborative effort of legal, financial, technical and programmatic.  They must be realistic, sensible and accounted for in the program plan.  Once clearly set out then a precise and specific contract clause (not a mopping-up clause) can be tightly crafted around each and every one.  These clauses must have triggers built into the program plan and each trigger must have adequate information derivation for decision making (ie, you need to know when the clause might need to be used).

The trick in all of this is not in deciding what to do but in identifying the risks in the first place but that is for examination another time.

HOW TO MITIGATE

Repackaging risk to mitigate effectively will be the topic of another blog.

What is ‘architecty’ about IT architecture? Reply

While the building and construction industry may rail against the self-proclamation of architect status by IT workers one wonders whether to whom the greater disservice is being done.  Although a ‘system’ may not manifest such obvious beauty to which we turn and marvel in the spectacle of its design the question should be asked – cannot a system have elegance too?

What is ‘architecty’ about architecture?

To me architecture has always encompassed the synergy of design and form.  It is the gentle blending of the functional with the artistic.  An objet d’art yet a liveable space with true vitruvian utility.  An expression of values and placement in the world yet something obviously sensible and practical.  Entirely down to earth yet striving to connect with the heavens.  Think of the pyramids, the Taj Mahal or the Paris Opera.  Can we compare IT to these? Could we ever design an IT system that could convey the sense of awe and achievement that great buildings and spaces inspire?

Possibly.

First we must broaden our perspective of ‘system’.  I always think of a system as a collection of parts functioning in unison for a common purpose:  the body, the metro, a biometric system at an airport or even a bee colony.  A system has spatio-temporal extent.  It is not conceptual and we can and do interact with it – purposefully or not.  It will always be hard to describe a network of underfloor cables and servers as beautiful.  But what about a well designed software application?  Where code has been masterfully crafted together into a contained system which delivers meaning to our lives and allows us greater utility to interact with humanity and our environment, can that be architecture?  What of the larger system?  Think of Ewan McGregor in “The Island”.  Possibly not the best example but a highly complex yet (almost) perfect blending of the utility of the system with the elegance of its structure.

What is elegant about systems?

Edward de Bono describes a good joke as one that is completely logical and obvious only in hindsight.  I think an elegant system is the same:  almost impossible to design logically and progressively but rather, it requires some divergent and parallel thinking to arrive at the seemingly obvious answer.  An architected system, therefore, should be a pleasure to use; inspiring and yet unintrusive, functional and provide us a clear means to our ultimate goal.  The Venetian transport system, Facebook even?

What do IT people do that is creative and beautiful?

IT allows us to interact with our environment in a way which not only heightens the end experience but the overall journey.  Software designers can create incredible applications which are not only functionally rich but are also a delight to interact with.  We can all think of a system that encompasses these things but there is one thing that architecture isn’t and that is haphazard.  ‘Architecting’ is design for purpose of a single entity.  Whether at the macro or micro level, architecting produces a single ‘architecture’.  It has unity, singular identity and purpose.  Think of the Parisian skyline.  There is one thing for certain and that is that architecting haphazardly is as bad as not architecting at all.

A new word for IT architects?

Even So, do IT architects ‘architect’.  Most usually not.  I would say that software designers often will come the closest.  This is not to say that IT is just Lego – positioning per-fabricated electronic building blocks to achieve a slightly different look.  By and large IT is more about technical engineering (capacity, throughput, interface, latency, queuing) than it is about designing into the human experience but this does not mean that it has to be nor is it always the case.