I have had a few conversations over the last few weeks with folks trying to do some high level business modeling to provide enterprise context for analysis and communication purposes. A conflict that comes up for organizations is whether to take a functional view of the business or a process view? And where do services fit in.
While the function vs. process question is not new, it did get us to thinking about what specific advice to give clients. A definition that I came across quite consistently from a variety of sources states the following:
- Function = Individual building block
Process = Blueprint that either shows how the individual blocks work together OR Series of activities that use individual blocksFunction Definitions:
1. the purpose or role for which an object or a person is particularly used or suited.
2. a factor or quality that is dependent upon one or more other factors or qualities.Process Definitions:
1. a systematic sequence of actions used to produce something or achieve an end. example: the assembly-line process.
2. a continuous series of changes, functions, or operations. example: the process of growing up.
3. movement onward or forward; progression.
When looking at function vs. process within an organization, there is typically a vertical (Functional) vs. horizontal (process) perspective maintained. The classic example to describe the difference between function and process is a pharmaceutical company. They are usually organized functionally – research, manufacturing, marketing, sales, logistics, etc. If you take a process such as “Bringing a Drug to Market” the process will go from R&D to manufacturing to marketing to sales to logistics, with some stops/iterations within/between different functions, as well as some other functions (such as accounting, procurement, legal, compliance) involved as well.
In our jump start material, also referred to as UMCEA (Unified Method for Communicating Enterprise Architecture), we suggest a functional heirarchy as one of the elements for HL modeling. The functional view lets you see the company independent of boundaries and existing workflows (like processes). I like the functional heirarchy as a HL organzational element – but it only goes so deep. Process is more beneficial for most organizations in trying to find overlaps/redundancies, as they tend to be functionally organized, and process goes across the org/functional entities – the jump-start materials have a functional bent so there is not as much overlap when you map functions-to-organization or funtions-to-apps. However, whether function or process is your focus, both must be understood by EAs. The key is in identifying the cross-functional processes, which isn’t apparent from my perspective by just identifying the functions. A good method for helping to identify the cross functional processes is to conduct an Enterprise Value Network (EVN) analysis. This approach will allow you to join the functions together by identifying relationships between them.
Another approach, however, suggested by the UMCEA is the mapping of information entities across functions, organizational units, and applications. This is probably the best method for identifying many of the key integrations across an enterprise. More on that another time.
Finally, the notion of services has come up in many of these discussions. Is service a subcomponent of function or process? Or is function a subcomponent of service? Or is process a subcomponent of process. I think the notion of service-orientation (not SOA, by the way) is an increasing trend that EA, IT and business groups must come to grips with in the near future. The interesting thing about service is that if you define just the word “service”, it is understandable, but doesn’t help in the exercise of trying to understand the relationship between functions, processes and services. Take the ITIL definition of service, for example:
- “A service is a means of delivering value to customers by facilitating outcomes customers want to achieve, but without the ownership of specific costs and risks.”
This helps to put some meaning behind service. However, I think the key to positioning service is adding context, because services represent vastly different things depending on context. For instance, externally-facing business services such as Customer Service, Delivery Service, Valet Service represent something completely different than internal business services (accounting, commercialization, procurement, Help Desk) or application services (Get Customer Info, Calculate Sales Tax, etc.) or infrastructure services (directory services, configuration management, capacity planning, authentication). For a great synopsis of levels of service orientation, check out Proact Business Transformation’s description.
In conclusion, I would like to tell you that as you are getting started, the functional view is probably the easiest, quickest and most well understood by executives to create. But as you begin to create more detailed views and conduct more detailed analysis, you will have to adjust your approach to take functions, information entities, and possibly services into account. And none of these are mutually exclusive, either.
Posted by George S. Paras 
