Enterprise Architecture Handbook part 4

In Part 3 of this essay series on enterprise Architecture, we reflected on defining the purpose of the organization. What the organization does or should do, taking into account the pair Vision / Mission . The next logical step is the definition of the value chain, the set of processes necessary to deliver results to stakeholders in the form of value. I’ve written before about the importance of distinguishing between the output and result that is perceived by the customer as value when a process is executed, however it is worth recalling the concept because recognizing this formalism is the difference between operations that are geared towards what customers want or what managers claim. There is a big difference. Here are some classic examples:

  • An organization with a customer base exceeding 10 million who made an effort to shorten the complaints processing time from 7 to 5 days after the regulator changed that particular service level agreement (output), but customers want the answer to be given in 3 days (results) and in some cases the decision should be made automatically if the customer provides all the necessary elements to make a decision, based on a paradigm of self-service or in the case there are shared digital data between the client and the organization, that allow an immediate decision based on rules  of commercial or technical nature defined in the contract.
  • An insurance company with which celebrates an insurance policy (output) or the client feels in fact insured, because after an accident, the insurance company legally defended the client, assured mobility or health care after an accident (result).


Defining Value trough Services - Professional Association

Defining Value trough Services – Professional Association


To build a value chain, it must be defined first the services of the organization, what the organization is the “WHAT”. For each service there must be a process that “realizes”, operationalizes the service. Before going into details, make a reflection on what should be the organization or in order words, the State. As you know, the Portuguese State, as well as Irish and Greek States were under a program of direct aid from the IMF and the European Union (Spain was supported indirectly by injecting capital into banks and restructuring of an obsolete business model through the merger of a number of small local banks called “Caxas”). During the financial aid program, it was attempted by the government (I’d say it was only a formal act, poorly done, that public opinion never cared about that) to create a script on the reform of State. In this script, the focus was the balance between a minimal state and a state where everything is public, from a state where education to health care is provided by private companies and citizens have to pay for it in exchange for less taxes or the same services are public, universal, free, which implies an increase of the tax burden. It is precisely this type of exercise that organizations have to do about the “WHAT “. What services are necessary to deliver value (results) to the customer.

The definition of the value chain is based on several important principles :

  • There should be a value chain for each line of business, however, some of the services / processes may be shared (the true principle which should be behind the creation of shared services rather at the expense of “fashion” / hype initiative because it’s been writing about it in management magazines). For example, a conglomerate that is in engineering and construction, waste treatment and renewable solar energy business, should have 3 distinct value chains. Processes such as Procurement and Recruitment should be shared with some variations according to the specific business line of business. Creating multiple value chains, based on the cybernetic principle of recursion, the organization as a system, is itself constituted by other organizations.
  • Each service must be supported by at least one process . If there are services that are not supported by processes, means that perhaps have no reason to exist (you have organizational “fillers” or you are not defining correctly the value chain).
  • Do not try to “fit” value chain models in your business . Although models such as generic SCOR eTOM, APQC are a starting point to reflect on what processes we should have, are normally contrary to the specific nature of the business model.
  • Do not decompose services or processes to a level of infinite granularity. In the early 2000s there was a tendency to over document processes, to the point that there is a document which specified the process, other for the sub processes an even activity details. What seemed to be a way to create a knowledge repository about processes, quickly turned into a document management nightmare, were composition and degree of granularity are associated what is commonly termed “engineering decision”. After a short time of being immersed in this approach, I concluded decomposing the value chain in layers was a way to sell professional services. Unfortunately, this approach still holds today when Enterprise Architects speak about creating “Capabilities Map”. For example, let’s consider a Procurement Process. The logic decomposition of a Purchasing process is to include these sub processes (or not). Purchase Requisitions , RFQ and Quotation , Purchase Orders , Contracts and Purchase Agreement ; Release Documents payments and purchase . If what we want is to define a value chain and Purchasing process is part of this value chain, why not just stay in the identification of the process as a whole and how it is made in terms of creating quotations or payment of invoices is mirrored in the way you want it to be in information systems, documents, legislation or any other support? What is the value for a manager knowing that you have to specifically improve the way payments are made to suppliers, because this is the cause of the delay in closing the accounts and makes the financial statements take more than 10 days to be published? This information should be part of the Business Case of the improvement project. To the manager, is only necessary to know that the procurement process must be improved.
A Value Chain

A Value Chain


