Enterprise Architecture – The Enterprise Architect at work
Published:
Browse All Articles > Enterprise Architecture – The Enterprise Architect at work
Enterprise Architecture – The Enterprise Architect at work
The purpose of this set of articles is to present my own view on Enterprise Architecture (EA), the roles of the Enterprise Architect and the discipline Architects, what EA does, what EA means and why you should know this – or sections of it - already..... This information is freely available.
Please note that I am using a full-scale organisation to emphasize my points. You do NOT have to start this big. Many new entrants into this field start with a much smaller group such as their own department or do not do an Enterprise model at all and just create relationship models. Whatever works for you but the principles are the same.
This particular article follows on from ‘What is Enterprise Architecture?’ found here:
http:/A_2448.html
And from ‘Enterprise Architecture – The Organisation Business Plan’ found here:
http:/A_2457.html
So what do we have so far? The top brass have had their week away deliberating, have decided what needs to be done as a business or organisation and communicated this to the world via a Corporate, Organisation or Business level plan – superb. Part of what allowed such a document to be created – and rewritten more times than anyone will want to think about – is the involvement of the Enterprise Architect or someone who is fulfilling that role but maybe with a different job title.
My favourite reference book is still the ‘Enterprise Architecture Good Practices Guide’ by Jaap Schekkerman. You may want to read it as this is where I get much of my inspiration from.
Firstly, there are myriad Enterprise Architecture methodologies and to be blunt, the likelihood of you picking one and it doing exactly what you want ‘out of the box’ is likely zero. Personally I am certified as a TOGAF practitioner (The Open Group Architecture Framework http://www.opengroup.org/togaf/) but it is called a framework for a reason. Like all frameworks, it is a set of standards and guidelines that can (should) be adapted to meet your needs. The Enterprise Architect drives these adaptations based upon the organisations requirements, so selecting the right framework, or at least a reasonable match to start off with, is key.
Secondly, the EA will want to begin populating the EA Framework with information that he/she has available. This is where the hard work comes in because a lot of this information will be in hidden documents such as those that are not normally distributed; may be in obscure documents concerning other topics and located in paragraph 3 on page 450 of 500; or may not exist at all and it is down to the EA to ask the necessary questions. Be clear here – the Architect does not create the information at this level; what the Enterprise Architect does is to pull it all together into the correct places within the framework and translating the information into something that can be clearly and concisely communicated back to the organisation. The Enterprise Architect will want to articulate their findings and get them validated by the appropriate personnel within the organisation to ensure their accuracy.
Thirdly, completion of the above allows both the business and the Enterprise Architect to identify gaps in the framework and for people to be tasked with either supplying or creating the information/documentation necessary to complete it. The intention here is to capture a complete representation of the organisation (the Enterprise) as it stands currently. Once captured fully at the Enterprise level all of the nice fancy statements that the Chairman has made, all the glib promises that the Sales Director has made, all the rash promises that the Finance Director has made will one day in the future be analysed and converted into logical statements with measurable, achievable outcomes and each will be aligned to the organisation business strategies.
Fourthly, we can move down to what I call the Discipline Architects level (generically called the Domain Architects and no, this is absolutely nothing to do with Microsoft Windows before you ask); this is where the fun stuff – for me - starts.
The four domains are:
Business Architecture
Applications Architecture
Data or Information Architecture
Technology or Infrastructure Architecture
Remember, these are MY views and you may have your own. I will go into each of these architecture domains in detail within future articles.
The Business Architecture is the whole process encapsulating how the business approaches delivering against the vision, the mission statements, the business strategies, the goals and objectives that the organisation is striving to achieve. How it carries out its business, what legislation may drive how it conducts itself, how it involves and interacts with its internal and external stakeholders and its customers. What business processes have been created, documented and implemented in order for the business to carry out its functions? Each business process should be aligned to a business function which, in turn, is aligned to a business strategy, the completion of which is aligned to the business goals, objectives and mission statements. Let’s face it; carrying out a business function that is at odds with the business strategy is not going to go down well at all....
The Business Architect will be continually reviewing all of these areas ensuring that the business processes are not duplicated, are streamlined, are resource and cost effective, accurately reflect the task being carried out and are efficient.
The Business Architect will also track the relationships – a crucial aspect of architecture – between each business process and the business function it supports. For example, a business process may have sub-processes, it will definitely have an owner, and there may be a budget for the process, a review date, service level agreements that it has to meet. Dependencies may exist between business processes that need to be recorded. For example, if the business changed business process number 4, what happens to business process numbers three and five? If changes are made to a process, who are the interested stakeholders? Who needs to be notified/consulted before a change is made? Are there thresholds associated with these processes?
The Business Architect will also set the rules and guidelines upon which business processes will be created, maintained and monitored.
All of this information is brought into the Enterprise Architecture framework/model.
The application Architecture revolves around the application portfolio. These are applications that support and help deliver the business processes and business functions allowing the business/organisation to achieve its objectives and goals in line with its strategies.
The Application Architect will be reviewing the applications within the Enterprise to ensure that they are effectively carrying out their tasks.
The Applications Architect will design and publish the rules and guidelines upon which new developments or COTS (Commercial Off The Shelf) will be baselined against. A good example of a rule would be that all delivered code must be in a reusable form; a good guideline might be that a web service will always be the preferred development approach if there are multiple ways of designing a new application.
The Applications Architect will also track relationships. Each application will have a relationship with one or more business processes, will have service level agreements, SLA’s, review dates when the application is no longer supportable, support agreement schedules, budgets, planned updates, restore/backup plans, business continuity/disaster recovery priorities, source-safe/Team foundation Server repositories etc.
All of this information is brought into the Enterprise Architecture framework/model.
The same is the case for the information/data architecture and the technology/infrastructure architecture. Every aspect will have inter-relationships that need to be recorded with associated metadata and key information. The Data or Information Architect probably has one of the most important roles and is often the least understood or utilised. Understanding how the organisation data is stored, what standards have been used (four lines of address in a database or five? Is the country-code entered in to the databases consistently GB or UK? Simple examples but oh so representative). I think you get my point........
It goes without saying by now that all of this information is also brought into the Enterprise Architecture framework/model
Now – if you think that was heavy going, think about all of the other relationships that will exist when you look across domain architectures as well.
Each application has a relationship with one or more data sources, therefore those data sources also have a relationship with the business process that the application is supporting. Each application is hosted on technology whether it is a virtual or physical server and therefore that infrastructure has a relationship with that data, that application and the business process it supports.
By the time you have recorded all of the entities (or artifacts as we call them) within the Enterprise it will look like a ball of string has been unwound and simply dumped on your great diagrams and documents because there will be links going to and from everywhere – at least, that is what it will seem like. Think how convoluted it gets if the organisation is made up of multiple, smaller business units!!
In truth this is stage one of three and is often the hardest one to accomplish. It provides the ‘As is’ state. What you now have is a plethora of information – the ideal is that you have captured all of this either in an indexed relational database or better still an Enterprise Architecture modeling tool – within which you can search for information.
If you want to get to point B then you HAVE to know where you are starting from.
Armed with the ‘as is’ Enterprise Architecture model and the organisation business plan, you now know where you are starting from and have the raw tools to start thinking about the ‘to be’ or the ‘where we want to get to’ position – and dreaming about the GAP analysis model that will eventually be identified.
What you also have is a complete representation of the organisation, a single view of the truth, documentation that EVERYONE will now use as the master index, a means to advise on almost anything from which applications use vb.net through to questions such as 'I want to upgrade this sql database server from SQL7 to SQL2005, who do I need to collaborate with?'
Anyway, enough for now – more to come on extrapolating out the business plan and creating the ‘to be’ model in the next article.
The purpose of this set of articles is to present my own view on Enterprise Architecture (EA), the roles of the Enterprise Architect and the discipline Architects, what EA does, what EA means and why you should know this – or sections of it - already..... This information is freely available.
Please note that I am using a full-scale organisation to emphasize my points. You do NOT have to start this big. Many new entrants into this field start with a much smaller group such as their own department or do not do an Enterprise model at all and just create relationship models. Whatever works for you but the principles are the same.
This particular article follows on from ‘What is Enterprise Architecture?’ found here:
http:/A_2448.html
And from ‘Enterprise Architecture – The Organisation Business Plan’ found here:
http:/A_2457.html
So what do we have so far? The top brass have had their week away deliberating, have decided what needs to be done as a business or organisation and communicated this to the world via a Corporate, Organisation or Business level plan – superb. Part of what allowed such a document to be created – and rewritten more times than anyone will want to think about – is the involvement of the Enterprise Architect or someone who is fulfilling that role but maybe with a different job title.
My favourite reference book is still the ‘Enterprise Architecture Good Practices Guide’ by Jaap Schekkerman. You may want to read it as this is where I get much of my inspiration from.
Firstly, there are myriad Enterprise Architecture methodologies and to be blunt, the likelihood of you picking one and it doing exactly what you want ‘out of the box’ is likely zero. Personally I am certified as a TOGAF practitioner (The Open Group Architecture Framework http://www.opengroup.org/togaf/) but it is called a framework for a reason. Like all frameworks, it is a set of standards and guidelines that can (should) be adapted to meet your needs. The Enterprise Architect drives these adaptations based upon the organisations requirements, so selecting the right framework, or at least a reasonable match to start off with, is key.
Secondly, the EA will want to begin populating the EA Framework with information that he/she has available. This is where the hard work comes in because a lot of this information will be in hidden documents such as those that are not normally distributed; may be in obscure documents concerning other topics and located in paragraph 3 on page 450 of 500; or may not exist at all and it is down to the EA to ask the necessary questions. Be clear here – the Architect does not create the information at this level; what the Enterprise Architect does is to pull it all together into the correct places within the framework and translating the information into something that can be clearly and concisely communicated back to the organisation. The Enterprise Architect will want to articulate their findings and get them validated by the appropriate personnel within the organisation to ensure their accuracy.
Thirdly, completion of the above allows both the business and the Enterprise Architect to identify gaps in the framework and for people to be tasked with either supplying or creating the information/documentation necessary to complete it. The intention here is to capture a complete representation of the organisation (the Enterprise) as it stands currently. Once captured fully at the Enterprise level all of the nice fancy statements that the Chairman has made, all the glib promises that the Sales Director has made, all the rash promises that the Finance Director has made will one day in the future be analysed and converted into logical statements with measurable, achievable outcomes and each will be aligned to the organisation business strategies.
Fourthly, we can move down to what I call the Discipline Architects level (generically called the Domain Architects and no, this is absolutely nothing to do with Microsoft Windows before you ask); this is where the fun stuff – for me - starts.
The four domains are:
Business Architecture
Applications Architecture
Data or Information Architecture
Technology or Infrastructure Architecture
Remember, these are MY views and you may have your own. I will go into each of these architecture domains in detail within future articles.
The Business Architecture is the whole process encapsulating how the business approaches delivering against the vision, the mission statements, the business strategies, the goals and objectives that the organisation is striving to achieve. How it carries out its business, what legislation may drive how it conducts itself, how it involves and interacts with its internal and external stakeholders and its customers. What business processes have been created, documented and implemented in order for the business to carry out its functions? Each business process should be aligned to a business function which, in turn, is aligned to a business strategy, the completion of which is aligned to the business goals, objectives and mission statements. Let’s face it; carrying out a business function that is at odds with the business strategy is not going to go down well at all....
The Business Architect will be continually reviewing all of these areas ensuring that the business processes are not duplicated, are streamlined, are resource and cost effective, accurately reflect the task being carried out and are efficient.
The Business Architect will also track the relationships – a crucial aspect of architecture – between each business process and the business function it supports. For example, a business process may have sub-processes, it will definitely have an owner, and there may be a budget for the process, a review date, service level agreements that it has to meet. Dependencies may exist between business processes that need to be recorded. For example, if the business changed business process number 4, what happens to business process numbers three and five? If changes are made to a process, who are the interested stakeholders? Who needs to be notified/consulted before a change is made? Are there thresholds associated with these processes?
The Business Architect will also set the rules and guidelines upon which business processes will be created, maintained and monitored.
All of this information is brought into the Enterprise Architecture framework/model.
The application Architecture revolves around the application portfolio. These are applications that support and help deliver the business processes and business functions allowing the business/organisation to achieve its objectives and goals in line with its strategies.
The Application Architect will be reviewing the applications within the Enterprise to ensure that they are effectively carrying out their tasks.
The Applications Architect will design and publish the rules and guidelines upon which new developments or COTS (Commercial Off The Shelf) will be baselined against. A good example of a rule would be that all delivered code must be in a reusable form; a good guideline might be that a web service will always be the preferred development approach if there are multiple ways of designing a new application.
The Applications Architect will also track relationships. Each application will have a relationship with one or more business processes, will have service level agreements, SLA’s, review dates when the application is no longer supportable, support agreement schedules, budgets, planned updates, restore/backup plans, business continuity/disaster recovery priorities, source-safe/Team foundation Server repositories etc.
All of this information is brought into the Enterprise Architecture framework/model.
The same is the case for the information/data architecture and the technology/infrastructure architecture. Every aspect will have inter-relationships that need to be recorded with associated metadata and key information. The Data or Information Architect probably has one of the most important roles and is often the least understood or utilised. Understanding how the organisation data is stored, what standards have been used (four lines of address in a database or five? Is the country-code entered in to the databases consistently GB or UK? Simple examples but oh so representative). I think you get my point........
It goes without saying by now that all of this information is also brought into the Enterprise Architecture framework/model
Now – if you think that was heavy going, think about all of the other relationships that will exist when you look across domain architectures as well.
Each application has a relationship with one or more data sources, therefore those data sources also have a relationship with the business process that the application is supporting. Each application is hosted on technology whether it is a virtual or physical server and therefore that infrastructure has a relationship with that data, that application and the business process it supports.
By the time you have recorded all of the entities (or artifacts as we call them) within the Enterprise it will look like a ball of string has been unwound and simply dumped on your great diagrams and documents because there will be links going to and from everywhere – at least, that is what it will seem like. Think how convoluted it gets if the organisation is made up of multiple, smaller business units!!
In truth this is stage one of three and is often the hardest one to accomplish. It provides the ‘As is’ state. What you now have is a plethora of information – the ideal is that you have captured all of this either in an indexed relational database or better still an Enterprise Architecture modeling tool – within which you can search for information.
If you want to get to point B then you HAVE to know where you are starting from.
Armed with the ‘as is’ Enterprise Architecture model and the organisation business plan, you now know where you are starting from and have the raw tools to start thinking about the ‘to be’ or the ‘where we want to get to’ position – and dreaming about the GAP analysis model that will eventually be identified.
What you also have is a complete representation of the organisation, a single view of the truth, documentation that EVERYONE will now use as the master index, a means to advise on almost anything from which applications use vb.net through to questions such as 'I want to upgrade this sql database server from SQL7 to SQL2005, who do I need to collaborate with?'
Anyway, enough for now – more to come on extrapolating out the business plan and creating the ‘to be’ model in the next article.
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 (1)
Commented:
This is a very solid series, put together from real world experience.
I spent a lot of time on the 'Architecture' side of the IT world and I wish I'd had a roadmap such as this back then.
Thanks for continuing these.
"Yes" vote above.