Aggregated enterprise architecture wisdom
The Open Group committee made a conscious choice to encourage customization of TOGAF, since every organizational context is unique. After all, TOGAF is a framework, not something you swallow whole to get well. If you look at the first BPMN sub-pr…
Enterprise Architecture (EA) organizations across the country have been hammered. As if the severe recession wasn’t enough, there are other reasons to account for this. Here are a few:EA organizations are notoriously unable to prove value.EA framewor…
Enterprise Analysis is a knowledge area which describes the Business analysis activities that take place for an enterprise to identify business opportunities, build a Business Architecture, determine the optimum project investment path for that enterprise and finally, implement new business and technical solutions. The question you may ask: Does this really differs from Enterprise Architecture, and if so, how?
At first sight, business opportunities are not always considered as being part of an Enterprise Architecture initiative, more as an activity which should be considered as an input. But let’s look at this in more detail.
Let’s look at this in more detail by way of mapping activities between BABOK v2* and the TOGAF 9 Framework*. The BABOK is the collection of knowledge within the profession of business analysis and reflects generally accepted practices. It describes business analysis areas of knowledge, their associated activities and tasks and the skills necessary to be effective in the execution:
|
BABOK v2 Knowledge Area Activity in Enterprise Analysis |
Definition | Enterprise Architecture (e.g TOGAF 9) | Differences, observations |
| Requirements Elicitation | This describes the interview and research process-how to best extract needs from stakeholders (and even how to recognize needs they don’t know they have).Elements such as metrics (tracking the amount of time spent eliciting requirements) and elicitation techniques (prototyping and brainstorming are just a couple) among the topics covered | Phase A: Architecture Vision is the initial phase of an architecture development cycle. It includes information about scope, the key steps, methods, information requirements and obtaining approval for the architecture development cycle to proceed |
Business scenarios are a useful technique to articulate an Architecture Vision. A Business Scenario describes, a business process, an application or set of applications enabled by the proposed solution , the business and technology environment, the people and computing components (called “actors”) who execute it, the desired outcome of proper execution To build such a Business Scenario, workshops with business users (stakeholders) would be organized |
|
Business Requirements Analysis |
This describes how to write/state requirements that will meet business needs. Key objectives include methods for prioritizing and organizing requirements, as well as the most beneficial techniques for requirements presentation (including state diagrams, prototyping, data flow diagrams, and process modeling, and more). Business Requirements for future project investments are identified and documented. They are defined at a high level, and include goals, objectives, and needs are identified |
Business Requirements are collected from business people during the Architecture Vision’s phase using the technique called Business Scenario (as mentioned above). That document identifies what will be the business solutions in generic terms |
The Enterprise Architects will define the Architecture Vision phase based on the goals, and objectives of the enterprise gathered from the business. There are two steps: 1. Business people will have defined the goals and the objectives of the enterprise independently from the Enterprise Architecture team 2. The Enterprise Architecture team which include business people gather the requirements based on the previous activity |
| Enterprise Analysis |
Begins after a Business executive team develops strategic plans and goals This outlines the crucial (and sometimes political) process of keeping everyone in the loop and on the same page regarding project’s direction and progress. This activity delves into such details as the requirements review and approval processes (including record-keeping). |
Most of these activities are taken into account in doing Enterprise Architecture or done directly by the Business executive team before starting an new Enterprise Architecture project | |
|
Strategic plan development |
Done outside of the Enterprise Architecture process by business people but is a key source of information | ||
|
Strategic goal development |
This is done outside of the Enterprise Architecture initiative by business people but is a key source of information | ||
| Business Architecture development | Done during Phase B:Business Architecture, looking at the baseline and target architecture, delivering a gap analysis, a plan and a roadmap | ||
|
Feasibility Studies |
Done during Phase A: Architecture Vision (with a Business Scenario) | ||
|
Business Case Development |
Done during Phase A: Architecture Vision (with a Business Scenario) | ||
|
New Project Proposal |
This is done in two steps: during the Phase A where we identify a Business solution and during Phase F: Migration Planning | ||
| Selecting and Prioritizing New Projects | This is done in two steps: during the Phase A where we identify a Business solution and during Phase F: Migration Planning | ||
| Business Opportunities | This is done during the Phase A: Architecture Vision and the Phase E: Opportunities and Solutions | ||
|
Launching New Projects |
This is done during Phase F: Migration Planning | ||
|
Managing Projects for Value |
This is done during Phase F: Migration Planning | ||
|
Tracking Project Benefits |
Once the project is in production, it is no longer part of the Enterprise Initiative | ||
| Solution Assessment and Validation | Details how to choose the best solutions for specific business needs (as well as assessing how well the chosen solution worked after its implementation).This should also cover risks, dependencies, and limitations that must be identified before proposing any solution |
Solutions are identified during Phase E.: Opportunities and Solutions. This phase is directly concerned with implementation, identifying major work packages to be undertaken and creating a migration strategy. Risk management, dependencies are taken into consideration. |
|
| Business Analysis Planning and Monitoring | Explains how to decide what you need to do to complete an “analyst effort” (in other words, how to plan a project). This helps intelligently decide which stakeholders, tools, tasks and techniques we will need to get the job done | Covered mostly in the Architecture Vision phase, then in the Business Architecture Phase | Stakeholder management techniques are used within TOGAF, tools and techniques are identified in the Business Architecture phase (modeling, reference models, viewpoints) |
| Requirements Management and Communication | Describes how to identify business needs (the why of the project; whereas requirements are the how) and state the scope of their solutions. This is a crucial piece of the analyst’s work. SMART criteria of measurement, SWOT analysis and other measurement factors that make identifying this root cause data objective and tangible are used | Business Requirements are collected with the business people during the Architecture Vision’s phase using the technique called Business Scenario (as mentioned above). |
SMART techniques are equally used. Communication plans are defined. |
This diagram below is a draft map BABOK® and TOGAF 9; more work is required!
Observations
There are obviously overlaps between Enterprise Analysis and Enterprise Architecture, but activities are not always done in the same sequence.
Enterprise Analysis complements Enterprise Architecture but also overlaps in some areas. Organization looking into Enterprise Architecture and specifically TOGAF 9 may consider adopting a Business Analysis framework such as BABOK and integrate them in the Preliminary Phase. If both approaches exist in a company, this would be a great opportunity for optimizing the alignment between Business and IT, and to run an Enterprise Architecture program from a complete business perspective.
About Business Analysis Body of Knowledge® (BABOK®)
The Business Analysis Body of Knowledge® (BABOK®) is the collection of knowledge within the profession of Business Analysis and reflects current generally accepted practices. As with other professions, the body of knowledge is defined and enhanced by the Business Analysis professionals who apply it in their daily work role. The BABOK® Guide describes Business Analysis areas of knowledge, their associated activities and the tasks and skills necessary to be effective in their execution. The BABOK® Guide is a reference for professional knowledge for Business Analysis and provides the basis for the Certified Business Analysis Professional™ (CBAP®) Certification.
BABOK® Guide 2.0 represents the development of a common framework to understand and define the practice of business analysis.
Enterprise Analysis is a knowledge area which describes the Business analysis activities that take place for an enterprise to identify business opportunities, build a Business Architecture, determine the optimum project investment path for that enterprise and finally, implement new business and technical solutions. The question you may ask: Does this really differs from Enterprise Architecture, and if so, how?
At first sight, business opportunities are not always considered as being part of an Enterprise Architecture initiative, more as an activity which should be considered as an input. But let’s look at this in more detail.
Let’s look at this in more detail by way of mapping activities between BABOK v2* and the TOGAF 9 Framework*. The BABOK is the collection of knowledge within the profession of business analysis and reflects generally accepted practices. It describes business analysis areas of knowledge, their associated activities and tasks and the skills necessary to be effective in the execution:
|
BABOK v2 Knowledge Area Activity in Enterprise Analysis |
Definition | Enterprise Architecture (e.g TOGAF 9) | Differences, observations |
| Requirements Elicitation | This describes the interview and research process-how to best extract needs from stakeholders (and even how to recognize needs they don’t know they have).Elements such as metrics (tracking the amount of time spent eliciting requirements) and elicitation techniques (prototyping and brainstorming are just a couple) among the topics covered | Phase A: Architecture Vision is the initial phase of an architecture development cycle. It includes information about scope, the key steps, methods, information requirements and obtaining approval for the architecture development cycle to proceed |
Business scenarios are a useful technique to articulate an Architecture Vision. A Business Scenario describes, a business process, an application or set of applications enabled by the proposed solution , the business and technology environment, the people and computing components (called “actors”) who execute it, the desired outcome of proper execution To build such a Business Scenario, workshops with business users (stakeholders) would be organized |
|
Business Requirements Analysis |
This describes how to write/state requirements that will meet business needs. Key objectives include methods for prioritizing and organizing requirements, as well as the most beneficial techniques for requirements presentation (including state diagrams, prototyping, data flow diagrams, and process modeling, and more). Business Requirements for future project investments are identified and documented. They are defined at a high level, and include goals, objectives, and needs are identified |
Business Requirements are collected from business people during the Architecture Vision’s phase using the technique called Business Scenario (as mentioned above). That document identifies what will be the business solutions in generic terms |
The Enterprise Architects will define the Architecture Vision phase based on the goals, and objectives of the enterprise gathered from the business. There are two steps: 1. Business people will have defined the goals and the objectives of the enterprise independently from the Enterprise Architecture team 2. The Enterprise Architecture team which include business people gather the requirements based on the previous activity |
| Enterprise Analysis |
Begins after a Business executive team develops strategic plans and goals This outlines the crucial (and sometimes political) process of keeping everyone in the loop and on the same page regarding project’s direction and progress. This activity delves into such details as the requirements review and approval processes (including record-keeping). |
Most of these activities are taken into account in doing Enterprise Architecture or done directly by the Business executive team before starting an new Enterprise Architecture project | |
|
Strategic plan development |
Done outside of the Enterprise Architecture process by business people but is a key source of information | ||
|
Strategic goal development |
This is done outside of the Enterprise Architecture initiative by business people but is a key source of information | ||
| Business Architecture development | Done during Phase B:Business Architecture, looking at the baseline and target architecture, delivering a gap analysis, a plan and a roadmap | ||
|
Feasibility Studies |
Done during Phase A: Architecture Vision (with a Business Scenario) | ||
|
Business Case Development |
Done during Phase A: Architecture Vision (with a Business Scenario) | ||
|
New Project Proposal |
This is done in two steps: during the Phase A where we identify a Business solution and during Phase F: Migration Planning | ||
| Selecting and Prioritizing New Projects | This is done in two steps: during the Phase A where we identify a Business solution and during Phase F: Migration Planning | ||
| Business Opportunities | This is done during the Phase A: Architecture Vision and the Phase E: Opportunities and Solutions | ||
|
Launching New Projects |
This is done during Phase F: Migration Planning | ||
|
Managing Projects for Value |
This is done during Phase F: Migration Planning | ||
|
Tracking Project Benefits |
Once the project is in production, it is no longer part of the Enterprise Initiative | ||
| Solution Assessment and Validation | Details how to choose the best solutions for specific business needs (as well as assessing how well the chosen solution worked after its implementation).This should also cover risks, dependencies, and limitations that must be identified before proposing any solution |
Solutions are identified during Phase E.: Opportunities and Solutions. This phase is directly concerned with implementation, identifying major work packages to be undertaken and creating a migration strategy. Risk management, dependencies are taken into consideration. |
|
| Business Analysis Planning and Monitoring | Explains how to decide what you need to do to complete an “analyst effort” (in other words, how to plan a project). This helps intelligently decide which stakeholders, tools, tasks and techniques we will need to get the job done | Covered mostly in the Architecture Vision phase, then in the Business Architecture Phase | Stakeholder management techniques are used within TOGAF, tools and techniques are identified in the Business Architecture phase (modeling, reference models, viewpoints) |
| Requirements Management and Communication | Describes how to identify business needs (the why of the project; whereas requirements are the how) and state the scope of their solutions. This is a crucial piece of the analyst’s work. SMART criteria of measurement, SWOT analysis and other measurement factors that make identifying this root cause data objective and tangible are used | Business Requirements are collected with the business people during the Architecture Vision’s phase using the technique called Business Scenario (as mentioned above). |
SMART techniques are equally used. Communication plans are defined. |
This diagram below is a draft map BABOK® and TOGAF 9; more work is required!
Observations
There are obviously overlaps between Enterprise Analysis and Enterprise Architecture, but activities are not always done in the same sequence.
Enterprise Analysis complements Enterprise Architecture but also overlaps in some areas. Organization looking into Enterprise Architecture and specifically TOGAF 9 may consider adopting a Business Analysis framework such as BABOK and integrate them in the Preliminary Phase. If both approaches exist in a company, this would be a great opportunity for optimizing the alignment between Business and IT, and to run an Enterprise Architecture program from a complete business perspective.
About Business Analysis Body of Knowledge® (BABOK®)
The Business Analysis Body of Knowledge® (BABOK®) is the collection of knowledge within the profession of Business Analysis and reflects current generally accepted practices. As with other professions, the body of knowledge is defined and enhanced by the Business Analysis professionals who apply it in their daily work role. The BABOK® Guide describes Business Analysis areas of knowledge, their associated activities and the tasks and skills necessary to be effective in their execution. The BABOK® Guide is a reference for professional knowledge for Business Analysis and provides the basis for the Certified Business Analysis Professional™ (CBAP®) Certification.
BABOK® Guide 2.0 represents the development of a common framework to understand and define the practice of business analysis.
Checkout following two plans below. And, contrast and compare them. Conceiving a coherent modernization plan and executing them has always been a challenge for OCIO. Enterprise Transition Plans generally documents the visions, goals, capabilities at th…
Programmed Cell Death is very important function to understand to gain insight into the way Transformation need to occur. When distortions occur in Enterprise Engineering, then this leads into obvious cancerous growth, which does not have easy remedy. …
Enterprise Architecture domains include Business Architecture which is the first architecture domain within TOGAF 9. An Enterprise Architecture program that includes this domain, maps critical business processes to their application, information, and infrastructure components to provide a comprehensive view of the business and IT landscape that enables informed decision-making.
Business Architects are supposed to manage Business Architecture, but who are they, what are their skills? How are they different to a Business Analyst or even a Project Manager?
Business Analysts are on the way to becoming Business Architects. Sometimes called IT Business Analysts, they are not strictly business or IT specialists. They write business cases (with very few technical terms), identify business requirements and often are part of a Development Team.
Based on many job descriptions and my observation below, is a grid of standard skills and responsibilities related to the function of a Business Analyst. In the second column, are the responsibilities also applicable to a Business Architect and in the last column comments on how TOGAF 9 recommend the activities to be addressed.
| Expected skills and activities | Business Analyst | Business Architect | Comments related to TOGAF 9 |
|---|---|---|---|
| Is an intermediary between IT and the business users, follows the implementation strategy with respect to getting stakeholder buy-in and support. | x | x | Both roles require to be positioned between IT and business. |
| In particular business processes of a line of business. | x | The Business Architect considers the organization’s strategy and less focused in a specific line of business. | |
| Acts as catalyst to implement strategic and tactical change for the business. | x | x | The Business Architect will focus more on strategic changes. |
| Works with end-user groups to assist with aligning IT to the department’s business goals. Conduct feasibility studies to define the purpose, functions, and overall structure of business processes | x | x | The Business Architect in TOGAF 9 will use Business Scenario techniques. |
| May be involved in Business Process Management (BPM). | x | x | |
| Performs analysis and documents business processes leading to process change and/or system implementation. | x | x | The Business Architect will model and process the business processes. |
| Operating as a more-or-less independent group that is focused on delivering BPM services | x | The Business Architect will be working at a strategic level and will be less focused on the delivery of BPM services. | |
| Does not have an IT background, but had, instead, a background in quality control. | x | The Business Architect must have a perfect knowledge of the business. | |
| Translates user requirements into software requirements that IT can then use to develop software | x | A Business Architect would not develop and review design specifications for software application. This would be the role of the Application Architect during Phase C. | |
| Analyze and resolve software errors in a timely and accurate fashion | x | A Business Architect is not in charge of managing incidents linked to applications. IT operations may escalate this to the Development Team, or the vendor. Once a first level of diagnostic done, it will be transferred to one of the architects depending on the domain (technology, application). | |
| Helps to develop and maintain software to support the business processes. Assist in developing system/application architecture. | x | The Business Architect does not contribute to software development. This is done by the Solution Architect. | |
| Leads and validates enterprise system designs across multiple business applications. | x | The Business Architect does not lead Application Architecture. This will be done by the Application Architect and potentially the Solution Architect. | |
| Creates and executes test plans to ensure that the functional and business requirements are met by the proposed solution | x | The Business Architect does not contribute to test plans. This is done probably by the Solution Architect. | |
| Documents and defines processes, eliminating activities that don’t add value and straightening out the flow of the activities. | x | x | In the TOGAF 9 Phase B we would do this by documenting the baseline and target architecture and do a gap analysis, identifying the various business architecture building blocks to be eliminated. |
| Determining how business policies are implemented in business rules. | x | x | Business rules have to be identified and implemented when business processes documented in both baseline and target architecture. Can be done at both strategic and tactical level. |
| Analyses customer needs and the processes customers go through to interact with an organization are key skills that any business process practitioner needs to be effective. | x | x | Business scenarios would be used to identify business requirements. |
| Creates, manages and maintains an optimum business architecture that includes informational, organizational, process, performance and systems architecture. | x | The Business Analyst focus more on projects delivery. The Business Architect is mostly focused on the delivery of the Business Architecture. | |
| Defines, socializes and implements Business Architecture. Reviews roadmap projects for impact and compliance. | x | Business Architecture roadmaps will be delivered from the gap analysis. | |
| Identifies and facilitates cross divisional continuous business improvement initiatives. | x | The Business Architect works at a strategic level and focus mostly on Strategic Architecture. | |
| Member of the Architecture Board, composed of representative process owners who approve any cross organizational business process changes. | x | Business Architects should be part of the Architecture Board. | |
| Identifies and maintains an up to date picture of opportunities and risks. | x | x | Risks have to be identified during both the Architecture vision phase and the development of the solution. |
| Experienced in business/process architecture including broad skills in the area of strategy mapping, business analysis skills, conceptual data and process modeling/design, EA frameworks. | x | The Business Architect must have these skills. The Business Analyst may focus on process modeling only. | |
| Strong work experience in Project and Change management. | x | x | Both roles require these skills. |
| Proven track record for working effectively with technical and business functions. | x | The Business Architect must work with other domain’s architects. |
My observations are:
Business Analysts are much closer to IT. They often are assigned to a specific Line of Business, which is close to the Development Team, and are implicated in software development. They may be part of the Development Team or the Project Management Office. The Business Architect reports to managers or senior managers who may be business or IT but are independent of any project. They have a global view on most business and will be responsible for modeling the business as a whole, then working top down to “architect” encompassing end to end business processes. Their role is more horizontal and is considered a neutral voice and because of that will make more critical decisions than a Business Analyst.
Business Analysts document requirements as defined by users during workshops. A Business Architect documents and may contribute to define a business strategy using requirements provided by the users if that strategy is not finalized. The Business Architect must have the ability to think in both a strategic and tactical manner whereas a Business Analyst is normally tactical.
The Business Analyst operates within the confines of a predetermined application and technology architecture. A Business Architect is a part of the decision making process to define the IT architecture (Data, Application and Technology). He will have a strong influence directing information technology to meet business needs, and assist in identifying business inefficiencies and opportunities.
Business Architect must be cognizant of enterprise strategies whereas a Business Analyst is normally concerned with specific projects independent of enterprise strategy.
Enterprise Architecture domains include Business Architecture which is the first architecture domain within TOGAF 9. An Enterprise Architecture program that includes this domain, maps critical business processes to their application, information, and infrastructure components to provide a comprehensive view of the business and IT landscape that enables informed decision-making.
Business Architects are supposed to manage Business Architecture, but who are they, what are their skills? How are they different to a Business Analyst or even a Project Manager?
Business Analysts are on the way to becoming Business Architects. Sometimes called IT Business Analysts, they are not strictly business or IT specialists. They write business cases (with very few technical terms), identify business requirements and often are part of a Development Team.
Based on many job descriptions and my observation below, is a grid of standard skills and responsibilities related to the function of a Business Analyst. In the second column, are the responsibilities also applicable to a Business Architect and in the last column comments on how TOGAF 9 recommend the activities to be addressed.
| Expected skills and activities | Business Analyst | Business Architect | Comments related to TOGAF 9 |
|---|---|---|---|
| Is an intermediary between IT and the business users, follows the implementation strategy with respect to getting stakeholder buy-in and support. | x | x | Both roles require to be positioned between IT and business. |
| In particular business processes of a line of business. | x | The Business Architect considers the organization’s strategy and less focused in a specific line of business. | |
| Acts as catalyst to implement strategic and tactical change for the business. | x | x | The Business Architect will focus more on strategic changes. |
| Works with end-user groups to assist with aligning IT to the department’s business goals. Conduct feasibility studies to define the purpose, functions, and overall structure of business processes | x | x | The Business Architect in TOGAF 9 will use Business Scenario techniques. |
| May be involved in Business Process Management (BPM). | x | x | |
| Performs analysis and documents business processes leading to process change and/or system implementation. | x | x | The Business Architect will model and process the business processes. |
| Operating as a more-or-less independent group that is focused on delivering BPM services | x | The Business Architect will be working at a strategic level and will be less focused on the delivery of BPM services. | |
| Does not have an IT background, but had, instead, a background in quality control. | x | The Business Architect must have a perfect knowledge of the business. | |
| Translates user requirements into software requirements that IT can then use to develop software | x | A Business Architect would not develop and review design specifications for software application. This would be the role of the Application Architect during Phase C. | |
| Analyze and resolve software errors in a timely and accurate fashion | x | A Business Architect is not in charge of managing incidents linked to applications. IT operations may escalate this to the Development Team, or the vendor. Once a first level of diagnostic done, it will be transferred to one of the architects depending on the domain (technology, application). | |
| Helps to develop and maintain software to support the business processes. Assist in developing system/application architecture. | x | The Business Architect does not contribute to software development. This is done by the Solution Architect. | |
| Leads and validates enterprise system designs across multiple business applications. | x | The Business Architect does not lead Application Architecture. This will be done by the Application Architect and potentially the Solution Architect. | |
| Creates and executes test plans to ensure that the functional and business requirements are met by the proposed solution | x | The Business Architect does not contribute to test plans. This is done probably by the Solution Architect. | |
| Documents and defines processes, eliminating activities that don’t add value and straightening out the flow of the activities. | x | x | In the TOGAF 9 Phase B we would do this by documenting the baseline and target architecture and do a gap analysis, identifying the various business architecture building blocks to be eliminated. |
| Determining how business policies are implemented in business rules. | x | x | Business rules have to be identified and implemented when business processes documented in both baseline and target architecture. Can be done at both strategic and tactical level. |
| Analyses customer needs and the processes customers go through to interact with an organization are key skills that any business process practitioner needs to be effective. | x | x | Business scenarios would be used to identify business requirements. |
| Creates, manages and maintains an optimum business architecture that includes informational, organizational, process, performance and systems architecture. | x | The Business Analyst focus more on projects delivery. The Business Architect is mostly focused on the delivery of the Business Architecture. | |
| Defines, socializes and implements Business Architecture. Reviews roadmap projects for impact and compliance. | x | Business Architecture roadmaps will be delivered from the gap analysis. | |
| Identifies and facilitates cross divisional continuous business improvement initiatives. | x | The Business Architect works at a strategic level and focus mostly on Strategic Architecture. | |
| Member of the Architecture Board, composed of representative process owners who approve any cross organizational business process changes. | x | Business Architects should be part of the Architecture Board. | |
| Identifies and maintains an up to date picture of opportunities and risks. | x | x | Risks have to be identified during both the Architecture vision phase and the development of the solution. |
| Experienced in business/process architecture including broad skills in the area of strategy mapping, business analysis skills, conceptual data and process modeling/design, EA frameworks. | x | The Business Architect must have these skills. The Business Analyst may focus on process modeling only. | |
| Strong work experience in Project and Change management. | x | x | Both roles require these skills. |
| Proven track record for working effectively with technical and business functions. | x | The Business Architect must work with other domain’s architects. |
My observations are:
Business Analysts are much closer to IT. They often are assigned to a specific Line of Business, which is close to the Development Team, and are implicated in software development. They may be part of the Development Team or the Project Management Office. The Business Architect reports to managers or senior managers who may be business or IT but are independent of any project. They have a global view on most business and will be responsible for modeling the business as a whole, then working top down to “architect” encompassing end to end business processes. Their role is more horizontal and is considered a neutral voice and because of that will make more critical decisions than a Business Analyst.
Business Analysts document requirements as defined by users during workshops. A Business Architect documents and may contribute to define a business strategy using requirements provided by the users if that strategy is not finalized. The Business Architect must have the ability to think in both a strategic and tactical manner whereas a Business Analyst is normally tactical.
The Business Analyst operates within the confines of a predetermined application and technology architecture. A Business Architect is a part of the decision making process to define the IT architecture (Data, Application and Technology). He will have a strong influence directing information technology to meet business needs, and assist in identifying business inefficiencies and opportunities.
Business Architect must be cognizant of enterprise strategies whereas a Business Analyst is normally concerned with specific projects independent of enterprise strategy.
In my previous article I describe the role of the Solution Architect within the TOGAF ADM, mostly acting between phases E to G, with a specific focus on E (Opportunities and Solutions) and F (Migration Planning). This article will cover the role in phase G: Implementation governance.
The objective of that phase is to formulate recommendations for each implementation project, and govern and manage an architecture contract covering the overall system implementation and deployment. In companies where the maturity is high, it would be perfectly acceptable to have the Solution Architect acting in the name of the Enterprise Architecture team and coordinate activities during the phase G.
► To govern and manage an Architecture Contract covering the overall implementation and deployment process (Source: TOGAF 9)
He identifies if there are any issues between the architecture and the implementation organization.
► To perform appropriate governance functions while the solution is being implemented and deployed (Source: TOGAF 9)
He will refer to existing governance best practices such as IT Service Management, Project Management, Risk Management, Security Management, and Audit management (for example).
► To ensure conformance with the defined architecture by implementation projects and other projects (Source: TOGAF 9)
He will Review ongoing implementation governance and architecture compliance for each building block.
► To ensure that the program of solutions is deployed successfully, as a planned program of work (Source: TOGAF 9)
He will Review ongoing implementation governance and architecture compliance for each building block.
► To ensure conformance of the deployed solution with the Target Architecture (Source: TOGAF 9)
He will support the architecture design review using a customized checklist as defined in TOGAF.
► To mobilize supporting operations that will underpin the future working lifetime of the deployed solution (Source: TOGAF 9)
The Solution Architect with the Enterprise Architecture team and the IT Operation Team:
This diagram is a high level representation of the Solution Architect’s activities interacting with all parties involved in the architecture development and delivery.
This approach where many activities are led by a designated Solution Architect. The alternative being to share the role between several architects from the Enterprise Architecture team.
In my previous article I describe the role of the Solution Architect within the TOGAF ADM, mostly acting between phases E to G, with a specific focus on E (Opportunities and Solutions) and F (Migration Planning). This article will cover the role in phase G: Implementation governance.
The objective of that phase is to formulate recommendations for each implementation project, and govern and manage an architecture contract covering the overall system implementation and deployment. In companies where the maturity is high, it would be perfectly acceptable to have the Solution Architect acting in the name of the Enterprise Architecture team and coordinate activities during the phase G.
► To govern and manage an Architecture Contract covering the overall implementation and deployment process (Source: TOGAF 9)
He identifies if there are any issues between the architecture and the implementation organization.
► To perform appropriate governance functions while the solution is being implemented and deployed (Source: TOGAF 9)
He will refer to existing governance best practices such as IT Service Management, Project Management, Risk Management, Security Management, and Audit management (for example).
► To ensure conformance with the defined architecture by implementation projects and other projects (Source: TOGAF 9)
He will Review ongoing implementation governance and architecture compliance for each building block.
► To ensure that the program of solutions is deployed successfully, as a planned program of work (Source: TOGAF 9)
He will Review ongoing implementation governance and architecture compliance for each building block.
► To ensure conformance of the deployed solution with the Target Architecture (Source: TOGAF 9)
He will support the architecture design review using a customized checklist as defined in TOGAF.
► To mobilize supporting operations that will underpin the future working lifetime of the deployed solution (Source: TOGAF 9)
The Solution Architect with the Enterprise Architecture team and the IT Operation Team:
This diagram is a high level representation of the Solution Architect’s activities interacting with all parties involved in the architecture development and delivery.
This approach where many activities are led by a designated Solution Architect. The alternative being to share the role between several architects from the Enterprise Architecture team.
Quite often people wonder where a Solution Architect fits within the TOGAF Framework and it is not obvious that there is a single answer. I suggest we look first at a generic profile for a Solution Architect.
Companies such as Oracle, Cisco, SAP and others have roles called Solution Architect but with little apparent agreement to what that role is.
Some commonalities between various skills are:
Building Block – A (potentially re-usable) component of business, IT or architectural capability
o A constituent of the architecture model that describes a single aspect of the overall model
o Describe required capability
o Shape the specification of SBBs
o Represents components that will be used to implement the required capability
o A candidate physical solution for an Architecture Building Block (ABB); e.g., a Commercial Off-The-Shelf (COTS) package that is a component of the Acquirer view of the architecture
All ABBs will be stored in the Architecture Landscape of the Architecture Repository. These ABBs will have different levels of granularity to suit different architectural objectives.
The Architecture Definition Document which describes an architecture will contain all artifacts describing as views the building blocks.
During the Phase E, Opportunities and Solutions, we identify work packages and group them into projects, consolidate the gap analysis results from phases B to D, identify the building blocks to be developed or acquired reusing the existing ones (stored in the Architecture Repository) as much as we can. From there, we identify the SBBs which could potentially address one or more gaps and their associated ABBs. Existing SBBs have obviously also to be considered taking the interoperability requirements and dependencies into consideration.
The Solution Architect has a key role in this phase as (s)he will probably be the best qualified to identify the appropriate SBBs. He or she participates in the definition of any Transition Architectures, identifies potential solutions, and helps to formulate a high-level implementation and migration strategy.
During the Migration Planning phase they also have an important mission to ensure that SBBs are properly designed or that acquired solutions support business requirements. The Solution Architect may work closely with the vendor if a COTS solution is considered. A solution includes the hardware, software, and supporting people and documentation to solve a problem.
“The gaps in the existing enterprise solutions framework need to be identified and the specific Solution Building Blocks (SBBs) required to fill these gaps will be the identified by the solutions architects. These SBBs may have a one-to-one or many-to-one relationship with the projects. The solutions architects need to define exactly how this will be done. There may be other projects working on these same capabilities and the solutions architects need to ensure that they can leverage best value from these investments.”
Source: TOGAF 9 (15.4.1)
When the Implementation Governance phase is started, the Solution Architect will work in partnership with the procurer/acquirer in addition to the development team and/or the vendor. He will ensure that the development will comply with the target architecture.
When the solution building blocks are developed or integrated with other existing solutions, the Solution Architect will be working with the development team. His role will be to contribute to the design, development, integration and testing of the new components. This may be considered as being the Solution Architecture activity.
A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high level business and/or IT system specifications and a portfolio of implementation tasks.
Solution architecture starts with an understanding of the problem, which should be documented in the business scenario, and this is where so many projects fail. Too many people have the idea that solving a problem is all about coding.
The Solution Architect is a member of the Enterprise Architecture team but becomes at a later stage also a member of the Development team. His role is mixed; he is the bridge between concepts and implementation. However, the Solution Architect does not operate at the Strategic Architecture level (at the level of the Enterprise) but mostly at Segment and Capability Architecture levels.
“The Solution Architect has the responsibility for architectural design and documentation
at a system or subsystem level, such as management or security. A Solution Architect may shield the Enterprise/Segment Architect from the unnecessary details of the systems, products, and/or technologies. The focus of the Solution Architect is on system technology solutions; for example, a component of a solution such as enterprise data warehousing.”
Source TOGAF9 (52.6.3)
There is no mapping for a Solution Architect in the TOGAF Skills Framework, but I would suggest, based on my experience, the following proficiency levels:
TOGAF proficiency levels:
Source TOGAF9 (52.4.4)
This approach is related to the current situation in the market for Solutions Architects, where we see that most of their activities are limited to phases E to G. Another approach would be to consider a Solution Architect being involved in all phases of the TOGAF ADM from phase A and on-wards. A follow-up paper will describe how to address solutions from Phase A , when constraints exist, defining the role and responsibilities of a Solution Architect.
Quite often people wonder where a Solution Architect fits within the TOGAF Framework and it is not obvious that there is a single answer. I suggest we look first at a generic profile for a Solution Architect.
Companies such as Oracle, Cisco, SAP and others have roles called Solution Architect but with little apparent agreement to what that role is.
Some commonalities between various skills are:
Building Block – A (potentially re-usable) component of business, IT or architectural capability
o A constituent of the architecture model that describes a single aspect of the overall model
o Describe required capability
o Shape the specification of SBBs
o Represents components that will be used to implement the required capability
o A candidate physical solution for an Architecture Building Block (ABB); e.g., a Commercial Off-The-Shelf (COTS) package that is a component of the Acquirer view of the architecture
All ABBs will be stored in the Architecture Landscape of the Architecture Repository. These ABBs will have different levels of granularity to suit different architectural objectives.
The Architecture Definition Document which describes an architecture will contain all artifacts describing as views the building blocks.
During the Phase E, Opportunities and Solutions, we identify work packages and group them into projects, consolidate the gap analysis results from phases B to D, identify the building blocks to be developed or acquired reusing the existing ones (stored in the Architecture Repository) as much as we can. From there, we identify the SBBs which could potentially address one or more gaps and their associated ABBs. Existing SBBs have obviously also to be considered taking the interoperability requirements and dependencies into consideration.
The Solution Architect has a key role in this phase as (s)he will probably be the best qualified to identify the appropriate SBBs. He or she participates in the definition of any Transition Architectures, identifies potential solutions, and helps to formulate a high-level implementation and migration strategy.
During the Migration Planning phase they also have an important mission to ensure that SBBs are properly designed or that acquired solutions support business requirements. The Solution Architect may work closely with the vendor if a COTS solution is considered. A solution includes the hardware, software, and supporting people and documentation to solve a problem.
“The gaps in the existing enterprise solutions framework need to be identified and the specific Solution Building Blocks (SBBs) required to fill these gaps will be the identified by the solutions architects. These SBBs may have a one-to-one or many-to-one relationship with the projects. The solutions architects need to define exactly how this will be done. There may be other projects working on these same capabilities and the solutions architects need to ensure that they can leverage best value from these investments.”
Source: TOGAF 9 (15.4.1)
When the Implementation Governance phase is started, the Solution Architect will work in partnership with the procurer/acquirer in addition to the development team and/or the vendor. He will ensure that the development will comply with the target architecture.
When the solution building blocks are developed or integrated with other existing solutions, the Solution Architect will be working with the development team. His role will be to contribute to the design, development, integration and testing of the new components. This may be considered as being the Solution Architecture activity.
A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high level business and/or IT system specifications and a portfolio of implementation tasks.
Solution architecture starts with an understanding of the problem, which should be documented in the business scenario, and this is where so many projects fail. Too many people have the idea that solving a problem is all about coding.
The Solution Architect is a member of the Enterprise Architecture team but becomes at a later stage also a member of the Development team. His role is mixed; he is the bridge between concepts and implementation. However, the Solution Architect does not operate at the Strategic Architecture level (at the level of the Enterprise) but mostly at Segment and Capability Architecture levels.
“The Solution Architect has the responsibility for architectural design and documentation
at a system or subsystem level, such as management or security. A Solution Architect may shield the Enterprise/Segment Architect from the unnecessary details of the systems, products, and/or technologies. The focus of the Solution Architect is on system technology solutions; for example, a component of a solution such as enterprise data warehousing.”
Source TOGAF9 (52.6.3)
There is no mapping for a Solution Architect in the TOGAF Skills Framework, but I would suggest, based on my experience, the following proficiency levels:
TOGAF proficiency levels:
Source TOGAF9 (52.4.4)
This approach is related to the current situation in the market for Solutions Architects, where we see that most of their activities are limited to phases E to G. Another approach would be to consider a Solution Architect being involved in all phases of the TOGAF ADM from phase A and on-wards. A follow-up paper will describe how to address solutions from Phase A , when constraints exist, defining the role and responsibilities of a Solution Architect.