In the past, APQC has talked at great length about the Process Classification Framework® (PCF) in terms of APQC’s offerings: process management, content/knowledge management, and benchmarking. Inspired by my colleague Holly’s recent research, I started thinking about how APQC positions itself in the enterprise architecture (EA) space. How can organizations that are focusing on enterprise architecture leverage APQC’s PCF for better EA outcomes? How can our process management tool MosaiQ® accelerate EA efforts? How can our methodology for process management reduce rework?

What is Enterprise Architecture?

Numerous definitions of enterprise architecture exist. Some overlap. Some conflict. Some push the concept in new directions. I’m not trying to set the standard definition of what EA is, so I’ll rather just jump into the fray and let you know how I think about it. Enterprise architecture is the practice of modeling an enterprise and governing the associated models. Simple in principle, complex in execution, just like all things.

Which Models are included in an Enterprise Architecture?

Let’s talk for a minute about the various models commonly used to understand an enterprise:

• Organizational structure – how we physically organize to create value for our clients and shareholders; includes people, places, and things – all of the resources necessary
• Process models – what we do to create the value for our clients and stakeholders
• Systems architecture – how we automate various processes and data flows
• Data models – what information we process to operate our business and how that information is governed
• Product/service mix – what products and services do we bring to market to create value for our shareholders?

Are these all part of the enterprise architecture? Sure – they are models of specific facets of an enterprise.

But a problem arises: models in isolation eventually converge. Organization models start defining processes. Data models refer to systems architectures. Process models include data models AND systems architectures.

Convergence: Good, bad, or Ugly?

When models converge without governance, bad things happen. Consider the situation when a systems architecture model and a data model merge (good) but no one tells the client (bad). Then the business people make a change to the data model. IT implements the change in the specific systems (good) but the systems architecture model that integrated the data model never gets the update (bad). Then someone assumes the data model integrated into the systems architecture model is consistent (bad) and makes a decision about something that isn’t true (very bad) and introduces rework or some kind of patch (ugly).

Just to reiterate: model convergence is good – it helps create consistency and reduce costs, but ONLY if governed and managed correctly. When it’s not governed, it can create problems. But governance is not the subject of this post – model convergence is, and specifically model convergence of processes into … well, really into ALL of the models.

I Am One With The Process

Data doesn’t exist without processes; processes cannot exist without data. It’s a real “which comes first” kind of situation. In enterprise architecture, you could ask the same question about any of the other models too. “Which comes first, the organizational structure or the processes executed in that structure?” You could do it for systems architecture as well: “what comes first, the systems architecture, or the processes executed in that structure?” You could do it for any facet of enterprise architecture. Go ahead, think thru it. I’ll wait.

…

Did you end up thinking that in most cases, the processes had to come first? Yeah, me too.

Understanding what an organization does – the “inventory” of processes per-se – is crucial to being able to understand how all of the other models relate. And remember – models converge, but beyond convergence, models – when considered together – represent the enterprise they are intended to … model. The more models you have, the more likely you are to be able to effectively understand and manage the enterprise.

So – when considering a process model, why not consider one that is free of the trappings of organizational structures, business rules, automation, and more? Why not consider one that creates structured building blocks that follow structured business rules that ensure consistency? Why not consider the PCF?

Simple Integration

In 2016, APQC launched MosaiQ, its cloud-based tool for creating and managing custom process frameworks. MosaiQ is the perfect tool to support your EA efforts because it prevents you from recreating the wheel every time you go to model something.

Imagine you’re creating an org chart that reflects your latest innovation: shifting your order to cash process to centralized processing centers in two major regions. You already have the processes identified in your MosaiQ environment. Now it’s just a matter of linking your organizational models back to the MosaiQ process elements. The definition doesn’t change – you have created the definition once and hyperlinked to it. But now the people who are looking at your organizational model know that the convergence of the models is a *good* thing because the processes remain governed in the MosaiQ tool. You didn’t have to fish out and link to process flow charts that have unnecessary details. Link once to MosaiQ which contains your customized process framework and *boom* you’re sure you have the most current version of “what” is being delivered at the new centralized processing center.

Why not get started today? MosaiQ is available at no cost to all APQC members.