9 years, 4 months ago

Socially enabled BPM

All content written by and copyrighted by Todd Biske. If you are reading this on a site other than my “Outside the Box” blog, it’s probably being republished without my permission. Please consider reading it at the source. A succession of tweets between Forrester’s Gene Leganza and Clay Richardson along with Brenda Michelson of Elemental […]

9 years, 4 months ago

OTN Podcast on EA Communication

All content written by and copyrighted by Todd Biske. If you are reading this on a site other than my “Outside the Box” blog, it’s probably being republished without my permission. Please consider reading it at the source. I participated on a panel discussion on communication and enterprise architecture, hosted by Bob Rhubart of Oracle. […]

9 years, 9 months ago

Enterprise Architecture, TOGAF and Solution Architects

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:

· Strategic business acumen (understand business requirements and strategy)
· Technical analysis
· Broad and deep technical knowledge
· Technical leadership (the trusted, technical advisor for assigned line of business, providing thought leadership and application of technology to business problems)
· Data Architect
· Shapes the evolution of company’s products
· Maps product requirements and business problems to re-usable end-to-end technology solutions
· Uses methodologies and frameworks (using best practices and common patterns, including database, component layers, user interfaces, web services, and integration patterns)
· Builds and deploys new functionality and extend applications (driving the development of those solutions by guiding and mentoring the development team through the entire development process. Some development will be required for shared services and components or technically challenging areas where the skills of an architect are needed).
· Software architect (must understand and contribute to all levels of design needed for the solution (business, data, application, technology))
· Deep experience developing enterprise solutions using all aspects of the .NET platform, open source or Java (or any other environment), Web Services, multithreaded programming, designing and building frameworks, enterprise patterns, SQL design and development, and database tuning
· Coder (build and code prototypes and frameworks)
· Hands-on experience
· Performance and load testing, development tools
· Works with major lines of business and IT Development teams
· Is a member of the Enterprise Architecture team
· Documents solution designs and how they interact with the larger Enterprise Architecture
Now looking at TOGAF, we need to consider a few definitions such as the Architecture Building Blocks (ABBs) and the Solutions Building Blocks (SBBs).

Building Block – A (potentially re-usable) component of business, IT or architectural capability

  • Architecture Building Block (ABB)

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

  • Solutions Building Block (SBB)

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.

9 years, 9 months ago

Enterprise Architecture, TOGAF and Solution Architects

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:

· Strategic business acumen (understand business requirements and strategy)
· Technical analysis
· Broad and deep technical knowledge
· Technical leadership (the trusted, technical advisor for assigned line of business, providing thought leadership and application of technology to business problems)
· Data Architect
· Shapes the evolution of company’s products
· Maps product requirements and business problems to re-usable end-to-end technology solutions
· Uses methodologies and frameworks (using best practices and common patterns, including database, component layers, user interfaces, web services, and integration patterns)
· Builds and deploys new functionality and extend applications (driving the development of those solutions by guiding and mentoring the development team through the entire development process. Some development will be required for shared services and components or technically challenging areas where the skills of an architect are needed).
· Software architect (must understand and contribute to all levels of design needed for the solution (business, data, application, technology))
· Deep experience developing enterprise solutions using all aspects of the .NET platform, open source or Java (or any other environment), Web Services, multithreaded programming, designing and building frameworks, enterprise patterns, SQL design and development, and database tuning
· Coder (build and code prototypes and frameworks)
· Hands-on experience
· Performance and load testing, development tools
· Works with major lines of business and IT Development teams
· Is a member of the Enterprise Architecture team
· Documents solution designs and how they interact with the larger Enterprise Architecture
Now looking at TOGAF, we need to consider a few definitions such as the Architecture Building Blocks (ABBs) and the Solutions Building Blocks (SBBs).

Building Block – A (potentially re-usable) component of business, IT or architectural capability

  • Architecture Building Block (ABB)

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

  • Solutions Building Block (SBB)

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.

9 years, 11 months ago

Development of an Enterprise Architecture Communication Plan

As a strategic activity for IT, communication is important for the effective management of both internal and external relationships. The IT function in many organizations operates with highly diverse stakeholders from different parts of the world. The situation has evolved rapidly over the last years through (standardization, globalization, and optimization…).

Communication significantly impacts how IT is perceived by the organization, and therefore it plays a crucial role in the successful positioning of IT as an internal partner. Moreover, given the competitive market pressure the position of IT within the company is the same that of an external IT provider. Hence the same level of professionalism in terms of quality and efficiency are demanded.

