togaf

Development of an Enterprise Architecture Communication Plan

by
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

Development of an Enterprise Architecture Communication Plan

by
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

Should the IT Strategist role disappear with Enterprise Architecture?

by

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.

Should the IT Strategist role disappear with Enterprise Architecture?

by

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.

Aligning ITIL V3 Service Design with TOGAF 9

by

ITIL V3 is structured in 5 modules, one of them being The Service Design book. This book refers to technology-related activities (requirements engineering; data/information management and application management). It also covers some of the practicalities: functional roles analysis; activity analysis; roles/responsibilities; and even service design and management tools. Service Design processes are important because they provide organizations with information that will affect their decisions on designing solutions for new or changed services-

Service Design has five aspects:

  • Design of the service solutions
  • Design of the Service Portfolio (and other supporting systems)
  • Design of the technology architectures and management systems
  • Design of the processes
  • Design of the measurement systems, methods and metrics

Section 3.6.3 on page 35, provides a specific context for the terms “architecture” and “system” which is well aligned with ISO/IEC 42010:2007 definition used by TOGAF 9.

”Architecture” is defined as:

“The fundamental organization of a system, embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution.”

”System ” in this definition is used in the most general, not necessarily IT, sense:

“A collection of components organized to accomplish a specific function or set of functions.“

”architectural design” as :

“The development and maintenance of IT policies, strategies, architectures, designs, documents, plans and processes for the deployment and subsequent operation and improvement of appropriate IT services and solutions throughout an organization.”

In ITIL V3, IT policies and strategies are defined by senior management during the Service Strategy phase of the service lifecycle. These policies may be also be reused during the Preliminary Phase of TOGAF 9. The Preliminary Phase allows us to establish the business context, customize TOGAF, define architecture principles, and establish the governance structure. Architectural Principles are general rules and guidelines that support the way in which an organization sets about fulfilling its mission. These principles should be the source for the creation of IT policies.

Service Architects and Designers will need to consider several resources such as (budgets, infrastructures, applications, information, and people) and capabilities (management, organization, processes, knowledge, and people) of the organization defined by TOGAF 9. This will have to be coordinated with the business requirements which may have been collected from a Business Scenario (TOGAF). Using inputs from the business and Service Strategy in ITIL V3, the design needs to take into consideration, people, processes, products, and partners. Also designers will have to take into consideration, the vision, mission, goals, and objectives in order to translate them into critical success factors, key performance indicators, metrics and measurements.

Documents in ITIL V3 may be considered as being artifacts in TOGAF 9. Artifacts consist of plans, contracts (Architecture contracts or other forms of contracts), job descriptions, organizational structures, process workflows, procedures, instructions, configuration, diagrams, catalogs, lists, and databases among many other document types.

One of the major difficulties for the designer will be to sort through this documentation and remove that which is obsolete, duplicated, incomplete, or erroneous. TOGAF with its Architecture repository may also help to store documents related to IT Service Management. You may also think of combining a CMDB with an Architecture Repository…but that would be another topic to discuss.

Although plans should be considered as documents, it is important to identify and sift through the myriads of plans that are in use in the organization. Plans may be produced by different lines of business including IT, issued by business planning committees, PMO, etc. Some of the difficulties will include gathering them (business plans, IT plans, operational plans, contingency plans, financial plans.etc.) , making sense of them and more importantly, making sure they are aligned. For these reasons, the TOGAF Migration Planning phase helps to coordinate different business areas and create a common plan.

The term architecture within ITIL V3 may be aligned with the 4 architecture domains from TOGAF:

  • Business Architecture: for Business, organization and enterprise
  • Data Architecture: for data and information, databases
  • Application Architecture: for applications
  • Technology Architecture: for hardware (desktops, mobile devices, servers, and mainframes), network, telephony and software

Some aspects may not be covered by architecture domains such the Environment (heat, ventilation, AC, etc.), or the physical workspace including safety (this would be covered by Security Architecture considered during the ADM phases).

Services would be a combination of the four domains.

