introduction to productivitycentre - fujitsu...

Macroscope is a registered trademark of Fujitsu Consulting (Canada) Inc.

© 2012, Fujitsu Consulting (Canada) Inc.

Introduction to the Solution domain

How to support the entire lifecycle of information systems

from a business solution perspective

Version 5.0 June 2012

Macroscope® Introduction to the Solution Domain

Introduction to ProductivityCentre ii

OWNERSHIP NOTICE

This document is proprietary to Fujitsu Consulting (Canada) Inc. Any unauthorized reproduction,

modification or transfer of this document is strictly prohibited.

Macroscope® is a registered trademark of Fujitsu Consulting (Canada) Inc.

Fujitsu® is a registered trademark of Fujitsu Limited.

ProcessUnifier™, and Results Chain™ are trademarks of Fujitsu Consulting (Canada) Inc. All other

product brand names are the trademarks or registered trademarks of their respective companies.

© 2012, Fujitsu Consulting (Canada) Inc. All rights reserved.


Introduction to ProductivityCentre 1

Table of Contents

1. In a Nutshell 2

2. About the Solution Domain 3

3. Method Structure 4

4. Lifecycle Configuration 6

5. Lifecycle Stages 8

6. Fundamental Principles 9

7. Why Use Solution? 11

The masculine form is used in this guide for the sake of convenience.



1. In a Nutshell

About the Solution Domain

The Solution domain is an integrated approach to help you efficiently

envision, design, assemble, deliver, operate, and evolve information

system solutions of all kinds throughout their lifecycle.

Primary Audience

Business owners and managers of the solution

Solution architecture team members

Business analysis and design teams

Technical specialists

Business transition teams

Secondary Audience

Any person involved in the delivery, operation, improvement or

retirement of solutions.

Applicability

The approach is adaptable to a large range of information system

solutions, whether comprising high or low level of IT, simple system

to complex multi-system solutions, mission critical or not.

About this Document

This guide will facilitate your navigation within Macroscope by

answering basic questions you may have about the approach such as:

what it is, how it is structured, why use it or what are the fundamental

principles I need to know.

Prerequisites

Familiarity with the Macroscope framework, or

Introduction to Macroscope



2. About the Solution Domain

Why Solution?

The key object of interest of this domain is the solution. In fact, a

more descriptive title would be:

How to support the entire lifecycle of information systems

from a business solution perspective

Why not SDLC?

If S and D respectively stand for Solution and Delivery, and assuming

that LC means Life Cycle, then yes, SDLC would be an appropriate

acronym for this domain.

Why not System?

The word System is too generic and often relates to Software Systems

or Computer Systems.

It is about Information Systems

The Solution domain focuses on Information System, which can be

defined as an organized set of resources and processes, comprising

both automated and non-automated tasks that deliver a given set of

products and services for an organization.

An information system, encompassing human, financial, information

and technological resources, should not be confused with software.

Quite naturally, information systems will rely in most cases on

software systems or components.

While the behavior of an information system is defined by the

business processes it supports, its semantic structure is often aligned

on information subjects of interest to the business.

It is about Business Solution

The Solution domain processes revolve around designing,

assembling, delivering, operating, and evolving information systems

of all kinds throughout their lifecycle.

The context of its application however is about the changes required

to be implemented to solve a particular set of business problems or to

create a new or enhanced business capability within a given period of

time, under a number of constraints, and with the appropriate level of

quality.

This requires an integrated approach as it must address aspects related

to business, work processes, technology, people, organization and

transition, as well as software.



3. Method Structure

From a structure perspective, as with all other Macroscope domains,

the Solution domain can be viewed as a collection of Deliverables

(Work Products), Roles, Techniques, Fundamentals and Concepts

orchestrated by a defined Process.

Key Concepts

Limited set of well-defined terms specific to the Solution domain.

Helps standardize the terminology and contributes to clear and

unambiguous communications among all concerned. These concepts

are a subset of a rich glossary available throughout Macroscope.

Processes

Set of activities structured into steps, phases, path or stages. Solution

proposes number of typical processes, presented in the previous

section, which may be used independently, partially or configured

into composite processes, to deliver a particular outcome or service or

to solve a particular problem.

Deliverables

The Solution domain proposes five sets of deliverables:

Base Delivery: typical deliverables used in solution delivery

projects.

Agile Delivery: re-configured deliverables for typical agile

projects.

System Operation: deliverables specific to operating an

information system.

System Improvement and Maintenance: deliverables specific

to information system maintenance and improvement.

Configuration Management: deliverables specific to

configuration management throughout the solution lifecycle.

http://fabok.fc.fujitsu.com/DMRHomeEn/Html/En_KeyConcepts.html

http://fabok.fc.fujitsu.com/DMRHomeEn/Html/En_Processes.html

