9 years, 3 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, 3 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, 3 months ago

Next: Canada, US, and Iceland

As indicated in a 140 char note on Twitter, I’m leaving Europe. For a month, that is. I am going on a flight/roadtrip, part work, part vacation. Locationwise roughly as follows: Toronto from July 17th to 25th. Washington, DC from July 26th to 31st. Ottawa from July 31st to August 6th. Boston from August 7th

9 years, 3 months ago

Next Generation EA

Come join us for Architecture Friday in Antwerp on 26 June about next generation enterprise architecture, as seen by two Australians and a Dane: Peter Bernus (wp) and Pat Turner, and me. If you want to participate, get in touch (you may get a discount code!). Peter Bernus chairs IFIP WG5.12 Architectures for Enterprise Integration,

9 years, 4 months ago

Aligning ITIL V3 Service Design with TOGAF 9

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!

9 years, 4 months ago

Aligning ITIL V3 Service Design with TOGAF 9

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!

9 years, 4 months ago

Modeling the MDM Blueprint – Part VI

In this series we have discussed developing the MDM blueprint by developing the Common Information (part II), Canonical (part III) , and Operating (part IV)  models in our work. In Part V  I introduced the Reference Architecture model into the mix to apply the technical infrastructure or patterns we plan on using. The blueprint has […]

9 years, 4 months ago

Counting Down to Book Launch

This has been a great week, for several reason, but most notably because our book, Coherency Management: Architecting the Enterprise for Alignment, Agility and Assurance, is now in AuthorHouse’s hands and should be ready for ordering very soon. On the book’s website, we have published the Table of Contents and a chapter overview, and also