The Service Design activities and processes covers:

  • Service Level Management
  • Availability Management
  • IT Service Continuity Management
  • Supplier Management
  • Information Security Management
  • Capacity Management
  • Service Catalogue Management

These processes can be designed when building the Technology Architecture with the Technical Reference Model (TRM).

Page 37 of the Service Design book refers to many documented practices available for designing, deploying, and operating service architecture. It lists Enterprise Architecture frameworks, one of them being TOGAF!

Aligning ITIL V3 Service Design with TOGAF 9

by

ITIL V3 is structured in 5 modules, one of them being The Service Design book. This book refers to technology-related activities (requirements engineering; data/information management and application management). It also covers some of the practicalities: functional roles analysis; activity analysis; roles/responsibilities; and even service design and management tools. Service Design processes are important because they provide organizations with information that will affect their decisions on designing solutions for new or changed services-

Service Design has five aspects:

  • Design of the service solutions
  • Design of the Service Portfolio (and other supporting systems)
  • Design of the technology architectures and management systems
  • Design of the processes
  • Design of the measurement systems, methods and metrics

Section 3.6.3 on page 35, provides a specific context for the terms “architecture” and “system” which is well aligned with ISO/IEC 42010:2007 definition used by TOGAF 9.

”Architecture” is defined as:

“The fundamental organization of a system, embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution.”

”System ” in this definition is used in the most general, not necessarily IT, sense:

“A collection of components organized to accomplish a specific function or set of functions.“

”architectural design” as :

“The development and maintenance of IT policies, strategies, architectures, designs, documents, plans and processes for the deployment and subsequent operation and improvement of appropriate IT services and solutions throughout an organization.”

In ITIL V3, IT policies and strategies are defined by senior management during the Service Strategy phase of the service lifecycle. These policies may be also be reused during the Preliminary Phase of TOGAF 9. The Preliminary Phase allows us to establish the business context, customize TOGAF, define architecture principles, and establish the governance structure. Architectural Principles are general rules and guidelines that support the way in which an organization sets about fulfilling its mission. These principles should be the source for the creation of IT policies.

Service Architects and Designers will need to consider several resources such as (budgets, infrastructures, applications, information, and people) and capabilities (management, organization, processes, knowledge, and people) of the organization defined by TOGAF 9. This will have to be coordinated with the business requirements which may have been collected from a Business Scenario (TOGAF). Using inputs from the business and Service Strategy in ITIL V3, the design needs to take into consideration, people, processes, products, and partners. Also designers will have to take into consideration, the vision, mission, goals, and objectives in order to translate them into critical success factors, key performance indicators, metrics and measurements.

Documents in ITIL V3 may be considered as being artifacts in TOGAF 9. Artifacts consist of plans, contracts (Architecture contracts or other forms of contracts), job descriptions, organizational structures, process workflows, procedures, instructions, configuration, diagrams, catalogs, lists, and databases among many other document types.

One of the major difficulties for the designer will be to sort through this documentation and remove that which is obsolete, duplicated, incomplete, or erroneous. TOGAF with its Architecture repository may also help to store documents related to IT Service Management. You may also think of combining a CMDB with an Architecture Repository…but that would be another topic to discuss.

Although plans should be considered as documents, it is important to identify and sift through the myriads of plans that are in use in the organization. Plans may be produced by different lines of business including IT, issued by business planning committees, PMO, etc. Some of the difficulties will include gathering them (business plans, IT plans, operational plans, contingency plans, financial plans.etc.) , making sense of them and more importantly, making sure they are aligned. For these reasons, the TOGAF Migration Planning phase helps to coordinate different business areas and create a common plan.

The term architecture within ITIL V3 may be aligned with the 4 architecture domains from TOGAF:

  • Business Architecture: for Business, organization and enterprise
  • Data Architecture: for data and information, databases
  • Application Architecture: for applications
  • Technology Architecture: for hardware (desktops, mobile devices, servers, and mainframes), network, telephony and software

Some aspects may not be covered by architecture domains such the Environment (heat, ventilation, AC, etc.), or the physical workspace including safety (this would be covered by Security Architecture considered during the ADM phases).