http://fabok.fc.fujitsu.com/DMRHomeEn/Html/En_Deliverables.html



The various deliverable types are grouped according to the major

facets or preoccupations of business and IT development. For

example, the Base Delivery set of deliverables is organized as

follows:

Requirements

System Architecture

System Specifications

Quality

Organizational Change Management

Project circumstances and characteristics of the problem domain

determine which deliverables are required. The extent to which each

deliverable is developed varies from project to project.

Roles

Each potential role is described in terms of roles, responsibilities and

required skills set.

The roles are organized into multi-disciplinary groups or teams, each

focusing on an important aspect of the implemented solution

lifecycle.

The structure and functional titles are usually adjusted to the

circumstances where they are used. For example, in many

organizations, the system architect is called solution architect. The

name is not important - the roles and responsibilities are.

An individual may perform more than one role, depending on the

context. The extent to which more specialized roles may be required

depends on the circumstances. For example, in large projects, the

system architect may be assisted by specialized roles such as:

information architect, user interface architect, database administrator,

etc. In smaller or simpler projects, all these roles may be entirely

assumed by the system architect.

Fundamentals

Fundamentals describe the basic principles that underpin the whole

approach.

http://fabok.fc.fujitsu.com/DMRHomeEn/Html/En_KeyRoles.html

http://fabok.fc.fujitsu.com/DMRHomeEn/Html/En_1203_100_OPD.html



4. Lifecycle Configuration

It is imperative to adapt to the situation at hand

No two organizations have the same needs. No two projects take

place under the same circumstances. No two solutions have the same

characteristics. Applying a process blindly without taking these

aspects into consideration increases the risks of over-engineering,

over-documenting and, ultimately of project failure.

The context and the outcomes to be achieved should always be

considered first, and then the appropriate method elements are

selected on that basis and adapted as needed.

No cookbook process or buzzword magic

The Solution Lifecycle covers all stages of a solution from the initial

idea through its operation, and eventually, its disposal.

You won’t likely find lifecycle qualifiers such as cyclical, iterative,

spiral, waterfall, just to name a few, within the Solution domain.

Throughout its lifecycle, a multitude of iterations or cycles will be

necessary to initially create and then evolve the solution according to

evolving business or technical requirements.

Each of these cycles usually takes different paths depending on the

nature of the change or evolution, the characteristics of the project,

the skills and resources available, the availability of stakeholders, etc.

Hence, a multitude of lifecycle configurations might exist even within

the same organization.

A lifecycle will use various delivery processes

In Macroscope, the Solution home page highlights three typical

lifecycle configurations named after the main delivery process used:

Base Delivery: for any type of solution, unless there is a more

suitable process available. Highly adaptable from the simplest to

the most complex project situations.

Agile Delivery: when project characteristics, stakeholder’s

implication, resource skills and organizational culture lend

themselves to an agile approach.

Package Solution Delivery: when the dominant use of package

products and services contributes to the carrying out of the

change.



Gradual delivery through iterations and releases

The notion of gradual implementation of changes within the business

has always been a key practice of Macroscope. Whatever the delivery

process, the notions of iterations and releases are assumed throughout

the various representations of the lifecycle as illustrated below.

1. A release is a coherent, working and useful sub-set of the total

solution. Release content, size, sequence or timeframe are

determined according to manageability, business priority,

capacity to absorb change, etc. A release can contain revised

functionality that was previously implemented.

2. Iterations are sometimes referred to with terms such as sprint,

sub-release, micro release or prototyping cycle. An iteration

delivers working functionality, demonstrable to the client usually

in a fixed time period.

3. These notions of iteration and release apply as well to the

maintenance process.



5. Lifecycle Stages

The typical solution lifecycle presents six stages illustrated below.

Each stage delivers specific results and can be achieved by one or

more, or a combination of process paths.

Stage/Process What is achieved Results

1. Opportunity Evaluation

Develop the vision of the problem space and its potential solution, and determines if further analysis is warranted.

Overall definition of the change to be undertaken. Project proposal for the next stage.

2. System Delivery

Choice of paths such as Base, Agile or Package Solution.

Design, architect, develop and implement a new information system or a major reengineering of an existing system.

Information system successfully implemented in the business environment.

3. System Operation

Provide user support, and ensure that systems in production are operated and maintained in conformance with their service level agreement.

System and service level performance achieved and improved. User requests, incidents and problems addressed.

4. System Improvement

Validate, approve and prioritize change requests for information systems in production. Integrate them into planned maintenance releases, or schedule them for rapid implementation (urgent change). Monitor and validate maintenance work once implemented.

Change requests processed from reception to closure. Implementation of urgent changes and maintenance releases planned, monitored and validated.

5. System Maintenance

Deliver a maintenance release or an urgent change. Maintenance covers fixes, corrective changes, technical or functional improvements.

