#bizarch artefacts concept map

This blogpost accumulates my contribution (it is work in progress) into LinkedIn discussion " Business capability concepts map" http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=245602764&gid=84758&commentID=144209821&trk=view_disc&ut=0BMR0Vl690JBM1

The reference blogpost is http://improving-bpm-systems.blogspot.com/2013/03/bizarch-artefacts-definition-again.html  I use the following definition of capability from that blogpost.

capability (noun)
the proven possession of characteristics required to perform a particular service (to produce a particular result) with the required performance.

Version 1 - no processes

1. This version is deliberately simplified by removing the process concept 
2. Showing that output from one service may become input for another - what is the best way? 
3. Some services are implemented via coordination of other services - to be added later 
4. Definition of service and its implementation are in the same concept yet - maybe to separate design-time and run-time concept maps later 
5. Role and people (and other related) concepts are not shown yet
6. Service has only one operation

Version 2 - processes are added

Services and process have a recursive relationship:

• all processes are services,
• some operations (or a very detailed function wrapped by a service) of a service can be implemented as a process, and
• a process includes services in its implementation.

Version 3 - roles and some other concepts are added; input/output, outcome, mission are removed

Version 4 - design-time and run-time concepts

A service provides one or many operation(s). 

Thanks,
 AS

Practical Process Patterns: Customer eXperience As A Process (CXAAP)

Another practical process pattern - Customer eXperience As A Process (CXAAP)

This blogpost is inspired by the sentence "The reason customers use our products and services, is to get jobs done in their lives." from http://bridging-the-gap.me/2013/06/03/designing-the-business-around-the-experience/

This sentence made me thinking about a hierarchy of embedded (in some sense) processes: 
"person's life-as-a-process", 
"person's situation-as-a-process" (e.g. expecting a baby), and 
"person's job-as-a-process" (e.g. buying a bigger car for bigger family).  

