TOGAF 9 Migration Planning and Project Portfolio Management

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? )

Keep an eye on OneCMDB and the CMDB Federation

OneCMDB Version 2.0 is a real interesting concept and product as this may be one of the first IT Service Management solution developed in an Open Source mode. It will not replace your Service Desk solution but may help companies with limited budget or companies which have a wide diversity of existing catalogs of assets. It is only covering Configuration Management as a process and in some way IT Assets management. For those who are using Nagios, there exist some connectors.

This has been initially developed by Lokomo Systems using Java but I’m not sure how does that fit with the CMDB Federation Group (I wrote a post on the subject in 2007) if it still exists….(I haven’t seen any indication of activity since January 2008 and maybe this is a dead project…).

In any case, keep an eye on both…

Deliverables, Artifacts And Catalogs-Matrices: Some examples

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.

TOGAF 9 Workshop at the Integration Consortium

The Integration Consortium asked me to run a TOGAF 9 Workshop at their Global Integration Summit on the 2nd of June in Las Vegas.

Details

TOGAF 9 introduces a very appealing concept of Capability-based planning for Business People

TOGAF 9 promotes a very interesting concept related to Capability-based planning which is an approach more focused on business issues and outcomes. TOGAF 9 defines a capability as “An ability that an organization, person, or system possesses. Capabilities are typically expressed in general and high-level terms and typically require a combination of organization, people, processes, and technology to achieve. For example, marketing, customer contact, or outbound telemarketing. “

Capabilities are in fact the building blocks of business. A business capability typically defines what a business unit‘s purpose is (goals and objectives), its core competencies, and is therefore directly bound to business objectives and strategy. Capabilities provide a black-box view of those things the business can do, i.e. working on business artifacts (e.g. Business Processes, Catalogs).

The business processes and resources involved in providing the capabilities are not exposed (business service orientation). Capabilities aren‘t isolated but form hierarchical value-networks with relationships that materialize the business processes. At a lower level, capabilities are modeled using traditional activity diagrams used for the design and implementation of IT solutions.

The key elements of capabilities-based planning are a conceptual framework, an analytical framework and a building block approach to applying the frameworks.

· A conceptual framework allows for business planning under uncertainty by emphasizing flexibility, robustness and adaptive capability
· The analytical framework provides a way to assess business capability options at the operational level and choose among capability alternatives
· A building block approach allows us to define, develop and test individual capabilities within their own business domains

Capabilities them can be developed and evaluated within smaller architecture domains from phase B to phase D, and then later combined to describe joint forces capabilities in Transition Architectures identified in phases E-F.

Capability Based Planning also revolves around the establishment of the capacity and ability to execute a designated set of generic tasks, bringing enormous help when entering the Opportunities & Solutions and Migration Planning phases. It is an effective way of selling the value of Enterprise Architecture to the business, without being too much theoretical…

You may also find this post as a PDF document on the Integration Consortium website.

TOGAF 9, a new era in Enterprise Architecture

For those who are interested in TOGAF 9, I have written an article for the Integration Consortium.

http://www.integrationconsortium.org/?page=TOGAF9

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)...

Which Enterprise Architecture Framework are you using?

Linkedin introduced recently a new feature: Polls.

I wanted to test that feature and created a poll with the main EA frameworks. Unfortunately, this is limited to 5 and I have not been able to include something like "others" or "proprietary".

Furthermore it is not possible to select several.

If interested, you can access this with

http://polls.linkedin.com/p/13540/ikhnz

Interesting results!

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!

IT Architecture is not Enterprise Architecture

For many years I have observed lots of confusion with some basic definitions such as IT and Enterprise Architecture among other terms. I will not try to define the meaning of Enterprise Architecture by myself (despite I have my own view on this) as this is something being right now redefined by the Open Group (which by the way used to call their events “IT Architecture Practitioner Conference” and changed only recently to “Enterprise Architecture Practitioner Conference”).

Looking at job definitions related to Architecture positions, I have also identified a clear misunderstanding of “who is supposed to be doing what…”. In addition to that, I’m frequently asked “what’s the difference between an Enterprise Architect and an IT Architect”.

First, let’s assume that everyone agrees on the fact that Enterprise Architecture includes

-Business Architecture
-Information Architecture
-Application Architecture
-Technology Architecture

Whatever the framework is.

One of the main differences between Enterprise Architecture and IT Architecture is the Business Architecture. The diagram below explains at a high level the purpose of each layer.

Among other activities, an Enterprise Architect will drive, supervise and review technology diagnosis and assessment activities. He will be an active member for the IT Strategy development, identify opportunities for technology-related improvement based on benchmark data and doing high-level cost benefit analysis-(Contribution to the overall alignment of IT delivery to the needs of the business). He will develop the enterprise architecture artifacts including current state architecture, target state architecture, architectural roadmaps, referential architecture patterns and technology standard. Also I recommend he acts as a solution architect during the pre-project and development phases of an IT program or oversight of future state designs including technology, solution, information and business architecture. Other activities are related to the access to the future state architecture for adherence to target state direction, or validate deviation justification and recovery plans.He may develop and implement training and documentation for enterprise architecture processes, procedures and framework, work with a team, coordinate, review and integrate the deliverables of information and technology architects into cohesive solutions architecture, taking into account the user requirements, technical requirements, etc.

An IT Architect could be an experienced software engineer with experience in cross-platform, cross-regional application architectures. He would be exposed to modern software engineering methodologies, such as object oriented analysis and design, web architectures, design patterns, iterative-incremental software development, test-first. He should also be familiar with the following methods and platforms: UML, J2EE, .NET, relational databases. And finally experienced in documenting and communicating software architecture, including communication to key senior stakeholders in business

There are various definitions of these roles. Most of them are clearly defined in some frameworks, but there are still lots of confusion in the market and among recruiters.

Business Architecture may help to get ISO 9001:2000 certification

The ISO standard is related to the definition and requirements of a quality management system. It helps an organization to operate with increased effectiveness, consistency and customer satisfaction and have the capability to continually improve the management system.

ISO 9001:2000 is based on eight Quality Management Principles which are comprehensive and fundamental rules of belief, for leading and operating an organization, aimed at continually improving performance over the long term, by focusing on customers, while addressing the needs of all stakeholders.

Principle 4 is referring to a “Process Approach”. The standard promotes the adoption of a process approach when developing, implementing and improving the effectiveness of the quality management system. A desired result is achieved more efficiently when activities and related resources are managed as a process.

Product realization is a system of processes by which inputs, such as raw materials or components from suppliers, are transformed through the activities of the organization, such as value added production or assembly operations, into outputs, such as products or components, which meet the needs and requirements of a customer.

Any activity or operation that receives inputs and converts them into outputs can be considered as a process. Almost all activities and operations involved in making a product or providing a service are processes.

When an Enterprise Architecture Committee receives suggestions for strategic changes, they should immediately translate those changes into changes in specific business processes. If the architecture is well-defined, changes in processes will immediately suggest changes in specific applications and databases. There are many definitions of a Business Architecture but they all refer to the definition of processes.

The business architecture is a formal documentation of the lines of business, their support functions and their relationship to each other. After the architecture has been documented, it is systematically analyzed to examine the functions (services) required by business and to align the enterprise technology with those functions.

Companies which have already documented their business architecture (baseline/as-is) may consider to have achieved a great step getting the ISO 9001:2000 certification.

Business Architecture and Capability Modeling

Capability modeling is an emerging technique for analyzing a business and modeling it in terms of its competencies. Capabilities are the building blocks of business. A business capability tipically defines what a business unit‘s purpose is, its core competencies, and is therefore directly bound to business objectives and strategy.

Capabilities provide a black-box view of those things the business can do, i.e. working on business artifacts. The business processes and resources involved in providing the capability are not exposed (business service orientation). Capabilities aren‘t isolated but form hierarchical value-networks with relationships that materialize the business processes. At a lower level, capabilities are modeled using traditional activities diagrams used for the implementation of IT solutions.


The key benefit that capability modeling provides over business process modeling is that it focuses on those elements of the business that are the most stable, and therefore facilitates the alignment with key IT initiatives, especially SOA adoption programs, which can leverage stable business concepts rather than process activities that are continuously evolving.

Outputs of capability modeling activities are direct inputs into the activities of service identification, definition and interface design (SOA).

Modeling effort should be done incrementally, with focus on key business initiatives first.