Communication concerns all business and IT employees whether they are managers, staff assigned to communication roles, or IT employees with technical tasks. Internally, multinational companies and global departments demand excellent communication and intercultural skills from employees and managers. This philosophy holds true for the field of IT. Smooth working processes and good performance are dependent on effective communications, especially in periods of change.

Effective communication is part of the overall plan for management of an Enterprise Architecture Program. An Enterprise Architecture communication document has to identify stakeholders of the organization’s Enterprise Architecture Program, the information needs of those stakeholders, and the communication strategy to be followed by the program in meeting those needs.

The goals of the Architecture Board, as established by (usually) the organization’s Management Committee’s mission and charter, requires a successful communication strategy. The Enterprise Architecture and the operations of the program charged with evolving that architecture are important topics that must be communicated by the program if the Enterprise Architecture initiative is to succeed.

The plan consists of sections devoted to an identified stakeholder group (you may reuse the stakeholders management defined in TOGAF). Within each section, the plan would identify:

  • The members of the stakeholder group
  • The TOGAF Enterprise Architecture Framework role(s) to which the stakeholder group maps
  • The information needs of the stakeholder group defined in the Architecture Vision The communication strategy to be followed by the program in meeting the information needs of the stakeholder group

This plan should be a living document, and as such should be updated on a regular basis to reflect new stakeholder groups, new information needs, and new communication strategies. It is important that the Enterprise Architecture Program be held accountable for implementation of this plan, and that the Architecture Board regularly reviews progress with the Program Director.

Stakeholder General Communication

Stakeholders are people who have key roles in, or concerns about, the system. Different stakeholders with different roles in the system will have different concerns. Stakeholders can be individuals, teams, or organizations (or classes thereof).

The list of stakeholders can be also based on the existing Business and IT organization and structure. It also takes into consideration recommendation from HR department addressing the various ways of communicating to various groups of people.

The various stakeholders may include (examples):

– Executive Management Board
– C-levels
– Business Users Advisory Board
– Business Units
– Procurement
– Architecture Board
– IT Units
– Enterprise Architecture team
– Customers
– Developers

The communication plan should take into consideration all groups (use best practices from EA frameworks such as TOGAF), the IT organization and the HR recommendations.

These groups will have to be clearly defined as probably some of the communication tools and techniques will have to be tailored for each community.

General Information Needs

The following information needs to be applied to all stakeholders.

  1. Understand what Enterprise Architecture is (at least at a high level)
  2. Understand the value, benefits, and importance of Enterprise Architecture to the business.
  3. Understand how the Architecture Board and Enterprise Architecture Program are contributing to the pursuit of the organization’s business objectives.

General Communication Tools

To meet these general information needs, the Enterprise Architecture Program should implement the following communications tools.

  1. A set of basic information materials describing the scope of the Enterprise Architecture. This set of materials will describe the value, benefits, and importance of Enterprise Architecture. The materials will be brief and concise, and may consist of: one-page briefing or brochure, key concept map, Frequently-Asked Questions (FAQ) document, position paper, and a presentation.
  2. In all status reporting, Committee and Program achievements will be explicitly linked to the organization’s business objectives.
  3. The basic Enterprise Architecture scope and value materials, as well as some high-level business-oriented status information, will be available (and prominently displayed) on the Enterprise Architecture website. These materials should be suitable for use/delivery by Architecture Board members as well as program staff. (The use of systems such as a CMS (Content Management System)would allow delivering information based on roles.)

Communication Matrix

A matrix should then be built which associates the various communication tools to the various stakeholders (see example below)

This matrix associates the communication tools to the various stakeholders. Each stakeholder, communication tool should then be described in that document and be related to various steps of the Enterprise Architecture governance.

The various views will also have to be defined in annexes.

Communication Planning

A Communication planning will have to be defined (see example below).

Implementation steps

To implement such a communication plan, the following steps will have to be completed:

  1. Validate if all stakeholders have been taken into consideration
  2. Define the content of each communication tool (reports, newsletters, verbal communication, etc.)
  3. Ensure that the appropriated communication tools are associated to the right stakeholders
  4. Implement the Communication Plan with the Business and the IT Department
  5. Once all communication tools are formalized and approved, identify the Business Units and roll out the communication plan to these stakeholders
  6. Once on board, roll out the communication plan to the Executive Management Board and C-levels
9 years, 11 months ago

Development of an Enterprise Architecture Communication Plan

As a strategic activity for IT, communication is important for the effective management of both internal and external relationships. The IT function in many organizations operates with highly diverse stakeholders from different parts of the world. The situation has evolved rapidly over the last years through (standardization, globalization, and optimization…).

