At the risk of being controversial, I don’t believe enterprise architecture is about “alignment between IT and the business”.  While there is not doubt that an effective enterprise architecture practice will improve this sort of alignment, it needs to do more than improve the standing of IT or the percentage of the value pie that IT gets credit for.

Enterprise architecture is a process.  But it’s not a process of creating as-is architectures, creating to-be architectures, and then creating transition roadmaps.  These are useful deliverables and will indeed be produced – but they are no more enterprise architecture than a MS-Project plan is project management.

The process of enterprise architecture is about identifying the activities, information, or assets that you want to standardise and then managing the level of standardisation actually achieved.  It’s also important to note that this process occurs regardless of whether or not the process is called enterprise architecture.

If you look for it, this generic process of standardisation is everywhere.  Even the idea that organisations have ‘products’ and ‘services’ is a form of this standardisation.  It doesn’t require an enterprise architect to see how it would be beneficial to have some standard definition of what you do for your customers.

Another example is in the familiar department structures we see in most organisations: HR, finance, IT, etc.  It has been determined in the past – and may well still be true – that it makes sense to standardise how, for example, payroll is processed.  So you have a payroll department rather than all business units separately designing payroll processes.  It also makes sense that you’d want to standardise the way products are matched with customers.  Although increasingly separate strategies in the information age, this standardisation is traditionally achieved in this case by centralising these activities into a marketing department.

This standardisation in department groupings helps to align each organisation’s capabilities with the dynamics of the labor market.  It also promotes efficiencies through specialisation and definition of labour.  It may not always be the case, but this generic continuous process of standardisation has created these particular groupings because there is value in standardisation in these areas.

Information technology – in the general broad sense that includes processes and methods, but also in common usage as technical I.T. Information Technology – also plays a role in this standardisation process.  To use the payroll department as an example again, it is not uncommon to implement the end-to-end payroll processes beyond what is performed by the payroll department into an ERP package such as those provided by SAP, Oracle, JD Edwards, etc.  This is a process of standardisation.

The real value of enterprise architecture is recursive and somewhat tautological.  Enterprise architecture is a standardisation of the process of standardisation.  It is an attempt at defining how this on-going process of standardisation can be managed.  It’s not perfect, but it’s all we have as a method of managing this process of standardisation with any formality or openness.

Enterprise architecture as an overall integrated framework helps to standardise by providing standard categorisations, definitions, and layers in which standardisation can be achieved.  For example, Technical layers allow for standardisation of platforms, infrastructure, etc.  Whereas Application layers provide opportunities to standardise integration approaches, services, types of common application functionality, etc.  At the Information layer it is standardisation of the definitions of information items that are important so enterprise architecture frameworks assist with that.

In all cases above, the benefits of effective standardisation include reduced costs, increased agility, reduced risks, and an increased capacity for innovation.  The special challenge of the Business architecture layer is twofold.  Firstly, it provides context for the other layers.  Particularly for information and application layer standardisation, it is the only way to understand ‘effective’ standardisation of those other layers.  Secondly, the business architecture needs to identify the areas where investment [in standardisation] will deliver the greatest value.

When is comes to business architecture the standardisation process revolves around ‘capabilities’.  Remember, organisations will keep on operating regardless of what the enterprise architecture team does.  So capabilities may be existing areas where investments can be made, or potential areas based on analysis of the organisation’s customers, strategies, and other capabilities.

Not all capabilities are equal, and the types and degree of benefits that can be obtained through investment will different.  However, if you don’t know what your capabilities are then you can’t make decisions about which to focus on and which to ignore.  The next blog entry will focus on business capability mapping and how it forms the core of the enterprise architecture effort.