Urgent change or maintenance release successfully implemented in the business environment.

6. System Retirement

Orderly shutdown and archive obsolete systems. Migration carried out. Obsolete system archived.

http://localhost:50/DMRPEn/Html/En_P_41_99_35_PTH.html




http://localhost:50/DMRPEn/Html/En_P_182_99_PTH.html

http://localhost:50/DMRPEn/Html/En_P_182_99_PTH.html





6. Fundamental Principles

Delivering information systems, understood in its broad Macroscope

definition, is a difficult endeavor. Over the last decades, however,

practitioners have identified a number of key practices, basic ideas or

approaches, which have progressively become the fundamental

principles for the Solution domain.

As the name says, these principles, summarized below, are

fundamental to the success of a project. While trade-offs are usually

necessary when adapting the processes, the deliverables and the

techniques to the specificities of a project, no compromise should be

made to the application of these principles. Missing one of them is

often the cause of project failure.

Adapt the Method to Your Context

Applying a process blindly without taking project circumstances into

consideration increases the risks of over-engineering, over-

documenting and, ultimately of project failure.

Maintain Focus on Business Value

The ultimate criterion for every decision, regardless of the nature of

the task or the phase of the project, should be "will this decision,

investment or action, contribute toward the expected business value?"

Balance Delivery Perspectives

There are natural yet healthy tensions between business needs to be

satisfied, resources required to deliver the change, and the quality of

the solution to implement.

Maintaining an optimum balance among these three delivery

perspectives throughout the entire project or program is crucial for

delivering the right business solution.

Distinguish Solution Perspectives

Three main perspectives mutually influence each other and must be

considered concurrently throughout the solution lifecycle. They are:



Owner (business) perspective - provides the business needs

for the solution;

User (functional) perspective - defines the expected behavior

of the solution;

Developer (technical) perspective - represents the technical

choices to implement the solution.

Apply Concurrent Engineering

Although the major phases of a project are usually executed

progressively, different aspects and levels of detail of the problem

space and of the required solution must be considered simultaneously

and iteratively throughout the process. For example, technical

feasibility or opportunity considerations may need to be dealt with

early in the project while the business requirements are still

developing.

Produce Tangible Results

Progress is measured by tangible results. Break down the work into

small, manageable and controllable pieces. These deliverables or

“work products” become visible results allowing the team to measure

progress objectively.

Deliver Change by Releases

While time to market is often a critical factor, change is seldom

feasible in one chunk. Change strategy needs to take into account

business priorities, the urgency of the change, the magnitude of the

change effort, the organization's history of successful change and the

organization's readiness to change. These factors usually call for

delivering change in small manageable chunks, or releases.

Use a Systemic Approach

Introducing change into an organization is often a multidimensional

endeavor. Viewing the organization, its components and its

environment as a system provides a framework for considering all

significant dimensions of the organization in a holistic and structured

manner.

Aim for Flexibility, Agility and Reusability

To adapt rapidly to constantly evolving needs, organizations must

adopt strategies that make them fast, agile and flexible. As much as

feasible, the approach should apply just-in-time and just-enough work

methods, and design with a reusability focus.

http://fabok.fc.fujitsu.com/DMRPEn/Html/En_P_1230_99_OPD.html







7. Why Use Solution?

A proven approach

Solution is a well proven set of processes that has been successfully

used by a number of organizations, in many different contexts, to

efficiently deliver changes related to information system delivery or

maintenance, and to achieve the expected benefits in a concrete and

timely manner.

What makes Solution efficient?

Solution (formerly called ProductivityCentre or sometimes P+) has

evolved over the years, always taking advantage of the best practices

and trying to simplify as much as possible the approach to change

delivery, while staying reliable and complete.

Essentially, the advantages offered by Solution are:

• Flexible processes that considerably streamline the approach to change delivery and system operation and maintenance.

• Solid principles such as: – Concurrent consideration of the owner, user, and developer

viewpoints – An iterative and incremental approach to better control the

risks – An integrated approach that addresses aspects related to work

processes, technology, people, and transition, as well as software architecture and components

– Projects centered on tangible and well-defined deliverables so that the process is made visible and easier to manage, and the focus shifted away from procedures and directed toward results

• In-depth reference material, techniques, tools, examples, and learning components to support the processes.

• The possibility to use processes from other Macroscope domains to complement certain aspects related to the change (for example, to define an optimal set of capabilities for the enterprise).

• A clear definition of roles and responsibilities so that there is no confusion about who should be involved and how. For example, it is important that the users take an active ownership role in projects to ensure delivery of the required results.

• Sound project management and business system management (the user part) concepts.

With all this in hand, Solution can certainly help you to succeed in

delivering change!

introduction to productivitycentre - fujitsu...

Documents