7 thoughts on “Enterprise Architecture Handbook part 4

  1. Hi, Good post, but I should react on one key point. You state that “Each service must be supported by at least one process”. This is a somewhat wrong understanding of what a Business Function is in ArchiMate. You seems to see it as a subdivision of an organisation (“Good Old Business Function” as some would say), where ArchiMate sees it as a behavioural concept which is in fact very similar to a process, so in some aspects it is a process. This is why (by the way) a Business Service is not “supported by” (if I understand you, “realized by”) a process, but instead a Business Service is “composed of” or “aggregates” processes.

    • Hi, sorry about my last comment’s quote which is not the good one (I’ve switch too fast between part3 and part4). ““Each service must be supported by at least one process” is perfectly valid, but the comments associated with Business Functions on part3 seems GOFB oriented. E.g when you say that “[Business Function] is pretty bad because semantically speaking is close to organizational function”. Another remark: when stating that “The Business Function viewpoint shows the high level business services” puzzle me as this assume that a Function is a Service, but I think its a not so good mixture of interal / external behaviour. Perhaps your vision need a little bit more axplanation for me to catch it 😉

      • Hi Jean Batiste:

        Thanks for your comments.

        I think that the way Archimate defined what is a Business Function was not very clear. I am assuming that probably it was tried to refer to the function of a system, rather than an organizational function. But unfortunately, the way they expressed it leads the reader in the later not in the former.

        Consider a elementary example an all terrain vehicle. Have both functions of off-road capability, and its on-road capability. A SUV only have the function of on-road capability (despite marketing promote of being able of off-road).

        This same principle applies to a company. In the depicted example there are two large group of Business Functions (as defined in Archimate): the core, related with professional membership and related and the others, secondary, related with advertising, technical book and journal publication and others. They actually do that (the “what” of an enterprise). If they do it, there must be a process for that purpose (the “how” they do it, “how” operations are done). If the process it’s documented or not, if there are or not flowcharts, if it’s pure based on top of tacit knowledge, it is a matter the way the enterprise choose to define and implemented it, but if there is a Business Function not supported by a Process, one of the two is true. The Business Function is a wishful thinking (the organization like to lie to itself) or that particular Business Function is supported by a company of heroes.

        As Archimate put’s it in order to support the relational meta-model:

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


        “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.”

        Hence a Business Service can be realized by the “what” (Function) and the “how” (Process). Shouldn’t be by the latter only (engineering approach) or only by the Function taking in consideration the first definition that a Business Function only realize Business Service (lack of coherence in the way it was written).

        This kind of discussion is what I’m trying to avoid. When you want to define a value chain, what is the best path:

        – Spend 3 months imagining the Business Services for each Business Function (it will be a myriad) and then the Business Processes, or;
        – Spend 2 weeks reflecting to the Business Functions and define what Processes should be in place to make operations happen.

        I clearly see the last option it’s the best (but I assume there are different point of view). If the result is to define the Value chain I think this is the way to do it.

  2. Thank you for your reply.

    I think I understand what you say (and it makes sens), but the point for me is that what you are describing as Business Function is in fact an Actor or a Business Role. The “what” is the Service and the “how” can be either a Process of a Function. Of course one can agrue that if you model an enterprise in deeper details you will end up with Functions aggregating some (internal) Processes, but at a high level that’s not mandatory. In your last value chain example (and always from a pure ArchiMate point of view) a function composed of only one process could stay at the function level only (on your example, it’s obvious that Marketing does Marketing Management so a you could stay with Marketing function only).

    To illustrate, here is a good blog post on this topic: http://masteringarchimate.com/2011/07/23/modeling-gofbf/

    • Jean Baptiste:

      As Archimate defines what is an Actor: “A business actor is defined as an organizational entity that is capable of performing behavior.” The definition is short, because a machine, a system can also perform behavior and it’s not an organizational entity. Again, these series of posts are not about criticizing Archimate, but make the most about coherence.

      I see Business Functions describing what a business does. For example, in Airport Management you have aviation business and non aviation business, meaning you will have two value chains. In non aviation business you can have functions about: rent a car, parking, retail, this is what the business does. If there is no hotel business, such function does not exist and you don’t have any process to support such a function.

  3. Pingback: Enterprise Architecture Handbook part 5 | End to End BPM

  4. Pingback: Viable System Model meets Enterprise Architecture | 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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s