Wednesday, December 3, 2014

Improving solution architecture by reducing the need for archaeology and being clear on requirements


I want to start with a simple analogy to avoid the scope for erudite excuses I hear so often from practitioners in IT. The reality is with new classes of solutions a very small change by each party can produce a dramatically different outcome.


Building - something we all know and understand
When a change is required to a building (or any complex technology) there are 4 things to consider when we are doing the high level design (e.g. the level of design done by architect):
  1. how things should be built. For a build the building codes and regulations which indicate what things such as: technologies (products, materials) can be used for what purposes and in what way (patterns, best practice, standards, etc.) and; various other constraints re how the new building should relate to other existing, or future, elements in the environment (how it should connect, that it should not obstruct etc.)
  2. what exists - For a build what existing buildings, infrastructures, common services, etc. exist (in just enough detail to know how they will be impacted, which is typically a lot less detail than is required to construct them i.e. we don't need to know where every nail or bolt is placed or necessarily where every detailed element exists or why).
  3. what the requirements are. For the new building. what products and capabilities it should enable, what it should enable to be done (e.g. functions and processes it should support), what it should store, who should be able to use it (roles, positions, types of people), what characteristics it should have (secure, efficient, safe, etc.), budgets and key dates etc.
  4. what will be delivered. For a building. a high design can be created that determines what is to delivered (built or bought) and how. It doesn't need to determine the placement of every building element - just sufficient to be clear what is to be delivered, how it relates to what exists, what requirements it meets (for the client) and that it will code with key codes (for the town planner). Most of detailed engineering designs necessary for constructions are done at follow stages by specialised engineers, designers and trades.
With buildings.
Town planning function aims to ensure:   a) how things should be built is clear
   b) what exists is know - so archaeological for new projects is minimised.
   c) what is built is recorded - so future archaeology is not required.
Architects aim to convey   d) what they understand the requirements to be
   e) what is to be delivered (for the client)
   f) how what is to be delivered meets the requirements
   g) how what is to be delivered relates to what exists
   h) that what is to be delivered is compliant with standards and codes.

Fortunately with building few town planners were once carpenters, who became architectures and then became town planners - and each level is relatively clear on its responsibilities, methods and tools.

IT - something we all know and understand doesn't deliver well.
When we look at changes in IT systems or businesses themselves we need to know the same things.
  1. how things should be built e.g. what: technologies can be used for what purposes and in what way (patterns, reference architectures); other constraints re how the new elements should relate to other existing, or future, elements
  2. what exists e.g. existing infrastructures or common services exist (in just enough detail to know how they will be impacted, which is typically a lot less detail than is required to construct them - i.e. we don't need to know where every nail or bolt is placed or necessarily where every detailed element exists or why).
  3. what the requirements are e.g. products and capabilities enabled, functions and procesess supported, information stores, users (roles, positions), characteristics it should have (secure, efficient, safe, etc.), budgets and key dates, etc.
  4. what will be delivered - a high design that shows is to delivered (built or bought) and how. It doesn't need to determine the details of every element - just sufficient to be clear what is to be delivered, how it relates to what exists, what requirements it meets, and that it will code with key codes. Most of detailed engineering designs necessary for constructions are done at follow stages by specialised engineers, designers and implementation specialists.
With IT.
Enterprise Architecture aims to ensure:   a) how things should be built is clear
   b) what exists is know - so archaeological for new projects is minimised.
   c) what is built is recorded - so future archaeology is not required.
Solution Architecture aims to convey  d) what they understand the requirements to be
  e) what is to be delivered (for the client)
  f) how what is to be delivered meets the requirements
  g) how what is to be delivered relates to what exists
  h) that what is to be delivered is compliant with standards and codes.

Unfortunately with IT many of enterprise architects where once are software engineers, who became solutions designers then became enterprise architects - and each level is not very clear on its responsibilities, methods and tools.

To complicate things further in a complex enterprise there are many initiatives operating in parallel and what is required to ensure all the changes fit together is a canonical view (common to all) or the things the requirements relate to: products, capabilities, functions, information, roles, positions etc.  So steps d & e need to allow all to understand overlaps and possible conflicts as early as possible.

How it can be done better With modern EA/EPM solutions the basis is provided for recording:
  a) how things should be built - standards and patterns
  b) what exists - so archaeological for new projects is minimised.
  c) what is actually built - so future archaeology is not required.
  d) what is requirements -
       by all projects and a specific project (explicitly related to a canonical view of the enterprise)
  e) what is to be delivered (solution architecture) can be clearly seen as a set of elements. 
      by all projects and a specific project (explicitly related to current assets and future assets).
  f) how requirements map to solution elements
  g) how what is to be delivered relates to what exists
  h) how what is to be delivered is compliant with standards and codes.

One can see from this that critical to improving how solution architecture is done - and minimising the need for archaeological efforts in this work is improving the recording of a to h. It requires a holistic view that sits above several streams of activity that are frequently siloed. Traditionally: EA has been strong on a, b but relatively weak on c. Solution Architecture has been weak on: d, e & f; Requirements teams have failed to relate their requirements to either a canonical of the business or its assets.

A very small change by each party can produce a dramatically different outcome.