Recent Discussions about Function vs. Process vs. Services

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.

A Simple Test for Analyzing EA Program Effectiveness

Many EA programs we examine suffer from one problem; they are mired in the details of a few narrow problem spaces and, as a result, are not as broadly focused as they should be.  A simple narrative-based analysis can help EA teams find the right level of detail for their work.  The narrative, while deceptively simple, reveals a lot about just how effective an EA program is, our how effective a new one can be.

The narrative leads to a simple test, one that is not objective and wouldn’t stand scrutiny as a well-constructed metric.  Instead it is in the form of a subjective analysis.  It is meant to focus EA leaders on one aspect of EA;  to drive consistent, enterprise-wide convergence towards a desired  future state enterprise architecture.  The premise is simple, that no matter how “perfect” and detailed the architecture, it will only make a difference to the organization if it is relevent, well-understood, it informs decision-making, and it is uniformly applied to the project and asset portfolios of the enterprise.  

The test begins by “imagining” the behavior of three (3) different project teams, all assigned the same exact project (out of the set of any projects that are typical for the organization). The teams are not permitted to talk to each other.  Ask yourself how likely is that all three will independently produce essentially the same fundamental design?  We’re not looking for identical results, e.g. the same lines of code, but whether they reach the conclusion to use the same primary infrastructure components, arranged in acceptable ways, manage data and information in the same logical and physical chunks, integrate with other applications with the same style and approach, be secure and reliable, etc.  In the absence of enterprise architecture, the answer is usually “not very likely”.  Designs will be based on each individual team members world view, their experience base, what they are comfortable with, what new things they are interested in pursuing, how they are influenced by others including colleagues, business-side leaders, vendors, and so on.

The next part of this “thought experiment” is to ask yourself the following questions: In your organization, are you providing enough information so that each team will, through the normal course of project execution, get “the most important things” right?  Do you know what “the most important things” are?  Are you effectively communicating them and educating/guiding the organization?

The final step is to use your findings to:

• influence content creation to make sure we address “the most important things” (because EA teams often spend disproportionate time deep-diving into narrow topics that have limited impact on the enterprise – we have always said EA should be “breadth before depth”)
• communicate to and educate the people who will have the most impact across the enterprise (because EA teams often fight fires and work exclusively on the hot projects and thus only influence narrow stakeholder communities)
• create usable, easily consumable deliverables that can be quickly located (because EA teams often create excessively detailed and lengthy deliverables instead of actionable and prescriptive content, and bury them in multiple levels of hierarchy instead of with links and/or tags in easily searchable repositories)

EA leaders that regularly contemplate the implications of questions like these tend to be more systematic in defining the work that they need to do, and are more successful in completing that work in the way that has maximum impact across the enterprise.  Furthermore, they tend to suffer from less churn and are not in “react mode” as often.  Those that are fortunate enough to be able to engage their leadership in the analyses of scenarios like these tend to get maximum support for their ongoing EA programs.

Portfolio Management Still a Key to Realizing EA & IT Benefits

Enterprise Architecture as long been considered a planning discipline.  Many times when asked about the value of EA, people will comment with the old axiom, “What is the value of a plan?”  While there is certainly some inherent value in the artifacts, processes, and relationships developed by EA in and of themselves, the real benefits are achieved through the implementation of EA plans.  However, a conflict has always existed between the EA representation of a long-term enterprise view and the near-term bounded perspective of implementation projects.

For many years, well over a decade, we have been helping organizations overcome this conflict by developing a portfolio perspective of the many (sometimes hundreds or thousands) of implementation projects underway, approved and being considered.  While more organizations are attempting to maintain a portfolio perspective, there is still a decidedly immature approach to making portfolio decisions (managing the portfolio) from an enterprise perspective.

There are a variety of reasons for this:

• Complexity / Volume of the project portfolio
• Lack of tools in use to help organize / analyze the project portfolio
• Lack of business participation / Perception that the project portfolio is an IT organization/CIO’s responsibility

The good news is that these problems can be overcome.  For instance, not every single unit of work defined as a project has to be accounted for in the portfolio.  Most successful portfolio management efforts include the creation of criteria for inclusing into portfolio analysis.  These factors can range from duration, budgeted expense, capital expense, and resource allocation to strategic impact, level of risk, ROI, and number of depencies. 

As organizations continue to mature their approach to portfolio management, they quickly find out that it is not all about realizing benefits from EA.  It is about making vastly better investment decisions for the enterprise.  The EA deals with the future vision of the enterprise.  The project portfolio management process, if done well with the input of EA, will provide a balance to fulfilling the immediate needs of the enterprise while also advancing the strategic vision of the business.

IASA “IT Architect Regional Conference” in Minneapolis – George Paras to deliver Keynote

“Enterprise Architecture (EA) is an immature discipline and possibly getting even more immature.  As the scope of EA extends beyond the areas that IT-centric efforts are prepared for (data, app, infrastructure), the competency, credibility and effectiveness of an EA team may decrease.  However, there are a variety of ways to increase these characteristics for EA teams, regardless of the stage of maturity in which you may find yourself. “

That is the theme of a keynote presentation, entitled “EA Profession: What’s Changing and What’s Not?”,  to be delivered by George Paras at the upcoming IASA ITARC event in Minneapolis on Friday, November 13.   The discussion will feature a lively discussion about his assessment on the state of the EA profession, what he sees going on in the industry that helps and hinders the evolution of the EA profession, and what else to expect in the future.

The International Association of Software Architects (IASA) is the premier association focused on the architecture profession through the advancement of best practices and education while delivering programs and services to IT architects of all levels around the world.  The IT Architect Regional Conference is the first event in Minnesota to address the pressing needs of IT architects today. There are 12 seminars and two tracks separated by specialty: Enterprise and Fundamentals. Architects of all levels can take their skills to the next level.

Effective EA Marketing and Communication – George Paras speaking at Western PA EA Forum

Although the word “marketing” can elicit negative thoughts in the mind of a technologist, it is a necessary consideration for any EA program in order to maximize its impact on the business and establish an environment for continued contributions.  George Paras will present on this topic and lead an interactive discussion at the November meeting of the Western Pennsylvania Enterprise Architects Forum on Monday, November the 9th in Pittsburgh. 

Some topics to be in covered include:

• Who are your customers and what do they really want?  How do they know they are getting just that?
• How do define “value delivered” and what kind of measures do you take to prove it?  How can you account for short term and longer term value areas that you deliver against?
• What is effective communication and how does this relate to the deliverables of an EA program?  What kinds of EA artifacts should you use to communicate with your customers in today’s high paced business environment?
• Different styles of communication & why this matters?

The WPEAF was created in 2002 to provide opportunities for sharing best practices around the emerging field of Enterprise Architecture.  The mission of the group is to foster the sharing of non-competitive architecture processes, concepts, and artifacts in order to support business requirements.