(The following is an extract from a Whitepaper which will be released next month)
Enterprise Architecture is one of those annoying concepts. It can generally be perceived as being either too complex ("You want to know everything to an excruciating level of detail!") or too simple ("It's a spreadsheet with a list of our apps on it - what's the big deal?")
The real truth about Enterprise Architecture is actually somewhere in the middle of that continuum. Of course you can define your enterprise to an excruciating level of detail (and that is, indeed, the philosophy extolled by practitioners such as John Zachmann with his Zachmann Framework for Enterprise Architecture), but even Zachmann himself will admit that when you start looking at some of the more esoteric cells in his framework he only has a theoretical knowledge of what goes into them.
The investment in EA may not be realised if there is too much focus on IT-related issues and not enough on business issues. Many companies have used their EA to guide management decisions in change programmes covering M&A, outsourcing, shared services, rationalisation, cost-cutting.
Problem
So the problem then arises of "Given the huge diversity of entities that can be managed through an EA, how can you successfully create an EA that is neither too detailed nor too light?"
Having considered this for some years, it is my experience that EA, basically, comes down to documenting and understanding the inter-relationships between four key sets of items:
Let's see how this would work in practice:
In any business environment, the key driver for change (and therefore the key driver for enterprise architecture) has to be Business Needs. Whether this is a new product or service line, the implementation of a new type of ERP system, the purchase of a new company, or the integration of new legal or statutory requirements, it is all a' business need'.
The Business Needs feed into the business process architecture.
Business Process Architecture
Business Process Architecture identifies and understands the business processes that are needed to support the business needs. This is also where we model organisational functions as well as processes. Functions are set up to manage clusters of related business activities. Business processes are not an alternative to functional structures, they complement them and so both need to be modelled together. In all cases it is paramount to understand that business process is the keystone to successful implementation of the business needs.
Data Architecture
When the business process is known and understood (or more accurately when the impact on the business process is known and understood), the underlying data to support that business process can be identified (using UML models, for example). This can be defined within your business process and recorded for use later. Now that the data need is known and understood the data architecture can define the detail behind that data.
The money is in the data. By that I mean that the competitive advantage your organisation can gain through applying an enterprise architecture will manifest itself in your data. Think about it: As an organisation you modify and update your applications frequently. You install new technology and you change business processes. But how often do you actually discard your business data? It's generally the only thing that is transferred across from one system to another as part of an implementation project and – especially if you are a company such as Google or UPS – there is immense value in your historical data.
Application Architecture
Knowing the types of data that need to be kept, it is than a matter of identifying the type of application that can manage, store and manipulate this data.
Technology Architecture
Once the application requirements are understood the underlying technology to support this can be identified. Will you be using web-based applications – in which case what technology infrastructure will you need to support that? Do the applications run on Wi-Fi hand-held devices? What is the infrastructure needed for that?
These four key facets are the basic building blocks for an enterprise architecture, and generally this is the sequence they are reviewed in and build on each other. But in all cases it is paramount to remember the following:
BP ALWAYS LEADS THE WAY
(There is, however, one exception. This is when a new technology comes along that can be game-changing in terms of it's impact on the business. Look back over recent history and understand how items such as the internet, mobile phones, social media and tablet PC's can give a company a competitive advantage. If these are added to a technology architecture they can then be fed (as a business need) back into the process, resulting in change.)
Tools:
I am firmly of the opinion that “If all you have is a hammer then every problem is a nail”. By that I mean it is very tempting to try and use tools that you already have for things they were not designed to do. The same thing applies to your enterprise architecture. It is all too easy to look at what you currently have in your arsenal and try to apply that to the enterprise architecture. Sometimes this will work, sometimes it won't. Gartner Group identifies two broad classes of EA tools: those which are modelling-based and those which are repository-based. The former focus on visualisation and the latter on decision-support. For effective EA both support categories are needed, such as those offered by MEGA, Troux Technologies and EVA Netmodeler from PROMIS AG. However, many potential users of such tools consider them to be too expensive, overly complex and difficult to apply. But the beauty of a tool such as this is that it will allow entry of information – and most importantly – reporting on that information to answer all the 'what-if' questions you may receive: “What if we decided to restrict internet access in these countries”, “What if we decided to remove this approval step from our manufacturing processes?”, “What if we wanted to relocate our Spanish office from Seville to Madrid”. With a well constructed and carefully maintained repository you could quite easily identify the relevant parts of the EA to answer these questions and determine what would be the right thing to do.
Summary
Creating an EA is usually a fairly detailed and time consuming effort. Unfortunately this is the way with Enterprise Architecture. It is useful to reference the following as a means of focusing your efforts, though.
Start with your business need. Identify the processes needed to support that need. Identify the data needed to support that process. Identify the applications needed to support that data. Identify the technology needed to support those applications and, finally, identify the appropriate toolset to capture and manage all this information.
You don't need to go into the excruciating level of detail that you may have thought you did. Use common sense and this roadmap and your efforts should pay dividends quickly.
(Want to read more from this whitepaper? The document this is extracted from includes a model to illustrate some of these concepts. Check back soon to hear more details about this document and how you can get a free copy of it.)
Enterprise Architecture is one of those annoying concepts. It can generally be perceived as being either too complex ("You want to know everything to an excruciating level of detail!") or too simple ("It's a spreadsheet with a list of our apps on it - what's the big deal?")
The real truth about Enterprise Architecture is actually somewhere in the middle of that continuum. Of course you can define your enterprise to an excruciating level of detail (and that is, indeed, the philosophy extolled by practitioners such as John Zachmann with his Zachmann Framework for Enterprise Architecture), but even Zachmann himself will admit that when you start looking at some of the more esoteric cells in his framework he only has a theoretical knowledge of what goes into them.
The investment in EA may not be realised if there is too much focus on IT-related issues and not enough on business issues. Many companies have used their EA to guide management decisions in change programmes covering M&A, outsourcing, shared services, rationalisation, cost-cutting.
Problem
So the problem then arises of "Given the huge diversity of entities that can be managed through an EA, how can you successfully create an EA that is neither too detailed nor too light?"
Having considered this for some years, it is my experience that EA, basically, comes down to documenting and understanding the inter-relationships between four key sets of items:
- The Business Processes and models;
- The Data and associated models;
- The Applications and their uses;
- The Technologies in use.
Let's see how this would work in practice:
In any business environment, the key driver for change (and therefore the key driver for enterprise architecture) has to be Business Needs. Whether this is a new product or service line, the implementation of a new type of ERP system, the purchase of a new company, or the integration of new legal or statutory requirements, it is all a' business need'.
The Business Needs feed into the business process architecture.
Business Process Architecture
Business Process Architecture identifies and understands the business processes that are needed to support the business needs. This is also where we model organisational functions as well as processes. Functions are set up to manage clusters of related business activities. Business processes are not an alternative to functional structures, they complement them and so both need to be modelled together. In all cases it is paramount to understand that business process is the keystone to successful implementation of the business needs.
Data Architecture
When the business process is known and understood (or more accurately when the impact on the business process is known and understood), the underlying data to support that business process can be identified (using UML models, for example). This can be defined within your business process and recorded for use later. Now that the data need is known and understood the data architecture can define the detail behind that data.
The money is in the data. By that I mean that the competitive advantage your organisation can gain through applying an enterprise architecture will manifest itself in your data. Think about it: As an organisation you modify and update your applications frequently. You install new technology and you change business processes. But how often do you actually discard your business data? It's generally the only thing that is transferred across from one system to another as part of an implementation project and – especially if you are a company such as Google or UPS – there is immense value in your historical data.
Application Architecture
Knowing the types of data that need to be kept, it is than a matter of identifying the type of application that can manage, store and manipulate this data.
Technology Architecture
Once the application requirements are understood the underlying technology to support this can be identified. Will you be using web-based applications – in which case what technology infrastructure will you need to support that? Do the applications run on Wi-Fi hand-held devices? What is the infrastructure needed for that?
These four key facets are the basic building blocks for an enterprise architecture, and generally this is the sequence they are reviewed in and build on each other. But in all cases it is paramount to remember the following:
BP ALWAYS LEADS THE WAY
(There is, however, one exception. This is when a new technology comes along that can be game-changing in terms of it's impact on the business. Look back over recent history and understand how items such as the internet, mobile phones, social media and tablet PC's can give a company a competitive advantage. If these are added to a technology architecture they can then be fed (as a business need) back into the process, resulting in change.)
Tools:
I am firmly of the opinion that “If all you have is a hammer then every problem is a nail”. By that I mean it is very tempting to try and use tools that you already have for things they were not designed to do. The same thing applies to your enterprise architecture. It is all too easy to look at what you currently have in your arsenal and try to apply that to the enterprise architecture. Sometimes this will work, sometimes it won't. Gartner Group identifies two broad classes of EA tools: those which are modelling-based and those which are repository-based. The former focus on visualisation and the latter on decision-support. For effective EA both support categories are needed, such as those offered by MEGA, Troux Technologies and EVA Netmodeler from PROMIS AG. However, many potential users of such tools consider them to be too expensive, overly complex and difficult to apply. But the beauty of a tool such as this is that it will allow entry of information – and most importantly – reporting on that information to answer all the 'what-if' questions you may receive: “What if we decided to restrict internet access in these countries”, “What if we decided to remove this approval step from our manufacturing processes?”, “What if we wanted to relocate our Spanish office from Seville to Madrid”. With a well constructed and carefully maintained repository you could quite easily identify the relevant parts of the EA to answer these questions and determine what would be the right thing to do.
Summary
Creating an EA is usually a fairly detailed and time consuming effort. Unfortunately this is the way with Enterprise Architecture. It is useful to reference the following as a means of focusing your efforts, though.
Start with your business need. Identify the processes needed to support that need. Identify the data needed to support that process. Identify the applications needed to support that data. Identify the technology needed to support those applications and, finally, identify the appropriate toolset to capture and manage all this information.
You don't need to go into the excruciating level of detail that you may have thought you did. Use common sense and this roadmap and your efforts should pay dividends quickly.
(Want to read more from this whitepaper? The document this is extracted from includes a model to illustrate some of these concepts. Check back soon to hear more details about this document and how you can get a free copy of it.)
Reminder: 'The Perfect Process Project' is still available. Don't miss the chance to get this valuable insight into how to make business processes work for you.
Click this link and follow the instructions to get this book.
For more about me check out my "About Me' page
All information is Copyright (C) G Comerford
