Help SME becoming #digital

The last from 3 presentations about #digital #transformation.


Thanks,
AS

An example of architecting #digital transformation

An example for an SME (Small and Medium Enterprise).

Architecting digital transformation v1 from Alexander SAMARIN

Thanks,
AS

Incremental transformation to #digital (explicit and executable) processes

All business processes within an enterprise form a complex structure. Everyone heard about hierarchical (pyramidal) structures of business processes with an enterprise.

In one extreme, it is recommended to model all business processes within an enterprise and then start to improve them (which a good deal for consultants but didn’t help to the majority of enterprises). In other extreme, it is recommended to implement many small process-automation projects. 

This blogpost is about a balance between these two extremes.


Used link:

• http://improving-bpm-systems.blogspot.ch/2014/03/enterprise-as-system-of-processes.html

Thanks,
AS

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

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

Enterprise patterns: AGA

Enterprise pattern – Architecture Governance Anchor (AGA)

This pattern addresses a typical problem – where to start Enterprise Architecture (EA) governance in a practical way without “boiling the ocean”.

Illustration below is used as an anchor. It considers that a typical EA function has to have an EA tool which is populated with various EA artefacts to provide the EA knowledge repository to its “users”. It is supposed that the EA knowledge repository will improve the decision-making related to all modifications within an enterprise. For example:

• Formal project management process.
• Informal project delivery practices.
• Corporate-wide strategic programmes, business strategy and its execution.
• Continual process improvements.

Governance challenges

The typical architecture governance challenges are at the interfaces as shown in illustration below.

1 The EA function may be involved in some “very important” projects but the EA engagement into all IT-related projects is not systematic neither systemic. As the result, some IT solutions and tools are unknown to the EA function or the EA function is dealing with them in the post-factum manner not up-front.

2 Although the EA is a unique corporate function which, potentially, must holistically covers the breath (all business units) and the depth (strategy to execution from the business to IT) of the enterprise, the potentials of the EA may be not unleashed yet. Usual practices in the IT-related decision-making do not take into account the EA function, especially in “shadow IT” and some IT tool-centric groups.

3 Being a guardian for the coherent transformation of the enterprise, the EA function should be an entry point for any IT-related changes now and an entry point for all business and IT changes soon. All changes, ranging from strategy to BAU projects should involve the EA function to guarantee the feasibility of changes and their optimal execution.

4 Is the EA function equipped with tools that are adequate to its current challenges (primarily the undesired complexity of the IT landscape)? Can an EA tool handle the following:

• complete nomenclatures of the EA artefacts (solutions, processes, business functions, applications, services, roles, rules, data, capabilities, etc.);
• validated dependencies between the EA artefacts (e.g. which business functions used in a particular business process);
• established procedures to maintain the EA repository (e.g. it is updated at the end of a project) and
• descriptions for proven and ready-to-use solutions.

Without this information, it is impossible to estimate the impact of changes. Also reference architecture and available solutions are not known to project teams.

5 The efficient delivery of the EA function is about making the EA knowledge:

• available (complete, up-to-date, and logically organised),
• understandable (detailed instructions and expert support on demand),
• actionable (linked to change processes to be used by the business and the IT department without systematic involvement of the EA staff members).

Thus, the EA function will be perceived as a facilitator of changes.

6 Gartner recommends that the EA team should be about 1-2% of whole IT staff (for IT organisation of 1 000 – 5 000 people). Estimate if the EA team is adequately staffed.

7 The set of available competencies in the EA function may be at its initial level. In particular, typical missing competences are: business architecture, process architecture, cross-domain architecture and SOA (see as well http://improving-bpm-systems.blogspot.ch/2014/03/enterprise-patterns-ear.html ).

8 If the users are not happy with the typical IT deliverables (develop something unformed and impose it to everyone) then maybe EA can offer something more adaptable to various needs of different users to make the diversity efficient.

Example of work items to improve the governance

The mentioned above governance challenges have to be analysed and prioritized. Potential work items to address some governance challenges are shown on illustration below (those work items are labelled stars).

The work item A is about obtaining the better input from projects. This allows avoiding duplications in the development (potential technique - http://improving-bpm-systems.blogspot.ch/2013/02/linking-business-strategy-and-it.html ).

The work item B starts to handle various EA artefacts (primarily processes, business functions, applications and capabilities) and relationships between them.

The work item C is adding some missing expertise into the current EA team.

The work item D is the selection of an EA tool which can handle all EA artefacts and produce various views (e.g. project, business unit, application portfolio, etc.)

The work item E is about improving the interface between the EA function and the project management processes. EA provides some tools and techniques to simplify project execution, for example:

• evaluation check-lists,
• templates for mandatory documentation (business case, architectural dossier, etc.),
• “as-is” EA artefacts and relationships between them,
• macro-planning,
• clear rules for approval gates.

The work item F may combine diversity and uniformity (potential technique -http://improving-bpm-systems.blogspot.ch/2013/09/enterprise-patterns-anisotropically.html ).

Evolution of the EA function

Logically, the EA function has to “expand” its influence step-by-step.

1. Staring from the IT domain and making it in order (EA is under the CIO)
2. Moving up-stream and helping to address operational issues (EA is under the COO)
3. Ideally, reaching the strategy level, EA function is enabling the execution of the corporate strategy (EA is under the CEO).

     

Thanks,
AS