Enterprise Architecture Handbook part 3

What is the purpose of the organization?

Taking a system approach on enterprise architecture can be viewed as daunting task but at the same time it can be something very exciting that’s worth the endeavor.

When talking about architecture there is the danger of jumping immediately to value chains, processes, IT, customer channels, before get to understand what is purpose of the organization you are trying to architect. That is not understanding only about company vision and mission (the WHAT) but the HOW. How the reason of the organization is implemented? How stakeholders are serviced (we will come back to the services quite shortly).

Hence an recovering the system thinking approach based on Viable System Model (VSM) the first thing you look for is to System 5.

Under VSM, System 5 has a profound strategic intent. This the land of:

  • Organization strategy;
  • Strategic objectives;
  • Strategic objectives initiatives;
  • Strategic objectives goals.

And makes the balance between the assessment of present and the future of the organization. This is here adaptation is born. This is where the WHAT is defined and for that, it uses the channels coming from system 4 and system 3 (I’m not going to waste on time on VSM structure) that measures external environment and the guts of the organization (for the dimensions that makes part of the scanning process I refer to in this post).

Dangers, perils and caveats about starting on strategy

In order to start thinking and designing the HOW, how organizational operations can be implemented and deliver the purpose of the organization, it’s necessary to define the organization services, because business processes (the operations) realizes a service. Once the organization does not operate without business processes, it’s critical to define the service catalogue.

What is an organization service?

Archimate poorly defines the concept of a service and gets fuzzy between what it calls a business function and business service (for the sake of the reader these series of posts are not about criticizing Archimate, but once this an enterprise architecture modeling language and models are an abstraction of reality and help us to understand that reality it’s important to setup a guidance about how it can be better used under my experience and perspective).

According to the version 2.0 there are two abstraction layers of services

Business Function – “A business function is defined as a behavior element that groups behavior based on a chosen set of criteria (typically required business resources and/or competences)”.

The name is pretty bad because semantically speaking is close to organizational function, contributing to create siloed viewpoints of organization departments and killing what can be an effort understating flows and interactions across the organization.

Anyway, further in the spec it states:

“A business function may realize one or more business services and may use (internal) business services or application services.”

Hence the reader is understanding where I’m coming from, it’s the concept anything as service (IT / SOA / Internet of things), but more than that is that is missing that services, as the operationalization of organizational strategy.
When you jump into the definition of business service, Archimate, puts it this way:

“A business service is defined as a service that fulfills a business need for a customer (internal or external to the organization).”

Further it states:

 

“Business service is realized by one or more business processes, business functions, or business interactions that are performed by the business roles or business collaborations, respectively.”

And finally (please be patient we will reach there):

“A business service is associated with a value”.

This is one of the most important focus an architect should look when arriving VSM’s System 1 land. Value as defined in the standard it has the same meaning of result and the value / result is what is perceived by the stakeholder.

What value /result stand for in terms of business process management?

  • The customer wants to feel that he is insured, rather than receive an insurance policy;
  • The customer wants to feel that it got the best interest rate and a flexible loan, rather than money to buy a house;
  • The customer wants to feel that the refrigerator keeps the food safe and reduces energy consumption, rather than buying an energy efficient appliance.

Values / results is what organizations should put the HOW working for, beyond the perceived value / features of what are offering in the era that the customer is dictating and taking command and control of operations. Instead of thinking that the supply chain can deliver as an output (what the customer does not value) of 3 days to deliver an order it should be focused in delivering as a value / result of the next day after order confirmation (what the customer wants).

Hence keep the aim in the value, because the services, must act as a hinge between strategic objectives and the value the organization has to offer. For that, start using Archimate’s Business Function viewpoint.

I’m going to change a little bit the definition of Archimate:

“The Business Function viewpoint shows the high level business services of an organization and their relationships in terms of the existing flows (information, value, capital, goods etc) between them. Business services are used to represent the most stable aspects of a company in terms of the primary activities it performs, regardless of organizational changes or technological developments. Business services delivers value to a stakeholder”.

This the reason you need first to identify the business services (before jumping into business process architecture) the strategy translation into operations, implemented by VSM’s system 3.

The header of this section setup a direction about the dangers of making the translation of strategy into operation. Despite strategy deployment can be mature in the organization you are architecting, bad strategic direction result in bad operation:

  • Scanning the environment does not detect rising new business models emerging from nowhere with reduced capital to a competitor make the incorporation (information technology); disruptive business models (Zipcar); next generation products (health care, green business);
  • Organizational analysis done wrong. Do not understand what are the core and distinctive competencies, what it’s the business model, is the business model aligned with market expectations in terms of competiveness (products have the features customers wants at a price the customer is willing to pay for).
  • Does strategy formulation done correctly in terms of:
    • Directional strategies (growth, stability, retrenchment);
    • Competitive strategies (cost leadership, markets the organization is in or stakeholders is serving).

One thing is making an AS-IS assessment and you find that there are disconnections between strategy and services, other thing is you making an AS-IS assessment based on wrong strategy assumptions. If you do not master strategy planning and deployment, put in the architecture team strategists. Just cross talking with managers is not enough.

The danger of putting labels on services

Since the beginning of my journey in BPM, I never liked the way BPM frameworks, labeled, coined processes. Typically there where (I use the verb is the past because I stop using it, despite it still exists):

  • Management processes – “Management processes are used to measure, monitor, and control business activities. Management processes ensure that a primary or supporting process meets operational, financial, regulatory, and legal goals”;
  • Primary processes – “Primary processes are end-to-end, cross-functional processes which directly deliver value to customers. Primary processes are often referred to as “core” processes as they represent the essential activities an organization performs to fulfill its mission. These processes make up the value chain where each step adds value to the preceding step as measured by its contribution to the creation or delivery of a product or service, ultimately delivering value to customers”;
  • Support processes – “Support processes are designed to support primary processes, often by managing resources and/or infrastructure required by primary processes. The primary differentiator of support and primary processes is that support processes do not directly deliver value to customers, while primary processes do”.

All definitions provided by ABPMP CBOK.

There are two problems with this kind of approaches:

  • First, no one like to be involved in support processes (you do not provide value) or even in primary processes when you are talking with process managers coming from management processes (you are coming from operation – blue collar). Hence labeling has a pejorative sense;
  • Second, what today can be support tomorrow can be primary. Imagine the organization excel on procurement (today a support process) and tomorrow it creates a new business unit (changes to primary). Yesterday business was static, labels perpetuated itself, today is the “you blink, you lose” era.

The same apply with services. Don’t label it. Just create and manage the catalogue to serve the organization and start working in the HOW. Remember you need services to start thinking into business processes.

Creating the service catalogue is matching organization strategy with realized value. The key to ensure you catalogue is correct is cross check if all services al realizing an organization objective and you don’t have strategic objectives / services unattended.

Services need to provide value / outcome. Otherwise they are just filers or satisfy the whim of someone else.

As an example here are the high level business services of a nonprofit organization (and we are still very far from processes and IT).

 

Business Function Viewpoint

Business Function Viewpoint

Advertisements

3 thoughts on “Enterprise Architecture Handbook part 3

  1. Pingback: Enterprise Architecture Handbook part 4 | End to End BPM

  2. Pingback: Viable System Model meets Enterprise Architecture | End to End BPM

  3. Pingback: IT Services are not a function of physical assets anymore | End to End BPM

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s