What does developing an IT Strategy mean?

I have observed many situations where a c-level person was supposed to document an IT Strategy in a short period of time in order to prepare the following year's annual budget. Very often lacking much supporting documented business information the result is a weak strategy, sometimes ignored by the user's community, the key stakeholders.

A weak IT strategy can be costly and wasteful, especially for resource-constrained organizations that operate with minimal budget, tools, knowledge and people.  It also implies that organizations cannot respond to changing business requirements rapidly enough. The absence of strategic anticipation causes organizations to be inefficiently reactive, forcing them to work in a constant state of catch-up.

An IT Strategy should answer the following questions:

• Are we doing the right things with technology to address the organization’s most important business priorities and continuously deliver value to the clients?
• Are we making the right technology investments?
• Do we measure what is the real value to the organization derived from that technology?
• Is our current Information Technology agile enough; flexible to continuously support a successful organization?
• Is our Information Technology environment properly managed, maintained, secured, able to support the clients, and is it cost effective?
• Can our strategy support current and future business needs?

Quite often the first thing we should consider when writing such a document is the targeted audience and its content. Different people with varying roles and responsibilities may read an IT Strategy within a company, so the document may need to serve several different purposes. It is not easy to pitch a strategy to different levels in the hierarchy within an organization, and at the appropriate level of detail. Sometimes it is too detailed and does not always match the stakeholder’s needs.

An IT Strategy is an iterative process to align IT capabilities with the business strategy and requirements:

• It is a documented and approved process (part of the organization’s governance framework)
• It is iterative (it needs to be frequently be revisited). Traditionally, IT strategies are updated and communicated on an annual basis, usually to meet budget cycles. This should be considered the minimum review period. If an emerging technology surfaces that has the potential to enhance the business, it should be investigated and communicated to the business as soon as possible. A one-year cycle may be too late.
• It is a strong alignment of business and IT capabilities rather than designing IT solutions to support business requirements
  • Assuming that both business and IT capabilities drive each other
  • Assuming that business drives IT and not the other way around
• The IT Strategy sets future direction for IT function in the organization
  • Ensuring that the IT budget is spent on value creation activities for the business
  • Creating shareholder value
  • Helping to maximize the return on IT investments
• The IT Strategy may include sub-elements such as:
  • Infrastructure strategy
  • Application strategy
  • Integration strategy
  • Service strategy
  • Sourcing strategy
  • Innovation strategy

This pyramid diagram can be used to illustrate the IT strategy and vision, and how the technology and business strategies are totally aligned. At the top of the pyramid is the enterprise overarching vision. Aligned below that is how IT supports the vision by becoming a premier IT organization in creating competitive advantage for the clients. The IT vision is in turn supported by three pillars: integration, improvement, and innovation.





To deliver this , the business strategy should clearly be articulated and documented taking into account some IT aspects. There are different ways of gathering these business inputs.
The first approach is a very classical one where you develop a questionnaire in business terms which asks each business unit to identify their future requirements for infrastructure growth, taking into account capacity and availability requirements. This extracts the data you need for business driven strategy.

This questionnaire may include some of the following examples of questions:

1. What are your top 5 business “pain” points? These are things that you wish you had a solution for
2. What are your top 5 business objectives? These can be short term or long term, can be driven by revenue, cost, time, time to market, competitive advantage, risk or various other reasons
3. How do you plan to achieve these objectives?
4. What will we gain by leveraging IT Capabilities across the business?
5. What is in the way of achieving your business imperatives?
6. Can IT help achieve your business imperatives?
7. How much do you spend on IT capabilities?
8. What is your technology ROI?
9. Does your company have a plan for technology?
10. Does your business plan include a technology plan?
11. Where is IT being used across your business unit?

The second approach would be the use of Enterprise Architecture that I will explain later on.

With this input you may now start to consider the structure of your document. It may look similar to this example below: An executive summary

• An introduction
  • The purpose
  • The background
  • The Business drivers
  • The Organizational drivers
  • The IT drivers
• The Business and IT aspects
  • The Business Goals and Objectives
  • The IT approaches and principles
• The IT components
  • Business application systems
  • IT infrastructure
  • Security and IT Service continuity
• Structure, organization and management
  • IT Governance
  • Skills, knowledge and education
  • IT Financial management
  • KPIS, measurement and metrics, balance scorecards
• Technologies opportunities
• Key issues

And this is where Enterprise Architecture may have to play an important and even crucial role. Some companies I have encountered have an Enterprise Architecture team, and in parallel, somebody called an IT Strategist. Frequently the connection is non-existing or quite weak. Other organizations may also have a Strategic Planning unit, again without any connection with the Enterprise Architecture team.

An Enterprise Architecture must play the important role of assessing; existing IT assets, architecture standards and the desired business strategy to create a unified enterprise-wide environment - where the core hardware and software systems are standardised and integrated across the entire organisation’s business processes, to greatly enhance competitive advantage and innovation. The IT Strategy details the technologies, application and the data foundation needed to deliver the goals of the corporate strategy, while Enterprise Architecture is the bridge between strategy and execution; providing the organising logic to ensure the integration and standardisation of key processes that drive greater agility, higher profitability, faster time to market, lower IT costs, improved access to shared customer data and lower risk of mission-critical systems failures.

As a real example, TOGAF 9 is perfect way to produce that IT Strategy document during the Phase F: Migration Planning.

Below you will find the relationship between some phases of the ADM and the structure of the above document. It needs to be said that we should probably use a Strategic architecture level to deliver a first version of the document, which then could be reviewed with Segment or Capability architectures.

Content		Examples	Enterprise Architecture and TOGAF
An executive summary
An introduction (This document must be business oriented)
Content		Examples	Enterprise Architecture and TOGAF
	The purpose	Key elements of the scope, audience, time horizon	The Preliminary phase is about defining ‘‘where, what, why, who, and how” Enterprise Architecture will be done and will provide all information. It also creates the conditions and context for an Architecture Capability
	The background	Business problems, constraints (financial, resources, IT, legal, etc.)	This is covered by the Phase A: Architecture Vision. An Architecture Vision sets stage for each iteration of ADM cycle. -Provides high-level, aspirational view of target the sponsor uses to describe how business goals are met and stakeholder concerns are addressed -Provides an executive summary version of full Architecture -Drives consensus on desired outcome The Business Scenarios is used to discover and document business requirements, identify constraints, etc.
	The Business drivers	Market conditions, competition, consumer trends, new customers, products sales, costs savings, incremental services revenues, drivers related to the IT function	In the Phase A: Architecture Vision, we: Identify business goals and strategic drivers -Ensure that descriptions used are current -Clarify any areas of ambiguity Define constraints -Enterprise-wide constraints -Architecture project-specific constraints
	The Organizational drivers	Profitability, financial performance, change in strategic objectives, end of the product development life cycle, mergers and acquisitions, staffs, risks
	The IT drivers	New or obsolete technologies, updates	Considering that IT is part of the Business, these drivers should also be considered in that phase
The Business and IT aspects
	The Business Goals and Objectives	Market growth, entering new markets, addressing manufacturing capacities	In the Phase A: Architecture Vision, we: Identify business goals and strategic drivers -Ensure that descriptions used are current -Clarify any areas of ambiguity -Define constraints -Enterprise-wide constraints -Architecture project-specific constraints
	The IT approaches and principles	IT standards, development, implementation, delivery, testing, consolidation, maturity, best practices	Standards should be documented in the SIB (Standard Information Base) When we define the Architecture Governance Framework during the Preliminary Phase, we identy the various touch points with existing other frameworks in the organization IT principles should have already have been defined by the IT department
The IT components
	Business application systems	Baseline (main applications: ERP, CRM, customers facing systems). Future plans, concerns, time period, priorities)	This will be addressed by Phase C: Information Systems based on the Statement of Architecture Work, output from the Phase A
	IT infrastructure	Baseline (servers, network , middleware, technical services)	This will be addressed by Phase D: Technology Architecture based on the Statement of Architecture Work, output from the Phase A
	Security and IT Service continuity	Issues, challenges, opportunities related to security, security principles, controls	Security concerns are addressed during all phases of the ADM
Structure, organization and management
	IT Governance	Best practices, frameworks, management and monitoring, resource management, portfolio management, vendors management, IT service management, project management, etc.	IT Governance will be considered when the Architecture Governance Framework is defined. There will obviously be touch points between the ADM and some other best practices used by the organization. IT Governance is defined outside of the Enterprise Architecture programme
	Skills, knowledge and education	Skills, knowledge and education	Enterprise Architecture skills will have to be addressed by the Architecture Capability Framework. Other skills may also be identified independently of the Enterprise Architecture programme
	IT Financial management	IT budget, costs structures, measurement and metrics, targets, areas needing investments, etc.	This is addressed is outside of the Enterprise Architecture programme
	KPIS, measurement and metrics, balance scorecards	IT performance measurements on SMART objectives ((Specific, Measurable, Achievable, Realistic, & Time bound)	Every governance frameworks may have its own KPIs. Enterprise Architecture KPIs may be added to that list.
Technologies opportunities		Emerging technologies, business related benefits	This can be done in parallel of the Enterprise Architecture programme
Key issues and initiatives		Summary or link to the IT Project portfolio	This can be done in parallel of the Enterprise Architecture programme

Color legend
	Direct relationship with Enterprise Architecture
	Indirect relationship with Enterprise Architecture
	Produced somewhere else

The next step would be the review of the IT Strategy document by the main stakeholders who would accept or reject technology opportunities. This could also be used as an important source of information for the Strategic Planning exercise (please refer to another post for additional information: “How Strategic Planning relates to Enterprise Architecture? “).

Once the IT Strategy has been reviewed, amended and authorised (which should in reality already be approved, as it is the result of various ADM cycles and the output of Phase F: Migration planning), the multi-disciplinary programme team for the implementation during Phase G: Implementation Governance, will deliver the solutions to the business.

As already mentioned previously, the outline strategies will be refined and expanded with a low level of detail when addressing Segment and Capability architectures. This is the part that meets the first challenge described above, where we need different levels of detail for different stakeholders. The documents should be hierarchical, with the ability to drill down to lower levels as more detail is required.

One of the main reasons for developing an Enterprise Architecture with TOGAF 9 is to support the business by providing the fundamental technology and process structure for an IT Strategy. Enterprise Architecture is the superset that represents both Business and IT Strategy; this is reflected in Enterprise Architecture’s basic structure of strategy, business architecture and technology/information architecture. One can certainly do an IT Strategy without Enterprise Architecture, but Enterprise Architecture cannot be done without an IT Strategy; the same would apply to business strategy/business architecture.

IT Governance, finally a worldwide recognition: ISO 38500

Finally IT Governance will be recognised as a standard. We already had a series of ISO standards for various IT Governance domains such as IT Service Management ISO 20000, Security Management ISO 27001, and Quality ISO 9000, but recently the international organization recognized that a new standard would be well accepted. It will be named ISO 38500 which will cover Corporate Governance of information technology. This standard was originally defined as an Australian standard AS8015, which by the way was the only alternative available.

AS8015 is (was?) intended to provide guiding principles to any organisation, from the smallest to the largest, including private and public (listed and unlisted) companies, not-for-profit organisations, associations, clubs and government agencies. This standard has an application to just about any organisation, either because you are a supplier of ICT related goods and services or more simply because you implement and use ICT in your business.

AS8015 provides six guiding principles for good corporate governance and the effective, efficient and acceptable use of ICT. The six principles (and examples of each) are:

1 Establish clearly understood responsibilities for ICT (eg, ensure individuals understand and accept their responsibilities)
2 Plan ICT to best support the organisation (eg, ensure ICT plans fit current and future needs and the organisation’s corporate plans)
3 Acquire ICT validly (eg, ICT acquisitions should be made for approved reasons and in the approved way; on the basis of ongoing analysis)
4 Ensure ICT performs well, whenever required (eg, ensure ICT is fit for its purpose and is responsive to changing requirements)
5 Ensure ICT conforms with formal rules (eg, ensure compliance with external regulations and internal policies and practices)
6 Ensure ICT use respects human factors (eg, ensure ICT meets the evolving needs of the ‘people in the process’)

The following ISO website used to be where the draft was located (different number) but if you want more information you may refer to

http://www.ramin.com.au/itgovernance/as8015.html

The 26th of May, the standard will be launched in the Netherlands. As any ISO standards, this will impact how IT Departments are organized!

Differences between IT Governance and Enterprise Architecture Governance

IT Governance is the responsibility of the board of directors and executive management of an IT department. It is an integral part of the enterprise governance and consists of the leadership and organizational structures and processes that ensure that the organization's IT sustains and extends the organization's strategies and objectives.

IT Governance ensures that

• IT delivery expectations are fulfilled
• IT resources deployment is continuously planned, targeted and optimized
• IT performance is measurable
• and that the risks are minimized

We may consider defining an IT Governance team which would care of various domains such as Project Portfolio Management, Security Management, Project Management, COBIT, SOX, Risk Management ,Service Management, ISO 9000, etc..

Enterprise Architecture Governance encompasses leadership, implementation and controlling of Business Architectures, IT Architectures (Information, Application, Technology architectures) and Solution Architectures including organizational structures (organizational units as well as processes and roles) to ensure that architecture sustains and extends the business strategy and objectives. When we implement an EA Governance, we may consider defining an Architecture Review Board which decides which IS is best suited for the needs of the enterprise, it decides when a change in the architecture is needed, and prioritizes initiatives. More detailed explanation on this other post.

To summarize Enterprise Architecture is one of the IT Governance pillars and Enterprise Architecture with its associated Governance is s subdomain.

Service Management and Enterprise Architecture

An article I wrote for OpenSource magazine published yesterday, you may comment here!

http://opensource.sys-con.com/read/493465.htm

ITIL V3, Enterprise Architecture and Project Portfolio Management, where do I start?

Recently I have attended the ITIL V2 to V3 bridge course and took the examination. It is clear that one day is not enough and a day and a half would have been convenient. IIL V3 is supposed to be an evolution and not a revolution… Pretty sure that a day and a half would have frightened some IT decision makers… and the decision was from trainers to only offer that single day.

As I was prepared for the course (I did some reading before), this was not a real issue...

This being said, after a few days I was wondering how companies would present ITIL V3 to the IT Management team, to a CIO, and obviously the business! The introduction of the Service life cycle is a new concept which requires the buy-in and the sponsorship maybe beyond the IT department! Service Strategy has to be sold, and demonstrates a real value, but this not the point.

Let’s imagine you are in a mature IT department where IT Governance is your daily culture. You may have different IT Governance pillars and among them:

• IT Service Management


• Project Portfolio Management


• Enterprise Architecture

Usually, different teams take care of these initiatives and unfortunately they do not always work together.

The Project Portfolio Management team (PPM) collect business demands and requirements, classify, categorize them, and on an annual basis, do some sort of planning after a budgetary exercise with the business. The PPM team may collaborate with the Enterprise Architecture team to better understand the impact of new demands on the company’s architectures. They may also interact with the IT Service Management for Capacity Management and Service Level Management to better assess these demands.

The Enterprise Architecture (EA) team who already has documented a baseline architecture, define a target architecture (or transition architecture) based on the business drivers, business strategy and with a gap analysis, identify new opportunities, new projects. These new initiatives may afterwards be included in the list of projects and be processed by the PPM team.

With V3, the situation becomes more complex as we have a new way of starting projects! The view is based on the creation of new services which are then included in the Service pipeline and Service Portfolio. In the past, with V2, operational people only had a reactive position. With V3, Service Strategy considers the business view and proposes ITSM as a way to launch new projects!

Isn’t this confusing? Do you think that companies which already have implemented PPM and eventually EA would change the way they classify and launch new projects? Would you go to your CIO and tell him….”...now with V3… we should start with a Service Strategy and consider PPM and EA, either in parallel or afterwards”?. No way! Would you go to your business partners and claim that V3 is a new way of creating new projects and services? Maybe not…

Below I have tried in a diagram to describe various scenarios related to how companies may approach the three domains:

• The PPM view considers new projects with PPM has the core methodology to address business needs. It refers first to Enterprise Architecture and then IT Service Management.
  


• The EA view consider PPM first and finally ITSM.
  
  
• The ITSM view (in fact V3) consider first PPM (Service Strategy) and then EA (Service Design)

It is clear that none of these approaches can be considered as better than the other one. All frameworks include bits and pieces of the others. I may imagine that V3 will make the choice event more difficult and mature IT department will have to evaluate where Service Strategy and Design fits in their IT Governance framework…or consider V3 has being the more innovative and change the company’s culture.

Do not miss Enterprise Architecture Governance!

Many people are considering Enterprise Architecture as a way to align IT to Business not only through the use of formalized processes. When looking at the various components of enterprise Architecture such as baselines, all kind of principles, modelling, target architectures, views, impact analysis among other of things….governance often appears as something maybe secondary. To be successful, Enterprise Architecture governance should be at the core of any program.

To build baselines, gap analyses, target architectures without a proper EA framework may end in a dead end. All new business initiatives should be validates against the current Enterprise Architecture, all exceptions have to be monitored, documented, and probably escalated. All changes on existing services, applications or infrastructure have also to be compliant with the existing Enterprise Architecture. This could be at any level, Technology Architecture (or infrastructure), Application Architecture etc..

When starting to think about your Enterprise Architecture initiative, there are two very important considerations that needs to be considered:

-How do we implement governance in the Enterprise Architecture and what are the associated processes
-How do we ensure adherence and a real collaboration in the processes

Furthermore, it is important to identify the differences between IT Governance and Enterprise Architecture Governance. Standards such as ITIL, COBIT or CMMi focus on IT Governance but none of them really refer to this EA Governance.

Governance lies at the heart of the Enterprise Architecture processes. It should be a framework that there is a logical consistency underlying the enterprise architecture structure. This structure in its broadest context means that we understand all the relationships between artifacts which are formalised.

Looking at the various EA frameworks it appears that these processes are never really clearly identified and documented.

I have identified 6 of them. Obviously each company will have to design them in a way which fits the company’s structure:

Enterprise Architecture Governance - PPM

This process identifies how any new demand or business initiative is routed to an Enterprise Architecture team for a first level assessment and impact analysis. The process also integrates at a high level Project Management and ensure that deliverables are still aligned with the initial architecture definitions.

Enterprise Architecture Compliance

All changes to business processes, information, technology, application and solutions are subject to architecture compliance. This step ensures that all changes are compliant with the existing Enterprise Architecture. If not compliant, request for exceptions go through review. In the case of an exception, the Architecture review board may issue a waiver to approve the exception. Alternatively, it may deny the exception.

Enterprise Architecture Waiver

In the event that a project sponsor's petition for an exception to the Enterprise Architecture is denied by the Architecture review board, the project sponsor may opt to appeal that decision to the Executive board, which has the authority to overrule the Architecture review board.

Enterprise Architecture - Standard Management

New company’s Standards should be the result of an investigation. Once a study or a proof of concept is finalized and presented, the latest may become a standard.

Other situations may occur when an existing standard is upgraded or there is a need for harmonization and consolidation. In both cases, standards have to be documented according to existing templates, be validated and approved by the Architecture review board, and finally approved by the IT Management team (eventually the CIO).

Enterprise Architecture – Standard Waiver

In case of exception, a waiver exception form has to be completed and be approved by the Architecture review board and the IT Management team.

Enterprise Architecture Requirements

Architecture often deals with drivers and constraints, many of which are beyond the control of the enterprise (changing market conditions, new legislation, etc.).
Architecture requirements are therefore invariably subject to change in practice. This process collects, identifies, stores and feeds requirements.

Enterprise Architecture Annual Revision or Changes

The architecture team is responsible for creating Enterprise Architectzre and revising it as an example, each year as recommended in many frameworks. Industry analysts and subject matter experts should be involved as needed in the process.

The Enterprise Architecture is updated at least on an annual basis to:

1 Incorporate amendments that were previously approved
2 Incorporate new technical standards, patterns and services, information, solutions, and business processes
3 Evolve the future-state road maps to reflect changes in business strategy

The structured architecture creation/revision process is defined by the architecture team in place and approved by the Architecture review board.

At the completion of the annual revision cycle, the updated Enterprise Architecture is submitted to the Architecture review board for approval and adoption.

Enterprise Architecture and ITSM Changes

There is a need to determine if a change (RFC) has to go through architecture compliance. If, in the opinion of the architecture team, the project has a low architectural risk, they may conditionally exempt the project from the architecture compliance process. This should be a step in the Change Management process.

There may exist additional processes…every company can extend its Enterprise Architecture governance the way which is appropriate.

That governance is put in place not just for ensuring compliance but also for ensuring enterprise wide collaboration.

Enterprise Architecture governance must ensure that decision makers across all disciplines in the company apply the same design patterns and are aligned to common design objectives.

Efficient Enterprise Architecture needs waiver requests...

A waiver request can be a new document type in an Enterprise Architecture program. The purpose of such a document is to request an exception to an approved Enterprise Architecture for information systems and applications. It allows to document the business justification, risk management process, and costs associated with an exception. This document and the associated exception process could apply to any system, application, element, or practice that varies from the approved Enterprise Architecture. These include but are not limited to data, applications, security, integration, collaboration, systems management, network and telecommunications systems, components, practices, and protocols. An Enterprise Architecture Review Board which is the decision authority for all waiver requests and could use its discretion to classify all waiver requests in different categories and will formulate a recommendation for approval or disapproval.

Examples of an important exception request could be:
· The total remediation cost for the exception exceeds fifteen percent of the project value.
· The total remediation cost exceeds USD 0.5 million.
· The exception will introduce a service, product, technology, or practice not currently in use in the company or is categorized as "Emerging" in the architecture.
· The exception violates an Enterprise Architecture principle.
· The exception is a service, product, technology, or practice, which is identified for "Containment" or "Retirement" in the current Enterprise Architecture.
· The exception does not comply with the infromation standards for a system for which it creates, updates, or deletes data.

Whether the waiver request is for a minor or major change, The board domain expert stakeholder or the board team will use the same decision criteria when approving or disapproving a request. Specifically, the individual member or board must determine whether the benefits associated with implementing the exception request outweigh any negative impacts to the IT community. In exercising this discretion, the decision-makers will consider:

· the impact of not granting the exception
· the technical merit of the exception
· the collateral impact to other systems and business processes
· the impact to the Enterprise Architecture
· alternatives to granting the exception
· precedent setting effects

Decision-makers must consider the Enterprise Architecture principles (including Business principles, Information principles, Application principles, Technology principles).

The decision-makers may approve or disapprove all or a portion of a request, based on the complexity of the system for which the exception is requested. The board should develop a consensus in reaching its decision.

The requestor has several important responsibilities in the architecture waiver process. First, the requestor is responsible for documenting the information contained in this form. This information outlines the justification for the exception and is critical to the decision-making process. Second, the requestor is responsible for obtaining the approval of the business owner and the technical owner. Finally, the requestor may have an opportunity to present the exception request to the decision authority on a scheduled basis.

The technical owner must approve all exception requests proposed by the requestor prior to review. The technical owner is the individual responsible for supporting the impacted business process with information systems solutions.

The business owner must approve all exception requests proposed by the requestor prior to review. The business owner is an individual at the director level or above who manages the business process that the system supports or will support.

The re-birth of Enterprise Architecture?

Sadly enough, Enterprise Architecture has always been considered as a side IT Governance component and few big names were proposing services around products. Why? Simply because the IBM and HP like did not have any product offering…IBM always claimed that they were into Enterprise Architecture but they always tried to sell their Rational line of products without really understanding what is EA all about…. Probably when acquiring all Rational products, there would be a chance to do EA, but at what effort, what level of integration and also at what cost? Modelling processes with Websphere Business Modeler is still a techie activity and there were no indication that Business Analyst would be able to use such a tool. Very often business people were rather considering using Mega or Aris from IDS Sheer. HP also on its side was never per formant on IT Governance and acquired Peregrine and Mercury, for Service Management, Project and Portfolio Management. Enterprise Architecture has never been on their agenda, despite the fact they sponsor the Open Group. This may change…

In a recent post I was wondering why these companies did not take into consideration companies such as Telelogic, Casewise, IDS, Mega, Troux and others. My view was that in the next 12 months the market landscape would change and most EA companies would be acquired.

This has just been confirmed by IBM who acquired today Telelogic. Telelogic propose two components: DOORS and the ex-Popkin System Architect. Requirement is at the center of Enterprise Architecture and the Telerate offer was really appealing.

Now with IBM a few questions have to be raised:

• What’s going to happen with Requisite Pro and DOORS? These two products have similarities.
• What about Websphere Business Modeler and the System Architect process modelling tool? Same issue.
• How will Telerate integrate with the Tivoli CCMDB (Enterprise Architecture Artifacts and CIs). An Enterprise Architecture Repository should be maybe an instance of a CMDB.
• How will be integrated WSRR with the SOA modelling of Telerate?
• How will RUP for SOA /SOMA) fit the various EA framework supported by Telelogic?

Will IBM start to really propose professional services around Enterprise Architecture and support TOGAF as an open Framework among others?

Until now it has not been the strength of these well known companies to provide a consistent roadmap in terms of integration. As another example HP is doing a poor job in terms of integrating Mercury and Peregrine (the roadmap is absolutely unclear in terms of UCMDB.. and there are no indication how redundant service management functions between Mercury and Peregrine will be managed). Different contacts, different interpretation of the account managers…

Will IBM be able to better integrate their suite of modelling and architecting products? Will they be able to provide roadmaps, strategy and clear directions?

With this announcement there is a high chance that competitors such as CA, HP, Microsoft and others will soon start to consider Enterprise Architecture as a new source of income and a way to sell new products. Watch the space for acquisition! That story will be similar to the one related to the auto-discovery tools market and CMDB.

If most of the big names will soon have an EA offer in terms of products and service, this will launch a new wave of EA projects and will help standardization organization to better promote EA initiatives!