A process architecture can take many forms and can be easy to do.  I have seen a lot of variation, however, and sadly most are not useful for actually operating or managing the business or creating value.  Most are too functional, meaning they often line up too conveniently with the organization structure and therefore are not versatile enough to withstand an organizational realignment.  That's what you get when you start by asking people in the organization 'what do you do?' as opposed to starting with the external stakeholders and the products and services they deliver, create, and receive. 

Another potential pitfall is architectures mostly created by blindly copying a process framework.  Frameworks can be extremely useful, but most do not deal well with end-to-end value creation, although they may have a lot of the bits and pieces needed somewhere.  They have most of the parts, but the assembly of them into a working value chain is often a problem.  I know that all the parts to build a car are in the car-parts catalog, but those parts are not categorized by how you want the car to drive.  A useful process architecture must be built from the point of view of the work that must be performed to add value along a chain of activities all the way out to the external world.  That means coming inside, starting from the outside, and being agnostic to the organizational groups or the parts catalog.  The parts have to be assembled for a purpose.

Useful process architectures have several common characteristics.  The first is a macro classification into bands of processes grouped by their role in value creation for customers and support of the business strategy.  As mentioned earlier, the highest-level classifications are core, guiding, and enabling processes.  Within each of these categories there may be more divisions of work processes based on relative closeness to the core activities.  Consequently some industries lend themselves to extra distinction professionally and politically.  Sometimes organizations break out extra categories to satisfy a need from some executives to make some processes more visible to the organization.  Figure 1 illustrates further segmentation possibilities.

    Figure 1.  Further High-Level Process Categories.

The core processes are typically focused on the customer and value delivery chain, since that's what the organization gets paid to do.  An airline would consider the process 'transport passengers to destination' as core and I hope that includes 'with luggage'.  The core processes will also usually include everything the organization does to innovate, bring and keep products and services in market as long as they are viable, and remove them when they are no longer so.  Enabling processes include the essential support processes that are very closely linked with the core as a separate band.  For example 'maintain aircraft' would fall into the primary core business resources processes for an airline and would be different from the general enabling processes of 'provide staff' and 'build office systems' and the like which are very similar in all organizations.  The farther you get from the Core you can expect to see more cross-industry generic processes.  The guiding processes typically include the planning and control processes that managers employ to keep the core day-to-day working at their best in near time.  These are shown close to the core and may be shown separately from strategy and directional processes which will have their own band.  'Develop flight schedule' is a good example of a close managing core process.  'Set budgets' would be an example of long term and more universal.  There can be many variations on this model that are specific to a particular business, but this segmentation has served well historically and gains executive buy in without too much difficulty.

Core Processes

Let's briefly look at the development of the core processes for the illustrative example of a consumer bank with guiding and enabling processes at level 1.  Each level-1 process is a value stream within the value chain and represents a logical progression in value contribution to the end stakeholder goal of the value chain.  Within each level 1 is a set of level-2 core processes.  In Figure 2, P or S stands for 'Product or Service'.

    Figure 2.  Guiding, Core, and Enabling Processes. 

Since the main focus of the core are the recipients of our goods and services, it is logical to look at what interactions we have with the customers over their whole experience with us.  The first step is to understand the customer journey (e.g., life of the potential relationship) and trace it from customer unawareness of the organization through to the end of the relationship and to find the major transition points where a clear result is attained.  This is the point where the state or status of the relationship changes and we deal with them or they with us differently.  Then we can define the process that was executed to achieve the transition point. 

For customers, and indeed all external stakeholder relationships, there are three main stages that the relationship will go through.  These are customer relationship establishment, customer business operations, and customer relationship re-assessment.  The customer relationship establishment typically happens once in the stakeholder journey to get things going.  The customer business operations processes typically occur on a regular iterative cycle.  The customer hopefully orders many times.  We may provide a service on a calendar basis once a month, for example, and the customer relationship re-assessment points occur regularly through typically scheduled periodic calendar reviews or action due to a specific positive or negative trigger.  This provides the opportunity to enhance the relationship or perhaps to terminate it.  Each particular customer will be in a state potentially different from the others at any point in time of course.

Once the processes preceding the main transition points are defined, look for the core relationships for business partners that are involved with you to jointly provide service to the customers or provide consumable resources used to provide products or service to them.  Figure 3 is an illustration for the bank consumer.

    Figure 3.  Bank Consumer Example:  Processes and Transition Point Connections.

Since our business is all about our products and services, we must focus on how we gain the best mix of them in the right market at the right time and for the right prices.  This is a second perspective on the core; the product or service lifecycle (Figure 4), starting with the initial product or service (P or S) concept all the way through to the end of the product or service life.  Once again, we would identify all the transition points where the state or status of the product or service changes and then define the process that preceded the change or do it the other way around as shown.

    Figure 4.  Generic Product or Service Example.

Similar to the customer and other stakeholder journey relationships in the first example, there are three main stages in play.  These are product or service establishment, product or service operations, and product or service re-assessment.  Product or service establishment typically covers everything that happens to get a product or service into market from the time a fragile idea was conceived, including a lot of processes that make a go/no go decision.  Product or service operations deliver on a regular iterative service cycle, and product or service re-assessment occurs based on scheduled review or specific triggers to determine the opportunity to enhance the product or service or perhaps to decommission it.  Again, different products or services will be in different states at any point in time.

While examining the natural stakeholder journeys or product and service lifecycles, organizations should constantly use reference frameworks to gain knowledge of industry standard processes and sequences and should create or modify the end-to-end process flow based on relevant insights gained from them.  Many organizations miss this key use of frameworks and end up missing key activities.  Whereas the top levels of the frameworks will sometimes be organized differently from what derives from the journey and lifecycle approach, the frameworks will become more and more useful as each of the level-1 and -2 processes are drilled into for specific sub-process identification at level-3 and -4.