Note that I define process (noun) as explicitly-defined coordination of services and/or activities to produce a particular result (see http://improving-bpm-systems.blogspot.com/2013/03/bizarch-artefacts-definition-again.html for more details). Thus the process is not only a predefined order of activities which is repeated many types. There are other variations of process as shown in see http://improving-bpm-systems.blogspot.com/2010/12/illustrations-for-bpm-acm-case.html .

For example, buying any car requires some planning, visiting car dealers, taking a credit, etc.  - a normal process which is unique in each case, but is constructed from some, mainly decision, process patterns (I must write a blogpost about those decision patterns).

Customer-experience-as-a-process - a person who is buying a car acts as a customer for a car dealer. This is a normal selection, trying and negotiation process among two roles. Each role has its own process (or own BPMN pool) and both processes are working together as co-processes. An excellent example http://www.slideshare.net/Olbrich/process-experience-the-coffee-example-2103831 shows what is important to measure in such case.

If your products and services fit better into those processes (i.e. reduce the hassle for a customer) then they will be more attractive for customers.  Potentially, all four mentioned above processes should be taken into account to improve the customer experience.  Then the customer will consider your service again.

IMPORTANT: Ask right questions. For example, a civil architect will ask a customer "Do your parents visit?" "How many kids do you want?" "How long do you want to stay in this place?" and then the architect works with the customer to find the best design that meets the customer needs.

Product-as-a-process (it has the life-cycle) and service-as-a-process are designed, delivered and evolved to fit those four mentioned above processes.

Business-as-a-process or enterprise-as-a-process are taking care to organizing the that design, delivery and evolution.

Unit-of-work-as-a-process is a typical decomposition of "normal" business processes.

Resource-as-a-process - each resource has its own life-cycle; for example a document or business object (BO) as shown below (slide #15 from http://improving-bpm-systems.blogspot.com/2013/04/addressing-security-concerns-through-bpm.html).

Processes must be made explicit and executable to employ the power of processes. An enterprise can do this with its own processes. Person's and customer's processes are still implicit (although they may use some explicit process patterns). Nevertheless, an enterprise should anticipate and maybe model those implicit processes to see how enterprise internal processes fit those external processes (sounds like some variations from  http://improving-bpm-systems.blogspot.com/2010/12/illustrations-for-bpm-acm-case.html maybe useful).


A related post https://www.linkedin.com/pulse/understand-customer-lifecycle-create-impact-melvin-brand-flu

Thanks,
AS

Enterprise patterns: eclipse

This is actually the subclause 5.5 "Making coordination explicit" from my book www.samarin.biz/book

A typical enterprise IT landscape is a set of monolithic interactive applications. Such applications usually have intra-application coordination in a very implicit way. Inter-application coordination is also implemented but in an ad-hoc manner – some changes of data stored in “Application A” should be copied to data stored in “Application B” outside the normal working hours. (Such a data transfer is implemented as a “batch”, i.e. a non-interactive or non-attended application.)

This is data-oriented coordination (see the figure below). Sometimes, an IT unit does not have the full picture of all intra-application dependencies, because they have been established in a decentralised (person to person) and, often, a “quick & dirty” way. The resultant coordination is often a complex “web”, and sometimes it is not clear which business process is affected by which applications or batches. The respect of SLAs requires serious efforts from the IT unit. Maintenance is frequently expensive since the evolution of one application may necessitate the alteration of others.

Data-oriented coordination

The use of control-oriented techniques for intra- and inter-application coordination allows the untangling of these “webs” into several (per business process) explicit cases (dealing with smaller building blocks), i.e. services but not applications, thus making your enterprise business system easier to control and evolve. 

Obviously, monolithic applications were not created for such a radical transformation. Imagine that a working application should be disaggregated into services and the coordination between them to be formally established with an additional tool. In many cases this will be a risky project without any obvious Return On Investment (ROI) and with a lot of resistance.

We recommend introducing control-oriented coordination using a step-by-step approach via the “eclipse” pattern (see figure below). At first, we “cover” only a tiny area of the whole process. Usually we start with the intra-application coordination, because this part of IT is considered as boring and not very rewarding. The first fragment of explicit coordination may be quite primitive; it is a duplication of some existing functionality which is just eclipsed by this process. Then we introduce more and more fragments. With time, we cover bigger and bigger areas by explicit coordination of existing fragments.

Use of the “eclipse” pattern for making coordination explicit 

Step by step, existing applications are transformed into services. We recommend that such transformations be carried out with great care. For example, at first, services should be implemented to copy as closely as possible the existing functionality; they are optimised and refactored only later. Modifications to applications are minimised – by preference, we just switch off some functionality.

And the recent blogpost which relates to this topic is http://improving-bpm-systems.blogspot.com/2013/05/integration-via-bpm-become-friendly-to.html

Thanks,
AS

#entarch basics in "for dummies" style

A fragment from a forthcoming article.

Why Enterprise Architecture? – To take right decisions on evolution

Any enterprise comprises many interrelated parts. Many people work for an enterprise; they must be managed; raw materials must be supplied in time; final products must be delivered as planned; enterprise’s goals must be achieved. All of those parts must be coordinated to work together as one whole. This is no easy because of the natural complexity as there are many interrelated parts with many unknown dependencies between them. Changing of an enterprise to work better, faster and cheaper is a challenge, because the complexity of the future enterprise is unexplored yet. That complexity leads to the high risk of uncertainty in changes.

The world experience shows that architecture is the way to reduce undesired complexity of a system (please, note that any enterprise is a system). Architecture shows in a simple manner the most important parts of a system and relationships between them. The understanding of them enables the evolution of the system as one whole.

The popular example of the architecture concept is civil architecture. A customer contacts a civil architect to present to the customer a solution (in some kind of visual format, e.g. a drawing or a scale model, because the aesthetics are often very important). After approval by the customer, the civil architect works with a general contractor. Figure below shows that an architect is a person who translates a customer’s requirements into a viable plan and guides others in its execution.

Architect works with the both customer and general constructor

Architecture of a small enterprise is comparable with the architecture of a separate building; architecture of a big and medium enterprise should be compared with the urban or city planning. The latter requires thinking about the water, sewer, electricity, and transportation infrastructures between buildings or quarters of a city. An enterprise architect, like a city planner, both frames the city-wide design, and formulates plans for the development of urban and suburban areas.

Enterprise Architecture (EA) [http://www.gartner.com/it-glossary/enterprise-architecture-ea/] is a discipline for proactively and holistically leading enterprise responses to disruptive external forces. EA creates and delivers the actionable knowledge about an enterprise. This knowledge facilitates the enterprise evolution toward desired business vision and outcomes.

How does EA operate? – Facilitating changes

Does an enterprise or a plan behave like “house of cards” in case of changes? Do people endlessly discuss potential changes without coming to a logical conclusion? Do unilateral changes in one department cause problems in other departments? If yes for any of those questions then somebody should anticipate and facilitate the changes.

EA provides: 1) understanding of “operations”, i.e. daily work of the enterprise, and 2) rationale for “transformation”, i.e. changes of the enterprise. What is “transformation” today becomes “operations” tomorrow. The both are equally important and must be considered together.

EA is involved into all change-centric processes as shown in the table below.

Change-centric process	EA acts as	Added value
bottom-up, e.g. business as usual, continual improvements	a guardian of the consistency and integrity	EA estimates the effect (positive or negative) of proposed changes
top-down, e.g. strategy, transformations	a governor to take into account the complexity and impacts	EA finds leverage points (places which bring the biggest improvements)
change-execution, e.g. strategy execution or program implementation	a guide to lead to a desired outcome	EA brings agility, flexibility and transparency

EA makes the knowledge actionable in the change-centric processes. A few examples of typical use of EA will be discussed in the article in more details.

What EA uses? – Artefacts and models

Changes (as a trip to an unknown territory) should not follow the popular “go there – do not know where, bring it – do not know what”. A good trip requires proper instruments, including a map and GPS navigator. EA provides all of them.

EA identifies and describes various constituent parts of an enterprise-as-a-system. Those parts are called artefacts. Typical artefacts are: operational objects, goals, business processes, roles, rules, locations, documents, tools, etc. EA links them in various models (e.g. organisational structure connects organisational units, roles, and people). Models formalise as knowledge the relationships between artefacts. Thus models make this knowledge actionable.

EA establishes rules for changing those artefacts and models as architectural principles, templates, techniques, patterns, and standards. At the same time, EA does not own those artefacts and models. They are owned by various people from the enterprise – stakeholders, CEO, COO, CIO, business process owners, line managers, etc. EA contributes to human capacity by helping those people to understand, create, arrange, interrelate, use, and evolve their artefacts and models.

Variations of architects

Basic type of architect	Primary customer	Plan	Executors of the plan	Comments
Solution architect	Project owner	Architecture of a solution	A project team	Also known as “architecture owner” in agile projects
IT Infrastructure architect	CIO + EA	Infrastructure improvement / modernization / transformation	Infrastructure unit of the IT department	This plan is usually spread over several projects
IT Application architect	CIO + EA	IT Application portfolio improvement / modernization / transformation	IT demand, IT supply (DEV and OPS) units of the IT department	This plan is usually spread over several projects which blend business and IT improvements
Information & data architect	CIO + EA	Information & data improvement / modernization / transformation	Information (business) and data (IT) units	This plan is usually spread over several projects
Business architect	Ideally: COO + EA; Possible: (depending on the maturity of organisation) CIO+EA	Business processes, organisation improvement / modernisation; strategy execution	Business departments and IT demand units	This plan is usually spread over several projects
Enterprise architect	Ideally: CEO; Possible: (depending on the maturity of organisation) CIO, COO	Strategy execution	Divers teams	See "Evolution of the EA function" at http://improving-bpm-systems.blogspot.ch/2014/03/enterprise-patterns-aga.html

Some combinations:
Enterprise solutions architect – solution architect for enterprise-wide solutions
NNN solution architect – solution architect in the NNN domain, e.g. SharePoint

Architect vs project manager

Architect defines a plan.
Project manager executes the plan with the guidance of the architect (for example, a general constructor can’t change the building’s plan without approval of its architect).

A few definitions

Architecture is a fundamental orderliness (embodied in its components, their relationships to each other and the environment), and the principles governing the design, implementation and evolution, of a system.

System is a functional entity formed by a group of interacting, interrelated or interdependent parts.

Artefact is an entity made by creative human work.

Thanks,
AS