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.

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!

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.