다음을 통해 공유

How FEA handles Capability and Process Modeling

  • 아티클

A few weeks ago, in a blog post, I asked about the relationship between business process modeling and business capability modeling.  I asked some open ended questions to get honest feedback.  I presented two models to illustrate two potential relationships between capabilities and processes.  I called them "Model A" and "Model B." 

So when doing a little research on the Federal Enterprise Architecture Framework, I got a good feel for how the OMB has attempted to solve this problem.

Answer: The FEA uses "Model A." My analysis showed that the FEA notion of a "Business Area" and "Line of Business" describes the same thing as the notion of "Business Capability" in a business capability framework.  I also noted that, in the FEA, processes exist under the capabilities.  There is no notion, in the framework itself, of processes that tie together capabilities across functional boundaries. 

I find this curious, because there is clearly INTENT to create and understand cross-functional processes.  Looking at some of the presentations made to various conferences, it certainly appears to be the goal to create an optimized structure for the improvement of cross-functional processes... yet there is nothing in the framework for it.

Studying the FEA, I noticed something else interesting.  In the FEA, business processes live at the intersection of the agency and the capability (or sub-function, as the FEA calls it).  In other words, if two agencies share a capability (say "loan guarantees"), then each agency will implement that capability using their own processes. 

The FEA taxonomy has nothing to say about alignment or reuse at the process level.  While processes show up in mappings to technology, they don't show up in the framework.

image

Without a process taxonomy, there is no mechanism to align processes, or find common elements even further down the list, at the activity level.  This is key, because in an ideal state, Enterprise SOA services support business process activities, and can be composed from there into support for processes themselves.  Without the activity level, the FEA cannot simplify beyond EAI levels, where entire applications were rationalized.

So my suggestion, to my hard-working colleagues who work on the FEA, is to include and make useful a business process hierarchy, separate from the functional (capability) hierarchy that the FEA now describes, and fill out the process activity element that sits at the join (junction) between an organization and the sub function (capability).

Technorati Tags: Enterprise Architecture, SOA

Comments

  • Anonymous
    May 20, 2008
    The FEA is based on reference models, which are not architectures themselves. The FEA reference models have been created to allow for planning across agencies. The SDLC can nly be an alignment to FEA, but not a direct derivative. My thoughts are to think through an ontology instead of taxanomy, since processes are behaviors. Taxanomies although are useful for programattic thoughts they do not lend sufficiently to understand behaviors.The FEA structure is more organizational needing the intervention of the Zachman framework to render them into normative structures. The process framework needs to be lead from the normative framework into declarative structures so to render them useful to the BPM / Worflow automation etc at the logical level. Importantly functional centic structure that follows an hierarchy is not suitable to SOA type structure that is network oriented. There is a fundamental contract between the 'service' boundary and 'function' boundary.

  • Anonymous
    May 20, 2008
    Hi Shrinidhi, I think my mistake was using the phrase "FEA Taxonomy."  The FEA reference model would have been a better term. Each of the "elements" in that reference model is a many-to-many mapping with levels above and below it.  It is not a taxonomy, nor a single ontology, but an information network.  This can only be rationally described with a metamodel.  I attempted to illustrate a simplified view of a metamodel in my diagrams in the post. I am used to working in this level of abstraction, as my own SDA model is very similar in structure (although we put 'information' in a different relationship, and we include a rich model for business processes). The fact that something is essentially a behavior does not mean that it would not fit in a metamodel.  On the contrary, it is essential to understanding business architecture. Note that MSIT has not adopted a standardized taxonomy of artifacts.  (Neither Zachman nor TOGAF).   We have not, therefore, created normative views across the MS businesses.   You are right in that the FEA does not identify any particular taxonomy of artifacts, and therefore the FEA cannot produce a normative set of documentation and by itself.   If this is important to the OMB, it may be a good idea to add a standardized taxonomy of artifacts into a future version of the FEA. Last point: in a metamodel, there is definitely a place for SOA Services.  A metamodel is quite capable of representing an information network that can describe the organizational, functional, behavioral, and informational inputs needed to create an Enterprise SOA.

  • Anonymous
    May 21, 2008
    In the NZ government's variation of US FEAF, we do not adopt the US BRM - for similar reasons to why Australia did not (our businesses are different) We suspect that OMB did not have the same focus of efficiency that we in NZ have. OMB seem to focus on avoiding duplicate spend; which we are as well. But we are also interested in doing more for your buck - which means comparing relative efficiency - which means that sooner or later you need a process classification framework.  Without a common way to describe processes you cannot achieve as much re-use as you might otherwise. Our pilot BRM contains: 4 sub-models or taxonomies:

  • Functions of New Government
  • Subjects of New Zealand Government
  • the Public Sector hierarchy
  • a Process Classification Framework (based on APQC) What we do, who we do it to, how we do it !   We dont think current modelling techniques are mature enough yet to maximise business value. The more business specific the services become the harder they are to define and construct.  When things get too generic, you typically lose contxt. The University of Wollongong is doing some interesting research in this area, that we are following.