Capabilities modeling has proven to be particularly efficient in allowing to solve business issues not addressable in other ways. It also eases the deployment of business activity monitoring, providing the insight the business needs to adapt to environmental changes or identify new opportunities.

Modeling of Business Operations (Operational modeling), using UML diagrams:

Based on Business Artifacts (artifact-centered operational modeling), which requires:

• Key Business Artifacts identification
• Artifacts life-cycle definitions
• Business tasks identification (BPMN modeling)
• Repository building for artifacts
• Flow components
  
  

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.

ITIL V3 Demand Management and...Demand Management

In one of my previous post I was referring to the definition of Demand Management and how this related to Requirements management and Project Portfolio Management.

With ITIL V3, Demand Management is part of Service Strategy and does not mean the same!!! This will for sure create some confusion for some people.

ITIL Demand Management’s objectives are to optimize the use of capacity by moving workload to less utilized times, servers, or places…. (Nothing to do with users having business requirements!).

This new process refers to:

• Activity-based Demand Management. Analyzing and tracking the activity patterns of the business process makes it possible to predict demand for service assets that support those services.
• At a strategic level, Demand Management can involve analysis of Pattern of Business Activity (PBA) and user profiles. Each profile can be associated to one or more PBA.
• At a tactical level it can involve use of differential charging to encourage Customers to use IT Services at less busy times.
• Service packages. They represent the value that the customer wants and for which they are willing to pay.

The key elements of the ITIL V3 Demand Management refers to:

o Core/supporting services

o Developing differentiated offerings

o Service Level Packages

o Advantage of core service packages

o Segmentation

Even these concepts may appear no to be crystal clear…

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.

Requirements Management and Enterprise Architecture

I was describing a while ago the relations between Requirements Management and other types of user’s demands.

Let me restate my definition of what that is. Requirements Management is the science and art of gathering and managing user, business, technical, functional requirements, and process requirements within a product development project. The project could be for a new consumer product, a web site, a system or a software application. In all these cases, the five classes of requirements should be represented.

The objective of the Requirements Management activity is to define a process whereby requirements for Enterprise Architecture are identified, stored, and fed into and out of the relevant Enterprise Architecture development phases. As such it forms part of the activities and steps carried out in each of these phases though it is not referred to implicitly in any projects I have managed.

(Requirements Management is also a discipline for both Quality Management (ISO 90001:2000) and Project Management (PMI)).

Target architecture must be based on credible assumptions about future business requirements. Getting these future requirements is not a simple matter of asking business management for them, and analyzing them is not the linear technique used to develop the design for a project. Instead, we have to use a combination of requirements aggregation and scenarios to gather and analyze long-term requirements. This will lead to more credible architectures with appropriate flexibility and evident business value.
For ease of use, it is convenient to think of requirements as belonging to a type.

• Business and Functional requirements

They are the fundamental or essential subject matter of the service or product. They describe what the service or product has to do or what processing actions it is to take.

Business Cases or Scenarios should be used as a useful technique to discover and document these requirements.

Project and Portfolio Management (PPM) addresses the decisions regarding what projects to undertake, with what priority, and in what sequence. Before a project has gone through the necessary requirements definition activities, its scope is based on high-level requirements derived from business drivers, plans, and needs. If these requirements are viewed in isolation, then solutions will be defined in isolation, and they will ignore synergies or dependencies between projects and undervalue foundational projects that provide capabilities that can be leveraged across future projects. Business Requirements also have to be a source for Project Management methodologies.

• Non-functional requirements

They are the properties that the functions must have, such as performance and usability. These requirements are as important as the functional requirements for the product/service’s success.

• Project constraints

These are restrictions on projects due to the budget or the time available to build a product or service.

• Design and architecture requirements

They impose restrictions on how the product/service must be designed. For example, it might have to be implemented in the hand-held device being given to major customers, or it might have to use the existing servers and desktop computers, or any other hardware, software, or business practice.

• Project drivers

These are the business-related forces. For example, the purpose of the project is a project driver, as are all of the stakeholders-each for different reasons.

• Project issues

They define the conditions under which the project will be done. The reason for including them as part of the requirements is to present a coherent picture of all factors that contribute to the success or failure of the project and to illustrate how managers can use requirements as input when managing a project.

• Testing requirements

