Browse All Articles > What is Enterprise Architecture?
The purpose of this article is to present my own view on Enterprise Architecture, the roles of the Enterprise Architect and the discipline Architects, what it does, what it means and why you should know this – or sections of it - already.....
For some reason, being an ‘Architect’ appears to be the new buzz word that everyone wants to be associated with and this fad has become more blatant. Whether it is because it sounds ‘cool’ to be thought of as an Architect amongst peers or it suggests a higher pay grade I really do not know – what I do know is that it is probably one of the most abused terms in the past couple of years.
So what is Enterprise Architecture? There are many definitions and each tries to encapsulate views from different standpoints. As this is my article, I will stick to the approach I adhere to as Head of Architecture. That approach is in line with guidance from IFEAD or the Institute For Enterprise Architecture Developments. Their web site and related information can be found here: http://www.enterprise-architecture.info/ifead%20about.htm. I am not on their payroll nor do I receive anything from them............
Enterprise Architecture is very simplistically the Architecture of the Enterprise – easy wasn’t it. So what is an Enterprise? For me, the Enterprise incorporates absolutely everything that makes up the organisation that I work for. This ranges from the top to the bottom and incorporates areas such as:
The Enterprise Architect works at the heady heights of the organisation where decisions are made on its mission and vision statements, its goals and objectives, where it sees itself in five to ten years, what sort of deliverables does the organisation need to produce, what are the outcomes and what would they look like so as to be able to state later that they had been achieved successfully? The organisation's strategies of how they will get from where they are now to their target position in X years ahead, what principles will drive this change or even what legislation might control these changes. In short, this is almost a summary of what makes the organisation tick, its reason for being an organisation in the first place.
In the middle, we have several areas dealt with by Solution Architects. Sometimes this can be an individual but are often covered by Architects of each discipline – namely a Business Architect, an Applications Architect, A Data or Information Architect and last, but not least, a Technology or Infrastructure Architect. These cover how the business is run. For example, what business processes have been introduced to allow the organisation to carry out its functions and to meet the expectations and strategies set out by the Enterprise Architect? Do all business processes align to the organisation strategies? What types of application are required to support the business processes? What form of data or information is needed by the systems used within the organisation? What environment(s) are needed to host the applications and data allowing them to be run?
At the bottom of the tree are the data architects, the software architects, the network architects and so on. These are the people who will advise the organisation on the actual systems, applications, data models et al that need to be implemented to support all of the above.
The tree mentioned above encapsulates the whole, and every facet whether at the top, middle or bottom is vital within the Enterprise.
By capturing, documenting and communicating a view of the Enterprise in its current condition you create a vision of the Enterprise known as the ‘as is’ state. Although not necessarily cheap, the use of a good Enterprise Architecture modeling tool is worth its weight in gold. Not only can you enter in all of the information gathered it can draw relationships between each piece of information. Which business processes support which strategies, which applications support which business processes, what data is used by which applications and so on. Just as many people record this information in spread sheets or Visio diagrams. Whatever works for you is fine but the benefits of having all the information recorded in one system are significant.
This documentation or model of the Enterprise can be passed around, published or presented within the organisation allowing the business users to verify that the model is correct and reflects the strategies. Verification can come from board members, executives, managers and line staff – all will have a view. Some of the best improvements come from the rank and file – the people who actually do the bulk of the work.
It never ceases to amaze me though that if you asked ten people to describe what the organisation strategy is you will get ten different answers. Not surprising but still makes me smile. However, ask ten Architects and you will also get ten views so I’m not smirking too much.....
You would probably be staggered to also know how many managers within an organisation have no concept of the Enterprise. They know what they do, they know why they do it – but how it drives or fits within a particular business strategy – you would likely be surprised at the relatively low figures. Further, by communicating the ‘as is’ model, it becomes apparent where business processes are not aligned to strategy, or there are duplicate applications supporting one business process. Just as commonly, there may be five applications with databases all holding similar information to each other. Prime culprits are often the HR system and the Finance systems – each with their own admin, license and support costs and both able to tell you how many users you have....
Performing the same activity against a model of where the organisation wants to get to creates a future or ‘to be’ state. Comparing the ‘as is’ model against the ‘to be’ model through GAP analysis creates the roadmap of projects, business process improvements, timelines and consolidation or technology changes that need to be considered by the Enterprise Architecture Board or EAB.
The EAB is responsible for the Governance of the Enterprise Architecture and is a crucial driving or controlling force. It sets out the rules and the guidelines under which enterprise Architecture will be conducted. A couple of my favourites are obvious ones but are still ignored by many organisations I have worked with or for:
Two rules that I think are brilliant....
‘Data is an asset, Data will be shared, and Data will always be available’. What a brilliant comment. In one line, it sets the scene for Business Architects who must ensure that access to data is a commodity that has revenue connotations; to the Application Architect who must ensure that COTS or developments must be on a services approach rather than a silo application; to the Data or Information Architect to ensure that the databases must be structured and available to all the applications that need it; and finally to the Infrastructure/Technology Architect that not even a site failure must stop services being available so failover/resilience is the order of the day.
All developed code must be reusable. Simple, but as it is stated as a rule and communicated to all partner/supplier organisations as a firm, auditable requirement, it brings in standards that can be monitored.
A sample guideline might be:
We will always use Microsoft technology if their solution can meet 95% of more of the business requirement.
The rules are fixed, the guidelines are just that.
The EAB will normally comprise members of the Board, some of its Directors, Senior Managers, maybe representation from IT, and hopefully representation from an organisations user base and supplier chain. ALL of these groups will have a vested interest in where the organisation is headed, how it performs, and how it is doing. It is widely recognised that including all interested stakeholders is the best course of action. It also covers you as an individual from the ‘it was his idea, honest - I had nothing to do with it!’ comments and accusations.
GOD help the organisation that has ‘The Visionary’ who thinks he alone can drive everything himself and drag everyone else along regardless of the views of others. The truth is that more stakeholder involvement at each stage means less missed opportunities, a more diverse environment, better understanding and a consolidated set of views on the bigger picture
Fortunately the days of this type of individual are passing as typically they alienate everyone around them and they certainly have no place within a functioning Enterprise.
At a very basic level the following are other roles often seen within an Enterprise Architecture structure:
The Business Architect, not surprisingly, focuses mainly on the business end of things and how the business is meeting the objectives – and therefore the goals – of the organisation. They will review the business processes that have been introduced looking for duplication, improvements that can be made or where there are gaps. Ensuring each process has an owner within the business, that procedures are in place and reviews are undertaken and that each are effective and efficient.
The Applications Architect looks after the applications portfolio, again endeavouring to ensure that application designs meet the needs of the business processes they support, removing duplication and planning the approach to meet the needs outlined in the ‘to be’ model. This may include the alignment of development techniques for example migration applications to a .net SOA approach from VB for new or existing systems.
The Data or Information Architect will be involved in the design of data structures within databases or other data repositories. Ensuring that corporate data is only held once in a structured, relational set of databases and called by different applications that need it as opposed to having multiple copies of similar data within databases that are solely used by their own application. Making changes to the address of a customer in ten different data locations is painful, unrewarding, an admin burden and pointless.
The Technology or Infrastructure Architect is responsible for designing the environments that securely and efficiently host the applications and the data. This will normally cover everything ‘under the hood’ from network topologies, security, backups, resilience/failover, storage to name but a few.
It is worth noting here that Architects are rarely the implementers of the designs. The implementers are the Business managers, the developers, the Database administrators and the network/server engineers. The Architects design and create the frameworks that the implementers will follow. In addition - a fact that often differentiates an Architect from an implementer, system or network engineer etc is that the Architect is rarely concerned about product selection. Technology - yes, Methodology - absolutely, but product x or product y - not really.
In summary, having a defined Enterprise Architecture allows your organisation a single view of where you are, where you want to be and what has to be done to get there.
In another Article, I will cover how the various architectures fit together and the benefits this provides.
Sequential Articles:
http:/A_2457.html
http:/A_2488.html
For some reason, being an ‘Architect’ appears to be the new buzz word that everyone wants to be associated with and this fad has become more blatant. Whether it is because it sounds ‘cool’ to be thought of as an Architect amongst peers or it suggests a higher pay grade I really do not know – what I do know is that it is probably one of the most abused terms in the past couple of years.
So what is Enterprise Architecture? There are many definitions and each tries to encapsulate views from different standpoints. As this is my article, I will stick to the approach I adhere to as Head of Architecture. That approach is in line with guidance from IFEAD or the Institute For Enterprise Architecture Developments. Their web site and related information can be found here: http://www.enterprise-architecture.info/ifead%20about.htm. I am not on their payroll nor do I receive anything from them............
Enterprise Architecture is very simplistically the Architecture of the Enterprise – easy wasn’t it. So what is an Enterprise? For me, the Enterprise incorporates absolutely everything that makes up the organisation that I work for. This ranges from the top to the bottom and incorporates areas such as:
The Enterprise Architect works at the heady heights of the organisation where decisions are made on its mission and vision statements, its goals and objectives, where it sees itself in five to ten years, what sort of deliverables does the organisation need to produce, what are the outcomes and what would they look like so as to be able to state later that they had been achieved successfully? The organisation's strategies of how they will get from where they are now to their target position in X years ahead, what principles will drive this change or even what legislation might control these changes. In short, this is almost a summary of what makes the organisation tick, its reason for being an organisation in the first place.
In the middle, we have several areas dealt with by Solution Architects. Sometimes this can be an individual but are often covered by Architects of each discipline – namely a Business Architect, an Applications Architect, A Data or Information Architect and last, but not least, a Technology or Infrastructure Architect. These cover how the business is run. For example, what business processes have been introduced to allow the organisation to carry out its functions and to meet the expectations and strategies set out by the Enterprise Architect? Do all business processes align to the organisation strategies? What types of application are required to support the business processes? What form of data or information is needed by the systems used within the organisation? What environment(s) are needed to host the applications and data allowing them to be run?
At the bottom of the tree are the data architects, the software architects, the network architects and so on. These are the people who will advise the organisation on the actual systems, applications, data models et al that need to be implemented to support all of the above.
The tree mentioned above encapsulates the whole, and every facet whether at the top, middle or bottom is vital within the Enterprise.
By capturing, documenting and communicating a view of the Enterprise in its current condition you create a vision of the Enterprise known as the ‘as is’ state. Although not necessarily cheap, the use of a good Enterprise Architecture modeling tool is worth its weight in gold. Not only can you enter in all of the information gathered it can draw relationships between each piece of information. Which business processes support which strategies, which applications support which business processes, what data is used by which applications and so on. Just as many people record this information in spread sheets or Visio diagrams. Whatever works for you is fine but the benefits of having all the information recorded in one system are significant.
This documentation or model of the Enterprise can be passed around, published or presented within the organisation allowing the business users to verify that the model is correct and reflects the strategies. Verification can come from board members, executives, managers and line staff – all will have a view. Some of the best improvements come from the rank and file – the people who actually do the bulk of the work.
It never ceases to amaze me though that if you asked ten people to describe what the organisation strategy is you will get ten different answers. Not surprising but still makes me smile. However, ask ten Architects and you will also get ten views so I’m not smirking too much.....
You would probably be staggered to also know how many managers within an organisation have no concept of the Enterprise. They know what they do, they know why they do it – but how it drives or fits within a particular business strategy – you would likely be surprised at the relatively low figures. Further, by communicating the ‘as is’ model, it becomes apparent where business processes are not aligned to strategy, or there are duplicate applications supporting one business process. Just as commonly, there may be five applications with databases all holding similar information to each other. Prime culprits are often the HR system and the Finance systems – each with their own admin, license and support costs and both able to tell you how many users you have....
Performing the same activity against a model of where the organisation wants to get to creates a future or ‘to be’ state. Comparing the ‘as is’ model against the ‘to be’ model through GAP analysis creates the roadmap of projects, business process improvements, timelines and consolidation or technology changes that need to be considered by the Enterprise Architecture Board or EAB.
The EAB is responsible for the Governance of the Enterprise Architecture and is a crucial driving or controlling force. It sets out the rules and the guidelines under which enterprise Architecture will be conducted. A couple of my favourites are obvious ones but are still ignored by many organisations I have worked with or for:
Two rules that I think are brilliant....
‘Data is an asset, Data will be shared, and Data will always be available’. What a brilliant comment. In one line, it sets the scene for Business Architects who must ensure that access to data is a commodity that has revenue connotations; to the Application Architect who must ensure that COTS or developments must be on a services approach rather than a silo application; to the Data or Information Architect to ensure that the databases must be structured and available to all the applications that need it; and finally to the Infrastructure/Technology Architect that not even a site failure must stop services being available so failover/resilience is the order of the day.
All developed code must be reusable. Simple, but as it is stated as a rule and communicated to all partner/supplier organisations as a firm, auditable requirement, it brings in standards that can be monitored.
A sample guideline might be:
We will always use Microsoft technology if their solution can meet 95% of more of the business requirement.
The rules are fixed, the guidelines are just that.
The EAB will normally comprise members of the Board, some of its Directors, Senior Managers, maybe representation from IT, and hopefully representation from an organisations user base and supplier chain. ALL of these groups will have a vested interest in where the organisation is headed, how it performs, and how it is doing. It is widely recognised that including all interested stakeholders is the best course of action. It also covers you as an individual from the ‘it was his idea, honest - I had nothing to do with it!’ comments and accusations.
GOD help the organisation that has ‘The Visionary’ who thinks he alone can drive everything himself and drag everyone else along regardless of the views of others. The truth is that more stakeholder involvement at each stage means less missed opportunities, a more diverse environment, better understanding and a consolidated set of views on the bigger picture
Fortunately the days of this type of individual are passing as typically they alienate everyone around them and they certainly have no place within a functioning Enterprise.
At a very basic level the following are other roles often seen within an Enterprise Architecture structure:
The Business Architect, not surprisingly, focuses mainly on the business end of things and how the business is meeting the objectives – and therefore the goals – of the organisation. They will review the business processes that have been introduced looking for duplication, improvements that can be made or where there are gaps. Ensuring each process has an owner within the business, that procedures are in place and reviews are undertaken and that each are effective and efficient.
The Applications Architect looks after the applications portfolio, again endeavouring to ensure that application designs meet the needs of the business processes they support, removing duplication and planning the approach to meet the needs outlined in the ‘to be’ model. This may include the alignment of development techniques for example migration applications to a .net SOA approach from VB for new or existing systems.
The Data or Information Architect will be involved in the design of data structures within databases or other data repositories. Ensuring that corporate data is only held once in a structured, relational set of databases and called by different applications that need it as opposed to having multiple copies of similar data within databases that are solely used by their own application. Making changes to the address of a customer in ten different data locations is painful, unrewarding, an admin burden and pointless.
The Technology or Infrastructure Architect is responsible for designing the environments that securely and efficiently host the applications and the data. This will normally cover everything ‘under the hood’ from network topologies, security, backups, resilience/failover, storage to name but a few.
It is worth noting here that Architects are rarely the implementers of the designs. The implementers are the Business managers, the developers, the Database administrators and the network/server engineers. The Architects design and create the frameworks that the implementers will follow. In addition - a fact that often differentiates an Architect from an implementer, system or network engineer etc is that the Architect is rarely concerned about product selection. Technology - yes, Methodology - absolutely, but product x or product y - not really.
In summary, having a defined Enterprise Architecture allows your organisation a single view of where you are, where you want to be and what has to be done to get there.
In another Article, I will cover how the various architectures fit together and the benefits this provides.
Sequential Articles:
http:/A_2457.html
http:/A_2488.html
Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.
Comments (5)
Commented:
Nice work here.
I have several years experience in both the design and implementation phases and you have done a great job of presenting the information.
"Yes" vote above.
Author
Commented:Commented:
Commented:
Excellent article. Making this one required reading for my team.
Jason1178
Comment Architect
Author
Commented: