Showing posts with label business architecture. Show all posts
Showing posts with label business architecture. Show all posts

2013-06-14

#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

2013-03-12

#bizarch artefacts definition; again

This post is written for the LinkedIn discussion "Whats the defference between, a Business Capability, a Business Function, a Business Process and a Service?"
In this post, I collected (and refined) several #bizarch definitions from the posts about #bizarch.

activity, noun
elementary or indivisible unit of work

function, noun
abstract and self-contained grouping of activities that collectively satisfy a specific operational purpose

Remark 1: Functions are unique within the enterprise and should not be repeated.
Remark 2: Some functions can be decomposed into smaller groups of activities, and thus the functional view has a hierarchical structure. (Without taking into account that one function may use other functions to accomplish its purpose.)
Remark 3: The structure of functions is not always the same as that of the organisation chart; in many cases, some organisational units can span several functions. Furthermore, organization charts may change while the function does not.
Remark 4: A business function typically has the suffix ‘management’ in its name (e.g. ‘Customer Relationship Management’), but it can also be a noun (e.g. ‘Marketing); usually, function name specifies something that is performed continuously.
Remark 5: The functional view emphasizes WHAT the whole enterprise does to deliver value to the customer (without the organizational, application, and process constraints). Usually, the hierarchical structure of business functions is very static (with a low rate of change).

service, noun
explicitly-defined, operationally-independent, and consumer-facing repeatable unit of functionality that creates a particular result for the consumer

Remark 1: It is considered that there are internal (even within an enterprise) providers and consumers as well as external consumers.
Remark 2: A service may wrap several functions. (In IT, we call them operations.)
Remark 3: A service is self-contained in some extend.
Remark 4: Complex services are created by means of the coordination of more simple services and/or activities (in the same way that an orchestra is a coordination of individuals and their actions). In this sense, an enterprise is a mega-service composed of a network of nano-services.

process, noun
explicitly-defined coordination of services and/or activities to produce a particular result

Remark 1: Processes are HOW of the business.
Remark 2: Services and processes can be considered to be intimately related since in real terms
  • 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. 


capability, noun
the proven possession of characteristics required to perform a certain kind of work (i.e. as a particular service to produce a particular result) with the expected performance

Remark 1: Capability needs to “understand” the mechanics of delivering that service. The mechanics include the resources, skills, policies, powers/authorities, systems, information, other services, etc., as well as the coordination of work within the service.
Remark 2: Capability is named after the expected result/performance (http://ingenia.wordpress.com/2010/10/19/modelling-behaviour/), e.g. “2CV”.

Why do we need all of them? 
Functions is an internal view of an enterprise (or supply-side). Services is a consumer view of functions (or demand-side). Capabilities is a performance view (or matching demand and supply) including both expected and realised performance.

Each service is associated with an owner who is responsible for delivering the promised results in all instances in which that service has been requested. That owner has

  1.  to know/estimate the demand-side needs (the service may have many different consumers who will be using it with different frequencies), and 
  2.  to design/organise/create in advance the supply-side capabilities to ensure those needs are satisfied. 

So, how can one ensure that a service has the required characteristics? There are three control options:

  1. by contract (“re-active” approach) – acquire a service with the required characteristics, use it, check that its performance is acceptable and replace it if something is wrong with it; 
  2. by measurement (“active” approach) – implement a service, use it, measure it, improve or re-build it, etc.; 
  3.  by design (“pro-active” approach) – build a service model, run a simulation test, improve the model, build the service, use it, measure it, improve it, etc. 

The first option works with some support services, the second option can work satisfactorily with lead services and the third option should be used for core business services. The core business services can’t be outsourced, can’t be bought and must not be “damaged”.

One of the models of the "mechanics" of provisioning a service is a business process. The explicit coordination brings several advantages.

  • It allows planning and simulation of the behaviour of a service to evaluate its performance. If that service uses other services, then the demand-side needs for those services can also be evaluated. 
  • It can be made to be executable, thus guiding how work is done. 
  • It allows control that the actual behaviour of the service matches its intended behaviour, thus pro-actively detecting potential problematic situations. 
  • It allows the measurement within a service of the dynamics of different characteristics, e.g. valuing, costing, risk, etc.
Thus a process is a way to guarantee a capability of a service to perform a function.



And architects are responsible for this how (see http://improving-bpm-systems.blogspot.com/2013/03/architects-are-responsible-for-how-thus.html).

Thanks,
AS

2009-09-29

Linkedin: Business Architecture Governance

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=84758&discussionID=6834576&commentID=6935305#commentID_6935305" />

A very good list from Michael to which I would like to offer a few additions
a. (explicit) list of events important for the subject
b. audit trails pertinent to the subject
c. (explicit) KPI of how good/bad the subject is governed


And a general comment -- it seems to me that for the implementation of the governance it may be practical to consider such an implementation as a BPM system (not a BPM suite - see the difference at http://improving-bpm-systems.blogspot.com/2009/04/should-we-consider-third-forgotten-bpm.html). I noticed many similarities between this list and recommendations on how to implement a BPM system.

Thanks,
AS

2008-12-07

LinkedIn: What is the difference between Enterprise Architecture, Business Architecture and the various other "X Architecture" names, interpretations

<question group="Business Architecture Community">

What is the difference between Enterprise Architecture, Business Architecture and the various other "X Architecture" names, interpretations and approaches?
Q1
Is there a difference or is it just semantics, causing confusion because of different naming conventions and promotion of individual view?

I have personally used "Business Ecosystem Architecture" and "Symbiotic Architecture" to define through naming a difference in my own approach, always with a very heavy emphasis on it being a business (executive) driven requirement.

Following the above...
Q2
Should Business Architecture refer to:
- Business strategy dimension for EA
- Business processes that aligns with EA (TOGAF)
- Integrated operational ecosystem model
- Whole-of-Enterprise
- Symbiotic relationship design
- Your suggestion here…

</question>



From my definitions...

enterprise architecture, noun
coherent and proven set of principles, recommendations, rules, practices, and tools which provides guidance and practical help for the design and evolution of IT and business to achieve enterprise vision and strategy

Remark 1: Examples of business vision and strategy are a higher level of maturity, a greater agility, better collaboration, merging, cost cutting, modernisation of legacy applications, outsourcing of a business unit, etc.

Remark 2: Some parts of enterprise architecture are dedicated to different stakeholders.

Remark 3: To guarantee the desired outcome, enterprise architecture needs to be as good as applied science.

enterprise business system, noun

top level view of an enterprise as a system for conducting the business

Remark 1: This top level view may concentrate on how the business is structured, what it does and what it needs to do to meet its goals.

Remark 2: The issues of greatest importance for enterprise business systems are the following:
• the core end-to-end business processes (also known as value streams);
• the governance structures;
• the core business information (semantics);
• the communication with the core business partners.

business architecture, noun
that part of enterprise architecture concentrating on the conceptualisation and evolution of the form and structure of the enterprise business system


Thanks,
AS