Services a discipline

(based on IBM SJ paper)

The following are some notes of interest:

Economic statistics conclusively demonstrate that global economies are increasingly based on information and services, and that demand is growing and exceeding supply for people with the knowledge and skills to be effective workers in this new economy. A consensus is emerging that the cumulative and interconnected innovations in information and computing technology, industrial engineering, business strategy, economics, law, and elsewhere cannot be described and understood by a single academic discipline.

Many of the concepts, techniques, for service design and operations originate in and emphasize person-to-person services. However, they do not fit well when person-to-person services are replaced or complemented by self-service, and hardly fit at all for automated IT services provided by one IT process to another. We might conclude that the word "service", in person-to-person services, service architecture, are homonyms and not try to unify them conceptually and methodologically, but we will make little progress toward a service science if we do not find abstractions that unify them or establish clear boundaries between them.

Many seem to view it as unquestioned dogma that a customer-centric approach is inevitable and essential.However, while a focus on the customer and customer interactions (the front stage) has been shown to contribute to quality in person-to-person services, it is not straightforward to apply the same focus to the design of self-service and automated information-intensive services.

The questions that can be asked about a service science inquire about some activity in the life cycle of a service. We can ask, How is a service: designed, planned, forecasted, specified, provisioned, composed, integrated, deployed, delivered, managed, certified, used, reused, evaluated, optimized, archived, etc.

This list, while far from complete, but illustrates that a very large number of activities or processes could be important parts of the life cycle of a service or set of services. Because services can be people-to-people, people-to-technology (self-service), or computer-to-computer (e.g., Web services), a variety of methodologies apply to the service life cycle. These methodologies partition the life cycle differently, use different words to talk about each activity, and make different design decisions and trade-offs.

When different disciplines and perspectives come together, the outcome is unpredictable. One discipline can become dominant and absorb parts of the others, or the overlapping pieces can break away and form a new field. But if the new field never becomes more than the sum of its parts, it can fade away over time. Occasionally, however, a new and important discipline emerges as a synthetic combination. The multidisciplinary or transdisciplinary character of the transition to a service-dominated economy makes it intrinsically difficult to define what a new, unifying discipline might look like. We might posit that a new and synthetic discipline of service science is desirable, but we should not assume that it is inevitable.

Product Management – Overview and concepts

Product Management – Concepts – circa 2000

Introduction 

My focus has always been on quality, continuous improvement and excellence of execution. Delivering services using well defined approaches[1] is critical to achieving these things. 

Approaches [3] deliver products and services [2]. Each approach has:

• a set artefacts (e.g. deliverables[4]) which there should be templates for and examples of. 
• a process i.e. a sequence of Steps (and sub-Steps), Steps are performed by Roles who use Tools and apply Techniques); 

This ensures services are delivered in a consistent and repeatable way, and assists in classifying artefacts and developing metrics e.g. for Steps, Artefacts, etc.

Highly adaptable approaches which can be easily instantiated[6] and adapted allows for continuous learning. Approaches that attempt to obviate the need for judgement and experience are doomed to failure[7]. Approaches can always be improved and need to constantly be assessed for gaps, areas of improvement, changes in underlying technologies or environment. etc.

Common tooling (and language, notation, syntax and format) is key to effectively getting people using common approaches[8] and managing complexity[9]. Basic modelling that allow elements of types and associations between those elements is fundamental.  Models can be present in many ways e.g. tables, forms, diagrams etc. 

Approaches need to lead by owners who will act as a focal point for ongoing development of the Approach. They will also try and stay abreast of industry and academic developments and assist in knowledge transfer by understanding who is applying the approaches, what they have know and learnt, what they have produced and any problems encountered. Their knowledge will be useful during instantiation and their reviews they highlight where approaches can be improved. 

Approach owners would ideally QA all work done with an Approach until they are confident a practitioner has developed enough experience in the use of the Approach to apply it successfully.

Universal access is critical so that teams of people can work together independent of location. So repositories need to established that are accessible from anywhere (over the internet). All documents of record (e.g. contractual, deliverables and key supporting artefacts should in these repositories.

Critical to improving metrics is understanding the effort associated with each Step, and/or Artefacts[10]. For this reason we favour high level plans (or task lists) and the recording the effort against them. If we don't record how long a class of task or artefact has taken in the past we have no basis for estimating how long it can be expected to take in future.

Approaches can be defined at different levels of detail. There has been much debate regarding the best format for representing the products. What we are trying to achieve is a consistent way of representing approaches. The current view is that products will be represented by:

• Brochure – that summarises the benefits and broadly outlines the approach.
• Presentation – that summarises the approach, its objectives, challenges to be overcome and the steps to be undertaken. 
• Model(s) – process models that provides an overview of process
• Document(s) and/or Wiki – a narrative describing the overall process, sub-processes and discrete steps (often with reference sources, useful tips on techniques, etc.)
• Artefact lists – derived from the approach model (and often presented with default metrics) as a spreadsheet. They may be elaborated in discrete documents.
• Artefact templates – for each artefact/model
• Artefact exemplars – for each artefact/model
• Role descriptions – usually recorded in the approach model (may be elaborated in documents).
• Work template – a simple set of steps and schedule (steps, key dependencies etc.).

Approaches should provide an overview[11] for experienced practitioners. The approaches may be terse and to the point[12]. It is not expected that anyone other than an experienced practitioner, or someone mentored by an experienced practitioner can successfully apply the approaches.

Approach use

When a project is established we will establish a discrete project repository. Copies of standard artefacts templates will usually be put in this repository (its categories, documents types will reflect the areas/steps of the approaches)

Approach model – will be either used as is or adapted as required.

Steps – will be recorded in a plan and each step will be sized and resourced as appropriate.

Work and Artefacts – work will be undertaken and artefacts will be created

Current technologies (i.e. what we should use)

Documents: spreadsheets, word, presentations, diagrams

Models: sets of components that are related

Diagrams: based on models where possible. 

Plans and schedules

Document repositories

Generic communications: email, IM, Wiki, etc.

---

[1] Sometimes called methodologies or processes.

[2] Sometimes called offerings

[3] Typically delivered in the context of a project or assignment

[4] I take a Miessian view of deliverables (i.e. “less is more”) and distinguish work products and deliverables

[5] Examples should be evaluated to see if they represent best practice

[6] The generic roles, artefacts and steps etc. be adapted, amalgamated, or put aside.

[7] Based on empirical experience (e.g. with organisations touting methodologies as silver bullets)

[8] Experience shows that Word document based approaches fail and Systems oriented approaches too expensive and inflexible.

[9] See: The Challenges of Complex IT Projects [British computer society; Royal Academy of Engineering]

[10] Often this is considered impractical in a plan because many tasks relate to many deliverables.

[11] Check lists, handy templates, memory joggers etc.

BPMN processes and pools

n addition to describing the internal process orchestration (or control flow), BPMN can represent choreography (the message exchange between processes). In the real world, an end-to-end business process may be composed of multiple BPMN processes interacting through choreography. A single BPMN process (as opposed to multiple processes) is confined to a pool (i.e. a pool is a container for a BPMN process), is within a single domain of control, and has a start/end (where the process state is changed by a set of activities in the process). The most common reason for multi-pool processes is that an instance of one process does not have one-to-one correspondence with an instance of the other. Unlike traditional process modeling notations, BPMN puts events and exception handling right in the diagram itself, without requiring specification, or even knowledge, of the technical implementation. This business-friendly “abstract” representation combined with precise orchestration semantics lets BPMN process models serve as the foundation of executable process implementations (with implementation properties layered on top of the model, usually be IT).