Communication significantly impacts how IT is perceived by the organization, and therefore it plays a crucial role in the successful positioning of IT as an internal partner. Moreover, given the competitive market pressure the position of IT within the company is the same that of an external IT provider. Hence the same level of professionalism in terms of quality and efficiency are demanded.

Communication concerns all business and IT employees whether they are managers, staff assigned to communication roles, or IT employees with technical tasks. Internally, multinational companies and global departments demand excellent communication and intercultural skills from employees and managers. This philosophy holds true for the field of IT. Smooth working processes and good performance are dependent on effective communications, especially in periods of change.

Effective communication is part of the overall plan for management of an Enterprise Architecture Program. An Enterprise Architecture communication document has to identify stakeholders of the organization’s Enterprise Architecture Program, the information needs of those stakeholders, and the communication strategy to be followed by the program in meeting those needs.

The goals of the Architecture Board, as established by (usually) the organization’s Management Committee’s mission and charter, requires a successful communication strategy. The Enterprise Architecture and the operations of the program charged with evolving that architecture are important topics that must be communicated by the program if the Enterprise Architecture initiative is to succeed.

The plan consists of sections devoted to an identified stakeholder group (you may reuse the stakeholders management defined in TOGAF). Within each section, the plan would identify:

  • The members of the stakeholder group
  • The TOGAF Enterprise Architecture Framework role(s) to which the stakeholder group maps
  • The information needs of the stakeholder group defined in the Architecture Vision The communication strategy to be followed by the program in meeting the information needs of the stakeholder group

This plan should be a living document, and as such should be updated on a regular basis to reflect new stakeholder groups, new information needs, and new communication strategies. It is important that the Enterprise Architecture Program be held accountable for implementation of this plan, and that the Architecture Board regularly reviews progress with the Program Director.

Stakeholder General Communication

Stakeholders are people who have key roles in, or concerns about, the system. Different stakeholders with different roles in the system will have different concerns. Stakeholders can be individuals, teams, or organizations (or classes thereof).

The list of stakeholders can be also based on the existing Business and IT organization and structure. It also takes into consideration recommendation from HR department addressing the various ways of communicating to various groups of people.

The various stakeholders may include (examples):

– Executive Management Board
– C-levels
– Business Users Advisory Board
– Business Units
– Procurement
– Architecture Board
– IT Units
– Enterprise Architecture team
– Customers
– Developers

The communication plan should take into consideration all groups (use best practices from EA frameworks such as TOGAF), the IT organization and the HR recommendations.

These groups will have to be clearly defined as probably some of the communication tools and techniques will have to be tailored for each community.

General Information Needs

The following information needs to be applied to all stakeholders.

  1. Understand what Enterprise Architecture is (at least at a high level)
  2. Understand the value, benefits, and importance of Enterprise Architecture to the business.
  3. Understand how the Architecture Board and Enterprise Architecture Program are contributing to the pursuit of the organization’s business objectives.

General Communication Tools

To meet these general information needs, the Enterprise Architecture Program should implement the following communications tools.

  1. A set of basic information materials describing the scope of the Enterprise Architecture. This set of materials will describe the value, benefits, and importance of Enterprise Architecture. The materials will be brief and concise, and may consist of: one-page briefing or brochure, key concept map, Frequently-Asked Questions (FAQ) document, position paper, and a presentation.
  2. In all status reporting, Committee and Program achievements will be explicitly linked to the organization’s business objectives.
  3. The basic Enterprise Architecture scope and value materials, as well as some high-level business-oriented status information, will be available (and prominently displayed) on the Enterprise Architecture website. These materials should be suitable for use/delivery by Architecture Board members as well as program staff. (The use of systems such as a CMS (Content Management System)would allow delivering information based on roles.)

Communication Matrix

A matrix should then be built which associates the various communication tools to the various stakeholders (see example below)

This matrix associates the communication tools to the various stakeholders. Each stakeholder, communication tool should then be described in that document and be related to various steps of the Enterprise Architecture governance.

The various views will also have to be defined in annexes.

Communication Planning

A Communication planning will have to be defined (see example below).

Implementation steps

To implement such a communication plan, the following steps will have to be completed:

  1. Validate if all stakeholders have been taken into consideration
  2. Define the content of each communication tool (reports, newsletters, verbal communication, etc.)
  3. Ensure that the appropriated communication tools are associated to the right stakeholders
  4. Implement the Communication Plan with the Business and the IT Department
  5. Once all communication tools are formalized and approved, identify the Business Units and roll out the communication plan to these stakeholders
  6. Once on board, roll out the communication plan to the Executive Management Board and C-levels
9 years, 11 months ago

