Sunday, April 3, 2016

Topic 6 / Post 1 – Emerging Business Architecture / Business Capability Modeling and Business Architecture

April 3, 2016 / Dennis Holinka

Topic 6 – Emerging Business Architecture

This week's posts go over the Emerging Business Architecture, the various perspectives, and related reflections in the blog.

Post 1 – Business Capability Modeling and Business Architecture


         There is nothing as confounding as the modeling of business architecture as is found in the discipline of Enterprise Architecture.  The discipline of Business Architecture is focused on architecting the business in such a way to provide for its transformation to a future state from its current state.  However, the questions that are raised are numerous such as what modeling depictions should we use and what are the models that we should produce.  Moreover, what is the value in the models and what is the value of all of that effort are the questions being examined by business and enterprise architects in the industry.  Recently, I have engaged in a discussion with a expert in business architecture from the business guild after having attained a yearly membership.  The discussion was related to the much needed information regarding the link of understanding the foundational terms in business architecture that keep emerging in the industry and academic literature.  That is, what is business capability and how is it different from business process, business function, business value chains, and business value streams.  The confusion emerges because there are many terms bandied about but these terms need to be precise in order to properly understand their elements and any relationships these terms have to each other.  Another set of questions around business capability modeling is how is it done and how do you know if you have properly factored them.  What is the relationship between them and how do we know if we have gone to far and too deep in the process of business capability modeling.  
         The answer begins in understanding the means to achieve ends.  That is, why are we doing any of this and what is the purpose of knowing everything we want to model and understanding the lineage of the relationships across the business capabilities.  It has been documented that business capabilities language is the lingo of executives in encapsulating many of the resources that are required in order for an enterprise to achieve an end in its future state or in a specific strategy outlined for the company.  It is here that a enterprise capability is a composite of what it does which is described by its function (i.e. what),  which resources are required in people, technology, and process of how it is done to achieve an outcome.  My reflection over this field is that there needs to be a precise ontology and metamodel for the field of enterprise architecture that precisely incorporates the meanings and depictions of these terms for the sake of de-conflating the ambiguity in the field.  Confusion exists with architects and IT professionals alike who proceed to model these imprecise and ambiguous constructs which works to dismantle the methodology of deconstructing and re-synthesizing the newly abstracted future state enterprise.
         The literature for enterprise architecture begins by consulting five sources which I have found to help me to construct a more precise mental model for the creation of business architecture models and extracting the value that is inherent in the methodology of modeling those abstractions.  Gartner definitely provides the best explanation of starting with the business context and creating the Customer Requirements Vision (CRV) with its traceability from goals, strategies, initiatives, and transformations for the business to IT systems and runtimes.  What I have found illuminating is that there is an articulation of a metamodel that says each of those components are related in the form of means to achieve ends (e.g. future state).  The business architecture models from there, generally speaking are models that would bring clarity to the transformations that are required and necessary to transform the enterprise.  For instance, there are models that would require us to understand as well as to inform us on the importance of understanding why the business process models are constructed the way they are.  In other words, some missing models of what we need are what are the business model canvas of our business profit model and what are the product models that make up those business models.  It is on those models, that we derive process contexts as to why and how our business needs to change besides stating generally that our business operations needs certain aspects and features.   The business profit model provides us with the insight on how the current processes either achieve or don't achieve the profit model being pursued as depicted.
Figure: Business profit models from business context


         Here we can benefit from the Business Guild and Gartner's methodology of decomposing the enterprise into value chains and value streams.  It was once documented by IBM research that there were 18 distinct value streams across the enterprise.  Each of those value streams would decompose into a value stage and the value stage would have a decomposition into business process.  It is here that we need to make a major distinction between business function and business process including cross boundary business processes.  Moreover, as architects we should be working from reference models for an enterprise and have a few places in which we can look to start the work without starting from scratch.  The use of business function, business process, and business capability models are available in the industry with limited explanation between each of them from ACORD for functional/capability model that is focused on only the customer facing portions of an enterprise.  APQC is focused on process and doesn't provide a complete view of the functional breakdown of an enterprise to the point that process can be understood comprehensively.   Gartner provides a breakdown of how these items are related to each other in the following depiction.  In addition, the functional relationship between a business function and business process is provided.
Figure: Gartner business architecture model relationships

Figure: Traditional functional hierarchy of a firm in relation to business process

         The best places to understand the relationship between function, business function, business process, and business capability is from EnterpriseArchitects.com, TOGAF 9.1, and EBMM. There are three models that provide a clear understanding of the simplicity and complexity of the relationship of the models being reviewed.  At EnterpriseArchitects.com, a business capability realizes a capability in that a capability is abstract without the ability to perform the logical function.  Moreover,they provide functional processes and well as cross functional processes to understand what makes up a capability. 
                                              
Figure: Functions realize capability
Figure: A conceptual framework for thinking about capabilities, services, business functions and processes
http://enterprisearchitects.com/business-function-does-it-have-a-place-in-business-architecture/

 In TOGAF, there is a recursive relationship with function and process which is depicted in the model provided by The Open Group which explains why there is much confusion in modeling these concepts.  It is explained that "function describes units of business capability at all levels of granularity such that the term 'function' is used to describe a unit of business capability at all levels of granularity, encapsulating terms such as value chain, process area, capability, business function, etc. Any bounded unit of business function should be described as a function." as depicted.
Figure: TOFAF framework for thinking about business functions and processes

Lastly, it is important that a metamodel depict the relationship across the scope of the enterprise and all of the lineage that may be required to depict the details of the enterprise business architecture model components in order to plan the target state transformations.  It is here, I recommend the use of of the EBMM for the big picture view of the enterprise from business context to business profit models, product models, service models., business value chain, business value streams, business value stages to business processes, to IT and systems and runtime models.
Figure: Enterprise Business Motivation Model (EBMM) - Primary Viewpoint v4.2

No comments:

Post a Comment