Services would be a combination of the four domains.

The Service Design activities and processes covers:

  • Service Level Management
  • Availability Management
  • IT Service Continuity Management
  • Supplier Management
  • Information Security Management
  • Capacity Management
  • Service Catalogue Management

These processes can be designed when building the Technology Architecture with the Technical Reference Model (TRM).

Page 37 of the Service Design book refers to many documented practices available for designing, deploying, and operating service architecture. It lists Enterprise Architecture frameworks, one of them being TOGAF!

TOGAF 9 Migration Planning and Project Portfolio Management

by

Phase F in TOGAF helps to describe how to create a viable implementation and migration plan in co-operation with the portfolio and project managers. Very often companies already have in place a Project Portfolio Management framework and there may be a need to integrate your enterprise architecture with that.

As an example, PMI has introduced a standard for Portfolio Management, and portfolio managers have a resource to help them develop professionally and achieve success for themselves and their enterprise. Within an organization, a portfolio represents a collection of active programs, projects and other work undertaken at a specific point in time to help the organization achieve strategic objectives. In essence, a portfolio reflects the priorities, investments and resource allocations.

Project Portfolio Management (PPM) may be part of an enterprise governance framework. It is a management process designed to help the organization-:

-To ensure that the organization is doing the “right things”, optimally allocating scarce resources toward the enterprise’s objectives
-To acquire and view information about all projects
-To sort and prioritize each project according to certain criteria, such as strategic value, resource impact, cost, and so on.

PPM has several activities which are similar to the objectives of managing a financial portfolio:

-The identification of all the individual demands in the portfolio
-The development of a “big picture” view and a deeper understanding of the collection as a whole
-The sensible sorting, adding, and removing of items from the collection based on their costs, benefits, and alignment with long-term strategies or goals.

In a nutshell, Portfolio Management can help zero in on the projects that are most worth their effort; project management can help execute those projects most efficiently.

These activities can be perfectly integrated with Phase F of TOGAF. Once the work packages, projects and building blocks inventory is created, the enterprise architecture team with the portfolio managers (and other important stakeholders) will examine each project and prioritize it according to established criteria. They will probably assign a business value; conduct a cost business analysis for each project (done in collaboration with business people); identify the risks to the projects.

The overall list of projects is then considered to develop a well-balanced list of supported projects and provide an input for a detailed implementation and migration plan. It will also help to confirm the Transition Architecture defined in the phase E. The use of an Architecture definition increments table is highly recommended to list these projects.

Some projects will be given high priority and extensive support, some will be given moderate priority, and still others will be placed on hold or dropped entirely from the list. This will also help to finalize the Architecture roadmap. Finally, resources will need to be identified and made available.

Other Governance domains may also be to be integrated in the PPM process and Phase F, such as Risk Management (e.g. RiskIT), Project Management (e.g. PMI, PRINCE 2), etc.

Companies who are mature in Portfolio Management activities may integrate their existing work practices easily with TOGAF. This would enforce the relationship between the Enterprise Architecture team and the PMO (or the PPM team).

(You can also refer to another post: Why do we not find yet links between Enterprise Architecture and Project Portfolio Management? )

TOGAF 9 Migration Planning and Project Portfolio Management

by

Phase F in TOGAF helps to describe how to create a viable implementation and migration plan in co-operation with the portfolio and project managers. Very often companies already have in place a Project Portfolio Management framework and there may be a need to integrate your enterprise architecture with that.

As an example, PMI has introduced a standard for Portfolio Management, and portfolio managers have a resource to help them develop professionally and achieve success for themselves and their enterprise. Within an organization, a portfolio represents a collection of active programs, projects and other work undertaken at a specific point in time to help the organization achieve strategic objectives. In essence, a portfolio reflects the priorities, investments and resource allocations.

Project Portfolio Management (PPM) may be part of an enterprise governance framework. It is a management process designed to help the organization-:

