2015-03-26

Interesting combination of two recent blogposts about #governance and #digital

In the following discussion
http://bpm.com/bpm-today/in-the-forum/do-you-think-the-more-talent-you-have-the-less-process-you-need I used a combination of two recent blogposts.

From the EA viewpoint, the topic of this discussion is the following:
  1. There are two essential enterprise-wide artefacts “talented staff member” and “processes”. 
  2. Are there some relationships between these artefacts? It seems yes.
  3. Are these relationships strong? i.e. a small change in one artefact may strong affect to another artefact? It seems yes.
  4. So, how to achieve synergy between these artefacts? Let us allow talented staff members develop processes which simplify and amplify their work for the best of an enterprise.
  5. Can digital amplify this synergy? Of course! – please follow http://improving-bpm-systems.blogspot.ch/2015/03/entarch-view-on-ditigal.html
  6. Thus it should be some governance around these artefacts? Absolutely! – To read more please follow http://improving-bpm-systems.blogspot.ch/2015/03/enterprise-patterns-ghost.html
  7. Any questions, please?
Thanks,
AS


2015-03-18

Enterprise patterns: GHOST

Enterprise pattern “Govern Handling Of Some Things”

(see also “Enterprise patterns: AGA” http://improving-bpm-systems.blogspot.ch/2014/03/enterprise-patterns-aga.html)

Part of enterprise architecture is about establishing practices (processes and decisions) to govern (or to steer) some domains of enterprise activities. This blogpost provides a generic approach to setup domain governance.

1 Generic approach


Domain governance covers the entire life-cycle of the domain primary-artefacts.

Decompose the whole life-cycle into phases (or stages).

Each phase comprises several primary-artefacts, rules, activities and processes.

Responsibilities to own these primary-artefacts, rules and processes must be assigned to somebody.

Responsibilities to perform these processes and activities must be assigned to somebody.

All these responsibilities are grouped into several roles (under some considerations including “separation of duties”).

Domain stakeholders are assigned to these roles.

Various documents to support primary-artefacts are identified and their life-cycles are considered as well (roles to write, use and approve these documents).

Domain governance makes explicit primary-artefacts, supporting-documents, roles, rules, processes, phases and life-cycles.

Domain governance specifies dependencies with other domains governance practices established in the enterprise.

2 EXAMPLE TW

2.1 Context for Technology Watch function

A typical IT Department uses hundreds digital technologies, tools, products and services from third-party companies to provide highly efficient digital business solutions. There are complex dynamic dependencies between those technologies, tools, products, services, companies and digital business solutions. For example, companies may merge or go bankrupt, products may be discontinued, tools may be exposed to security bridges, new technology may make an existing technology obsolete, etc. All of these may have a negative impact on some digital business solutions or, on the contrary, create an opportunity for improving some digital business solutions.

2.2 Technology Watch (TW) vision and mission

TW vision – timely provisioning IT industry information for decisions related to strategic, tactical and operational aspects of digital business solutions.

TW mission – systematic capturing, analysing, disseminating and exploiting information about used digital technologies, tools, products and services.

2.3 TW governance


TW function operates with three primary-artefacts:
  1. Critical Watch Artefact (CWA) – a technology, tool, product, service, company to be watched
  2. TW-Event (TWE) – a fact of detecting something interesting about a particular CWA
  3. TW-Decision (TWD) – a decision taken for a particular TWT

The relationships between these primary-artefacts is depicted in figure BELOW. Monitoring of a CWA may detect hat something of interest has happened with this CWA and thus to trigger the initial analysis. The latter may lead to a deeper investigation and a decision for dispatching some ITSM processes.

Figure 1

3      EXAMPLE SOA Governance

3.1 SOA Governance vision and mission

SOA vision – considerably speed-up the delivery and evolution of software-intensive digital business solutions.

SOA mission – industrialise the delivery of software-intensive business solutions as a set of autonomous components (i.e. services).

3.2 SOA Governance approach

SOA governance is balancing the demand side and supply side. Some service providers (supply side) may be temporary not consumed. Some service consumers (demand side) may use the same service provider. A service consumer (demand side) may use a few service providers at the same time.

Figure 2 Links between service consumers and service provides

The life-cycle of service demand comprises the following phases: D1. Contracting, D2. Renting and D3. Reviewing.

The life-cycle of service supply comprises the following phases: S1. Planning, S2. Building, S3. Running and S4. Optimising.

3.3 Scenarios for service provisioning

There are three scenarios in the service provisioning.

1. Scenario “sur mesures” or “make-engineer-to-order” - design a new service and deploy; coordination between phases in this scenario is shown in figure below.
Figure 3 Scenario “sur mesures” for service provisioning

2. Scenario “adaptation” or “make-build-to-order“ - tailor an existing service and deploy; coordination between phases in this scenario is shown in figure below.
Figure 4 Scenario “adaptation” for service provisioning

3. Scenario “prêt-à-porter” or “make-build-to-catalogue” - build some services before actual demands; coordination between phases in this scenario is shown in figure below.

Figure 5 Scenario “prêt-à-porter” for service provisioning

3.4 Stakeholders and their participation into the service demand and service supply life-cycles

Demand side roles are:
  • demand initiator, e.g. a Head of Department
  • service consumer, e.g. staff member from a Department
Supply side roles are:
  • service owner, e.g. somebody from the IT department
  • service implementer, e.g. a preferable partner
  • service operator, e.g. a preferable partner or the IT Department (actually, its OPS group)
Governance side role is:
  • service auditor, e.g. somebody from the IT department, EA function or third-party
General participation of various roles in all phases is depicted in figure below (the first pattern for service provisioning is used).
Figure 6 Participation of some roles

The detailed participation of various stakeholders is shown below in accordance with the RACI technique.



service demand
service supply
contracting
renting
reviewing
planning
building
running
optimising
Demand initiator
(demand side)
RA
RA
R
C
I
I
C
Service owner
(supply side)
C
C
C
RA
C
I
R
Service implementer
(supply side)
C
-
-
-
RA
C
C
Service operator
(supply side)
C
C
I
-
C
RA
C
Service consumer
(demand side)
C
I
C
-
C
I
C
Service auditor
(governance side)
I
I
A
I
-
I
A


3.5 Outline of the process

The coordination between the two life-cycles is shown in figure below. The pink numbered markers show the sequence in the control flow (only the “happy” path). The solid arrows are used within each of the life-cycles. The dashed arrows are used between the two life-cycles.
Figure 7 Coordination between two life-cycles

This figure is the base for defining the domain documents and their life-cycles as well (thus governing bodies which approve these documents).


Thanks,
AS

2015-03-16

#entarch view on #digital

A several statements (à la manifesto) about digital from the enterprise architecture viewpoint


Note: The illustration is adapted from http://improving-bpm-systems.blogspot.ch/2013/06/entarch-basics-in-for-dummies-style.html

Business artefacts are available in digital formats (thus formal and executable).

Digital is the master media for business artefacts.

Enterprise, ecosystem and society “understand” the digital formats for business artefacts (not consider digital artefacts as BLOBs).

Enterprise can transmit, protect, validate, enrich, interpret and manipulate digital business artefacts at their whole life-cycle.

Enterprise can generate new knowledge from digital business artefacts.

Enterprise knows all the dependencies between its digital business artefacts (i.e. how a change in an asset affects some other assets).

Enterprise can transform digital business artefacts (extract, combine, change presentation, convert, etc.) to fit the current needs of a particular customer.

Business artefacts can be moved between digital, analog and physical medias (e.g. with 3D printing).

Enterprise can capture the external physical world into its digital artefacts.

Business digital artefacts may be offered for consumers as apps.

People can delegate to "things" (i.e. computers and robots) some routine activities with their business artefacts (e.g. with the use of #IoT)

With the progress of #IoT, "things" become more capable actors of digital business processes ("things" may form temporary groups to cayy out a particular activity).

Digital business artefacts help increasing flexibility of enterprise systems (from www.samarin.biz/book ):
  • All artefacts must be versionable throughout their lifecycle
  • All artefacts must evolve to become digital, externalised, virtual and components of clouds
  • All relationships between artefacts must be modelled explicitly
  • All models must be made to be executable
(see also "Yet another definition of enterprise architecture #entarch and metrics for enterprise architects" http://improving-bpm-systems.blogspot.ch/2014/12/yet-another-definition-of-enterprise.html )

Thanks,
AS