Should the IT Strategist role disappear with Enterprise Architecture?

Many companies in their IT department have two units: IT Strategy & Planning and Enterprise Architecture. As regularly these are two different people managing these units, there is a high risk this ends up in serious conflicts.

The IT Strategist needs to understand the organization’s overall business strategy and is supposed to develop a comprehensive IT Strategic Plan that aligns with the business strategy (linkage, support of goals and objectives, etc.). He will continually assess all areas in the IT department to make sure their efforts and initiatives support this IT strategic plan, highlight gaps and identify alternatives to close gaps. During the development of the IT Strategic Plan (creation and maintenance of a detailed project plan (schedule, WBS, etc.) for the development and execution) , he interacts with various IT and Business Governance committees, and supports the execution and the evaluation of that plan.

How much is this different from one of the role of any Chief Enterprise Architect?

Among various roles the Chief Enterprise Architect ensures that the organization’s strategy is understood and acted on. Ideally, he should contribute to the strategy itself. He also has to understand, advocate and support the organization’s business and IT strategies.

Enterprise Architecture should be used to develop an IT Strategy. The EA team is in charge of implementing an EA program, which involves articulating the desired future state, understanding the current state, identifying the gaps between the two states and developing approaches to close these gaps. The team is leading the creation or evolution of the EA function or program, including the coordination of an appropriately balanced pursuit of enterprise business, information, application, technology and solution architecture viewpoints. Understand new technology future IT directions and how they can Impact the business.

When creating the new architecture (blueprint or high level architecture) which is based on the business goals and directions, they will identify new technology options and key finding from IT assets mapping and technology as-is mapping. The gap analysis will document each element that we mapped in the current state and translate this into roadmaps with dependencies and assignments: group gaps into projects, write one page of project high level analysis, assign resources to projects and creating a road map.

MODAF Acquisition Views will help to define these projects including dependencies.

FEAF in section 4 EA Transition Strategy / TOGAF Phases E (Opportunities and Solutions) and F (Migration Planning) describe similar activities.

Enterprise Architecture is a bridge to make the connection between business side planning and enterprise IT strategy making. When successful it delivers the IT strategy documentation.

The role of the IT Strategist should be split into two sets of activities (Enterprise Architecture and PMO (project management office) and does not make anymore sense when an organization has these two units.

9 years, 11 months ago

Should the IT Strategist role disappear with Enterprise Architecture?

Many companies in their IT department have two units: IT Strategy & Planning and Enterprise Architecture. As regularly these are two different people managing these units, there is a high risk this ends up in serious conflicts.

The IT Strategist needs to understand the organization’s overall business strategy and is supposed to develop a comprehensive IT Strategic Plan that aligns with the business strategy (linkage, support of goals and objectives, etc.). He will continually assess all areas in the IT department to make sure their efforts and initiatives support this IT strategic plan, highlight gaps and identify alternatives to close gaps. During the development of the IT Strategic Plan (creation and maintenance of a detailed project plan (schedule, WBS, etc.) for the development and execution) , he interacts with various IT and Business Governance committees, and supports the execution and the evaluation of that plan.

How much is this different from one of the role of any Chief Enterprise Architect?

Among various roles the Chief Enterprise Architect ensures that the organization’s strategy is understood and acted on. Ideally, he should contribute to the strategy itself. He also has to understand, advocate and support the organization’s business and IT strategies.

Enterprise Architecture should be used to develop an IT Strategy. The EA team is in charge of implementing an EA program, which involves articulating the desired future state, understanding the current state, identifying the gaps between the two states and developing approaches to close these gaps. The team is leading the creation or evolution of the EA function or program, including the coordination of an appropriately balanced pursuit of enterprise business, information, application, technology and solution architecture viewpoints. Understand new technology future IT directions and how they can Impact the business.

When creating the new architecture (blueprint or high level architecture) which is based on the business goals and directions, they will identify new technology options and key finding from IT assets mapping and technology as-is mapping. The gap analysis will document each element that we mapped in the current state and translate this into roadmaps with dependencies and assignments: group gaps into projects, write one page of project high level analysis, assign resources to projects and creating a road map.

MODAF Acquisition Views will help to define these projects including dependencies.

FEAF in section 4 EA Transition Strategy / TOGAF Phases E (Opportunities and Solutions) and F (Migration Planning) describe similar activities.

Enterprise Architecture is a bridge to make the connection between business side planning and enterprise IT strategy making. When successful it delivers the IT strategy documentation.

The role of the IT Strategist should be split into two sets of activities (Enterprise Architecture and PMO (project management office) and does not make anymore sense when an organization has these two units.