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.

Comparing various Enterprise Architecture Frameworks

There are plenty of comparisons between architecture frameworks and the one I like is written by Roger Sessions from Objectwatch, Inc.

http://msdn.microsoft.com/en-us/library/bb466232.aspx

However when you need to explain this to your IT Management or to any decision maker, it becomes a real challenge.

Below is a section of an internal employer email recently sent to explain the role of Enterprise Architecture and how it helps to develop business solutions for people using technology. It uses the analogy of undertaking a trip to explain how the architecture can help on that journey.

...It takes quite some time in convincing people that the decision is not TOGAF or DODAF or FEAF etc. but using just enough of each architecture framework to produce a functionally elegant, minimally complex and maximized compliant solution.

It describes the differences between the frameworks somewhat more simplistically: Zachman is like the map at a low resolution.

TOGAF is like the directions on the map that will lead us to some destination (it may be a good or bad destination).

FEAF contains specific information such as the reference models which act like the road rules and speed limits and communication protocols of our mobile phones, etc. (these are the sensible and logical constraints).

MODAF / DODAF and other defense architecture frameworks describe how our vehicle, which we are using to undertake our journey, is constructed, supported, used, etc (say a bike or a car).

Always refer back to Zachman when you are lost. (Overcome with complexity).

Refer to TOGAF at specific milestones in the journey. (Preparing for reviews, checking completeness of the architecture, etc.).

FEAF reference models for what technologies, constraints, resources, etc that can be used in the architecture.

DODAF when redesigning or designing or specifying explicitly a ‘widget’ in the architecture. (Widget may be a solution agnostic architectural building block or a solution dependent solution building block)...