What does Enterprise mean to my Enterprise?

As organizations struggle to evolve, adapt and become more efficient in these challenging economic times, one of the things they focus on is making better use of scarce resources in order to meet their goals. Often this takes the form of identifying areas where consolidation can occur in order to leverage economies of scale. The discussion in the meeting may include sentences like “Well, I think we really need to focus on enterprise capabilities” or “The only way for us to get some of these costs out is to identify our global business processes and make sure they are truly efficient.” I’ve sat in these meetings and had these conversations at the water cooler, and I think that to truly capture these efficiencies and economies of scale, their needs to be a broader understanding of how terms like enterprise, global, common, etc. fit into the way that the organization operates. There needs to be some precision about what these terms really mean and the organization needs to define these things explicitly. It is also important to define more than just the biggest or most global things in the enterprise. It’s important to have categories for the things that aren’t global, enterprise or common. This is because to really work well organizations need to explicitly define not just what will be governed, but what won’t. Deciding where to allow local control explicitly opens the door to real agility where it is most needed and prevents wasting management resources on making decisions that should really be made at a lower level. This needs to be made explicit because the tendency otherwise is to pass decisions upwards. Eventually the avalanche of decision requests will overcome the ability of the decision makers to make insightful rulings and a breakdown occurs where those making the decisions are uninformed and those passing the decision upward bear little responsibility for the results of the decision. This obviously does not increase organizational performance and can lead to a viscous cycle where the decision makers attempt to rest even more decision making authority from those below in an attempt to get things moving back down the right track with disastrous consequences.
Fortunately, there are some proven approaches that organizations can use to help work this problem that includes developing an explicit vocabulary and determining how the organizational operating model should work. For one thing many people have caught on to the Operating Model concepts embodied in Enterprise Architecture As Strategy: Creating a Foundation for Business Execution by Ross and Weill and begun to frame their governance in a manner that is based on the organizational operating model structure. By taking the time to determine the right level of standardization and integration at the various levels of organizational federation these organizations are helping to build the framework from which governance should be expressed. By making clear determinations about what they expect to get from their governance, i.e. a specific degree of standardization and integration they make it easier to craft the governance itself. This is absolutely a critical activity for Enterprise Architects and architectural organizations.
Essentially, if you buy into the idea of an “organizational operating model” you are buying into the idea that successful organizations openly express the degree to which they will standardize business processes and/or integrate data to produce optimized business outcomes.

Operating Model Concept in Brief

Federated organizations will include being able to effectively categorize items and concepts within the organization in a manner that provides insight into the amount of governance that will be applied to them as well as their intended use. For example a “global” business process or application might be defined as one that can be used by the entire organization across federated boundaries without customization. This is just an example, but I think it illustrates why it is necessary to have the definition. Without out it the user may not know or may make assumptions about configurability, extendibility, etc. I’m not going to go into extensive details on the Operating Model in this article, but I am going to focus on the language of classification that might be used beneath this construct in order to facilitate standardization and integration. Please keep in mind that this classification structure is meant to illustrate a point and not to state that this is ”the” language that should be used by all organizations. Your needs will vary, please customize and tailor in order to meet your organization’s specific requirements. Remember that what we are building is a common language for classification that can be applied across many organizational concepts including applications, services, business processes, data, etc. For my example I have used the following terms:

Enterprise

An Enterprise concept supports the organization without customization for all markets. Enterprise concepts do not contain any organization specific business logic, business rules, or business processes, etc. If this is an application or service it is possible that they can be configured for specific business unit use, but this should be limited to configuration that does not impact usage across the organization. Enterprise items may initially be developed and funded by any organization; however it is my opinion that once something is recognized as “enterprise” the funding mechanism should be moved to the highest level of the federated organization leveraging the concept in order to maintain the enterprise nature of the item in question.

Enterprise in a Federated Environment

Common

A Common concept supports multiple business units or organizations within the federated structure. Common concepts contain or may be tailored to organization specific business logic, business rules, or business processes, etc. An important consideration for common concepts is governance structure. Significant efficiencies may be gained by encouraging common item usage, but only if the organizations using these concepts can count on having a voice at the table when decisions are made to adapt, tailor or change these concepts. The use of common concepts probably embodies one of those most fertile areas for many organizations to gain economies of scale and facilitate collaboration and capability but the usage and value of these are going to be heavily influenced by the design of the governance structures that will support them. The ongoing financial support and funding mechanisms should also be clearly illustrated in order to gain maximum benefit. If “common” concepts are to be adopted and leveraged the organizations that use them must believe they are getting a square deal on the purchase (or development) and support costs across the organizations that leverage these items.

Common in a Federated Environment

Local

A Local concept is applicable to specific units or organizations within the federated environment. These local products may include specific extensions to “enterprise” concepts or standalone items that are unique to a single organization. For the larger organization the management of these will be heavily dependent on the Operating Model approach. Important considerations should include ensuring that local concepts are faithful to the operating model and do not undermine the optimum level of standardization and integration that is being sought by the larger organization. Local concepts should also be reviewed on a regular basis in order to identify locally successful concepts that could be applied to a larger swath of the organization. Most importantly for organizations where the operating model dictates a high degree of autonomy because of the specialized nature or high degree of independence of the “local” organization is that the central organization should respect this local designation. The tendency to over govern or apply an enterprise solution to a local problem is sometimes quite predominant among strong central planning organizations. If you have worked hard with the business’ various federated planning structures to develop an operating model that includes the management of concept “x” as a local item DO NOT go back on that promise lightly.

Local in a Federated Environment

I hope this provides a better understanding of how to use a light classification of items within a federated organization. I can’t stress enough how important a mature understanding of Operating Model concepts can be to really leveraging these concepts within your organization. For this I would recommend reading the book Enterprise Architecture As Strategy: Creating a Foundation for Business Execution by Ross and Weill as well as spending some time reviewing your general governance in light of this reading. I think the operating model is one of the most under appreciated concepts in the practice of Enterprise Architecture and is often treated as an after thought rather than a foundational component of the EA program. Understanding the level of standardization and integration that is applicable to your business has enormous implications for how you execute your EA program, the governance you use to implement the program and the way you resource and staff. The above was focused on a small piece of making a real understanding of your organizations operating model something that can really work by having clearly defined classifications for concepts in terms of organizational span. Combine these with governance based on the desired operating model and you have a pretty mature method for controlling the usage of EA concepts within the organization.

Original post