-To ensure that the organization is doing the “right things”, optimally allocating scarce resources toward the enterprise’s objectives
-To acquire and view information about all projects
-To sort and prioritize each project according to certain criteria, such as strategic value, resource impact, cost, and so on.

PPM has several activities which are similar to the objectives of managing a financial portfolio:

-The identification of all the individual demands in the portfolio
-The development of a “big picture” view and a deeper understanding of the collection as a whole
-The sensible sorting, adding, and removing of items from the collection based on their costs, benefits, and alignment with long-term strategies or goals.

In a nutshell, Portfolio Management can help zero in on the projects that are most worth their effort; project management can help execute those projects most efficiently.

These activities can be perfectly integrated with Phase F of TOGAF. Once the work packages, projects and building blocks inventory is created, the enterprise architecture team with the portfolio managers (and other important stakeholders) will examine each project and prioritize it according to established criteria. They will probably assign a business value; conduct a cost business analysis for each project (done in collaboration with business people); identify the risks to the projects.

The overall list of projects is then considered to develop a well-balanced list of supported projects and provide an input for a detailed implementation and migration plan. It will also help to confirm the Transition Architecture defined in the phase E. The use of an Architecture definition increments table is highly recommended to list these projects.

Some projects will be given high priority and extensive support, some will be given moderate priority, and still others will be placed on hold or dropped entirely from the list. This will also help to finalize the Architecture roadmap. Finally, resources will need to be identified and made available.

Other Governance domains may also be to be integrated in the PPM process and Phase F, such as Risk Management (e.g. RiskIT), Project Management (e.g. PMI, PRINCE 2), etc.

Companies who are mature in Portfolio Management activities may integrate their existing work practices easily with TOGAF. This would enforce the relationship between the Enterprise Architecture team and the PMO (or the PPM team).

(You can also refer to another post: Why do we not find yet links between Enterprise Architecture and Project Portfolio Management? )

Deliverables, Artifacts And Catalogs-Matrices: Some examples

by

Quite often as an Enterprise Architects we are asked to show what the deliverables of an Enterprise Architecture program are.

TOGAF provides a methodology for analyzing your specific situation and turning that analysis into deliverables and actionable artifacts. Artifacts may have different shapes as defined in TOGAF 9. They may be: Catalogs, matrices or diagrams. EA artifacts may also help to define a standard set of document types such as education, strategy, decision, policy, standard, guideline, etc. It is also recommended that you set up a simple online discussion thread or wiki for each artifact to solicit feedback from artifact consumers.

Enterprise Architects should ensure that their efforts to create architecture documentation produce meaningful results by creating artifacts that connect with the consumer, drive decisions, and will allow the development of reusable building blocks.

If we consider the various architecture domains, they may have different forms.

As examples-
in Business Architecture, they could be the views of the Business stakeholders. The matrices between business strategy and the main business functions. The diagrams showing the relationship between processes and information. The Value Chains. Business and Operating models of the Enterprise. Customizing the configuration of the Business Functions according to model — and more.

The artifacts for Data or Information architecture may refer to an information map or diagram . It could also show the mapping between data items and the Business Information map.

Artifacts for Application Architecture, could show the key interconnections between applications, middleware connection matrices. There may also exists views for Portal Architecture, Enterprise Content Management , Identity management, Business Intelligence, ERPs and CRMs.

Last but not least, Technology Architecture artifacts may propose servers and storage technology diagrams, office views (file, printing, data base servers, etc…), LAN/WAN/Voice Network architecture diagrams, applications and interconnections mapping to technology servers and networks, infrastructure security diagrams. In addition to that, there may be a certain numbers of artifacts related to the company’s organization, organization chart, lines of business mapping to business functions, organization roles in organization units and job descriptions.
Many graphical tools may aid to develop diagrams or document matrices but may also be quite costly. The use of spreadsheet may be a first step in building artifacts such as matrices. The following examples illustrate how they may simply be build with Excel.

List of Metadata

Data-Business process matrix
Application Inventory List

These are very basic example of what artifacts may look like. They may rapidly be created and are definitely a way to explain to the EA stakeholders how the first deliverables of our baseline architecture looks like.