It is recommended to start testing requirements as soon as we start writing them.
We make a requirement testable by adding its fit criterion. This fit criterion measures the requirement, making it possible to determine whether a given solution fits the requirement. If a fit criterion cannot be found for a requirement, then the requirement is either ambiguous or poorly understood. All requirements can be measured, and all should carry a fit criterion.


Requirements Management and Enterprise Architecture cannot be dissociated.

Some vendors have perfectly understood the need of integrating this, such as Telelogic and the need to share a common metadata repository.

With that solution, there are possibilities to go from requirements, to enterprise architecture, to systems implementation and design, with tightly-coupled, bi-directional integration between DOORS (their requirements management tool), and Systems Architect.

IBM has it’s own requirements management solution but has (not yet) an enterprise architecture solution. This may change with the on-going acquisition of Telelogic, but I haven’t been really able to understand IBM’s strategy yet. Is this only a question of absorbing another market or a willingness to offer a full Enterprise Architecture suite in the Rational catalogue? (Requisitepro being obviously an issue….).

The HP approach seems to be the how to integrate the different application coming from the former Mercury and Peregrine world. HP PPM (and HP Quality Center for testing requirements). Their current approach is to use the Demand management module in PPM to manage business requirement at business level and using the module in Quality Center to specify the requirements at technical level to translate them in test case. Nevertheless, HP does not have any Enterprise Architecture solution.

Invitation to join the Enterprise Architecture Network Group on LinkedIn

I've just started a new LinkedIn Group dedicated to people in the Enterprise Architecture arena. I'm sending this invitation in the hopes that you would be interested to grow the community.

If you work in any of the following domains:

-Enterprise Architecture
-Business Architecture-Business Process Management
-Information/Data Architecture
-Application Architecture
-Technology Architecture
-Methodologies-frameworks :FEAF, DODAF, MODAF, TOGAF, Zachman, Gartner/Forrester (and obviously other frameworks or internal methods)
-IT Strategy
-Corporate and/or IT Governance

If you are:

-CIO/CTO
-An architect in any of the domains above either in the Business or in IT
-Consultants
-Other…

The goal of this group is to help members:

-Reaching other members of the Enterprise Architecture Network interested in any of the listed domains
-Sharing information, problems, solutions, ideas specific to Enterprise Architecture and the domains mentioned.
-Accelerate careers/business through referrals from the Enterprise Architecture Network Group members
-Know more than a name – view rich professional profiles from fellow the Enterprise Architecture Network Group members

This will be a starting point for those who wish to share ideas, network with other professionals, exchange advice. We may consider to use something like the Yahoo groups for interaction or anything else web enabled. Until then, this place should do.

Here’s the link to join:

http://www.linkedin.com/e/gis/36781/1FD7B029687F

I look forward to meeting you online! Many thanks.

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.

Do not invest too much in building your CMDB now!

Interesting enough a few days ago a new version of the CMDB federation Whitepaper has been posted. The list of participants is impressive as we find every key players in ITSM including Microsoft…CA, IBM, BMC, Fujitsu, HP and Microsoft have worked together to propose a standard for federating data from ITIL compliant CMDB repositories. The intention is to submit their achievement to a standard body sometimes this year. For the time being, this is a draft which is reviewed by the main IT Service Management actors.

In this current version, there are explanations how to push or pull information from/to various CMDBs into a main CMDB. These “other CMDBs” are named: MDR, Management Data Repositories. Exchange mechanisms and technologies used to access these MDRs will be based on the SOA stack (HTTP, SOAP, WSDL, XML).

What does that mean concretely?

· In a few months (years?) vendors could sell Service Management solutions with a different metamodel
· Instead of using autodiscovery tools, vendors could provide these push pull mechanisms for companies which already have in place other platforms such as Asset Management systems, or system management platforms, or other inventory systems
· It becomes maybe un-necessary to build proprietary bridges with systems which contain important information to build a CMDB. This could be postponed.
· Vendors which actually come with tactical scenarios such as HP-Mercury with their UCMDB could change their strategy sooner than expected!
· Companies in a CMDB project may have to “migrate” in the future to another approach, based probably on a hub and spoke architecture
· Taxonomy being a key challenge for such a project may impact existing CMDB implementation

Companies which started to build a CMDB should measure the impact of that initiative in the long term with their vendors as the CMDB landscape could change dramatically in the next months.