Guiding Processes

Level-1 guiding processes, as illustrated by our example shown in Figure 5, can be viewed as a holding grouping, and one is required for every guiding or constraining concept or item that must be managed.  Typically this includes self-contained level-1 processes for dealing with strategies, policies, budgets, regulations, and other governance issues and the entire journey for directional, governance, or compliance types of stakeholder relationships such as owners or regulatory bodies.  Each has its own sub-levels (level 2 on down) similar to the core journeys or cycles.  The approach is the same as shown earlier for the consumer cycle, and the pattern is similar with regard to the three major stages.  Directional or constraining guidelines that we manage internally, such as strategies, budgets, or policies of the organization, all follow a lifecycle similar to stages seen in products and services.  By identifying the guiding aspects of organizations, we can define the top level of the guiding architecture.  The use of frameworks in this domain is helpful since these frameworks often have full-cycle views of such organizational assets.  The APQC frameworks are particularly strong in these aspects.  Figure 5 shows an illustration for the level-1 process 'Mitigate Regulatory Risk'.  The other guiding level-1 processes will follow a similar pattern.

    Figure 5.  An illustration for the level-1 process 'Mitigate Regulatory Risk'.

Enabling Processes

Level-1 enabling processes can be viewed as a holding grouping for everything in its sub-levels (2 on down) which is the entire journey for reusable resource provisioning stakeholders, such as human resources (not the department), facility, or technology-provisioning relationships.  In addition, the internal provision and optimization of resources such as equipment, technology, or people all follow a cycle similar to products and services, with a clear beginning and end.  Each level-1 enabling process will have clear demarcation points in the journeys or lifecycles for their level-2 processes.  By identifying the enabling aspects of organizations we can define the highest level of the enabling architecture.  Like for guiding processes, the use of frameworks is beneficial.  Figure 6 shows an illustration for the level-1 process 'Provide Facilities'. The other Enabling Level 1 processes will follow a similar pattern.

    Figure 6.  An illustration for the level-1 process 'Provide Facilities'.

Describing a Process

Every process still needs a full description of its attributes.  Not all of the information will be available or known when doing the early parts of architectural work, but at some point in time, once it is better understood and some design decisions have been made, the contents can be documented.  This information is an important complement to the graphic models and should be stored in an appropriate repository along with the pictures.  An Illustration for one of the processes in our banking model is shown as Figure 7.  The template is applicable for any level of process description and will cascade along with the decomposition of processes themselves.

    Figure 7.  Process worksheet for one of the processes in our banking model. 

Connecting the Dots

There are several ways that organizations can connect processes.  Many start at the detailed task level and show pure workflow sequencing, but this is at a detailed level of work and the volume of activities is vast.  These bottom-up approaches are well supported by traditional model types such as BPMN where the question of 'who does what next' is most appropriate.  The notational advantages of sequencing at such a workflow level are not realizable, however, for architectural work since they do not handle or make visible the exchange of value with other architectural processes and where sequence is very hard to discern.  To trace value it is much more useful to create a view that examines product, service, and information exchanges (provided or received).  Figure 8 illustrates this perspective.

    Figure 8.  A view that examines product, service, and information exchanges (provided or received).

This is a powerful way to connect the architecture and keep it measurable and focussed on value creation.  Fortunately, with the architecture concepts defined in the model described to this point we can describe each process' scope in terms of such exchanges and its connection to strategy and stakeholder expectations.  In the Process Worksheet in Figure 7 you will find four scoping questions covering the Inputs as well as the Outputs from the process in scope.  In addition, there are questions of the provision of guides and enablers for the process.  These are different in terms of the role they play with regard to a process action.  They are not inputs to be transformed into outputs but are critical to the success of the process in question.  In addition many processes produce outputs that are not changed in every subsequent process but are used over and over again, such as a business rule to be consistently applied to make a decision in every transaction or a system to always be used when making a calculation.  For an architecture with integrity, every input, guide, or enabler must come from either another architectural process or an external stakeholder; nothing else and no one else!  Likewise, every output can only go to another architectural process as an input, guide, or enabler or to an outside stakeholder; that's all!  An architecture with integrity cannot have disconnected orphans.

There is a tremendous advantage to this approach which I pulled together based on the concepts of IDEF0 (in the mid nineties) and that is its data or information orientation.  If we can find everything that moves between pairs of processes then we can identify the information requirements of the organization or value chain since processes create, update, or delete such information or perhaps just read it and take no action.  Regardless, poor data quality of information leaving a process means there is something wrong with that process or one of its predecessors.  The role of Information Management will be treated in an upcoming article.  This Input, Guide, Output, Enabler (IGOE) model is also ideal for initial scoping of process improvement or Lean projects since it proves traceable integrity back to the architecture and the strategy of the enterprise.  Managing scope is eminently manageable with this starting point.

Future Articles

The business process knowledge gained and made available here should produce more than a nice picture.  The configuration is the structure of operational work and the basis for measurement and capability to optimize the ability to do work.  It is the heart of the business pumping the blood through the organization's arteries and veins.  It tells you what is important to be good at, regardless of what your organization chart says.  It is the basis of operational governance and change decisions.  It is a view based on value creation, and that's what we are striving to achieve.  The performance management system will connect to the top of the strategy and process scorecard and all the way down to the detailed elements of everyone's work.  But that's the topic of the next article in this series.

That's the way I see it.

# # #