We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Anatomy of Agile Enterprise

Janne J. Korhonen

Maturity Begets Agility

Vote 0 Votes
Counterintuitive it may seem, agility does not come with an abandonment of rules, but actually requires more organizational discipline. Mature organizations do things systematically, while immature organizations achieve their outcomes as a result of the heroic efforts of individuals (Harmon, 2004). As illustrated in Figure 1, the agility of an organization co-evolves with its architectural maturity.
Figure 1. Architectural maturity begets enterprise agility.

In my previous blog post, I discussed how organizations face the need to co-develop both their organizational and technological capabilities to varying degrees. Of course, it is not that an organization is either agile or not, or that architectural maturity is either the most advanced or nonexistent. There are several shades of gray in between.

A common approach to assess and develop a specific capability in an organization is to devise a respective maturity model that provides an evaluative and comparative basis for improvement (Rosemann et al., 2006). The common base for the majority of maturity models is the Capability Maturity Model (CMM) framework (SEI, 1995) by the Software Engineering Institute (SEI) of Carnegie Mellon University (CMU). CMM defines five levels of maturity with '5' representing the highest level. Higher degrees of maturity are likely to lead to higher agility, but as each organization has an ideal level of maturity, higher does not necessarily mean "better" (OSIMM, 2009).

In the following, I will subscribe to the five-scale ordination of maturity and outline a view of architectural maturity levels with regard to Service-Oriented Architecture (SOA) and Business Process Management (BPM). Each maturity level builds cumulatively on the foundation of previous levels.

Level 1: Initial

The organization at this level is siloed. Each unit, be it functional, geographic or focused on a product, optimizes its own efficiency without end-to-end coordination of efforts across the organization (Fisher, 2004). There is no awareness of aligning business strategies, drivers and principles and IT strategies, drivers and principles (IFEAD, 2004).

The application landscape is largely unintegrated, consisting of "islands of automation" and "green screen" legacy. There is no integration of data, processes, standards, or technologies, and the IT systems cannot be integrated without significant manual intervention, such as re-keying and re-interpretation of data (OSIMM, 2009).

Business processes are performed in inconsistent, sometimes ad hoc ways with results that are difficult to predict. There is no explicit process or organizational support. (OMG, 2008). The processes are characterized by high levels of manual interventions and workarounds. Approaches to methodology, tools and techniques are various and not consolidated. (Rosemann et al., 2006).

Level 2: Managed

The organization is still built around functions and suffers from the lack of alignment around end-to-end, enterprise-wide processes. IT provides some level of cross-functional efficiency through data integration and process standards, but there is little or no enterprise-wide governance that provides the structure necessary for end-to-end alignment (Fisher, 2004).

The applications are integrated to support key business functions. EAI approach (Enterprise Application Integration) is adopted but with proprietary connections and integration points (Arsanjani and Holley, 2005). Thereby, integration does not extend to common standards in data or business processes (OSIMM, 2009).

The organization starts to recognize the importance of BPM and the executives and top management become increasingly involved. First business processes are documented and modeled and first attempts with a structured methodology and common standards are made. (Rosemann et al., 2006). The work can be performed in a repeatable way, yet work units performing similar tasks may use different procedures (OMG, 2008).

Level 3: Defined

Here, the organization undergoes an important mind-shift from functionally oriented to process driven. This step requires a top-down mandate: "enterprise-wide leadership and a supporting team that will be responsible for end-to-end process optimization, as well as the controls and governance needed to enforce the decisions of this leadership team" (Fisher, 2004).

The organization is implementing first Web services for SOA: low-level entity services "fine-grain" orchestrations over native endpoints to automate STP parts of its business processes. The IT systems have been analyzed and broken down into discrete and re-usable component parts, but these components are often replicated and redundant (OSIMM, 2009).

Business Process Management focuses on the management of the early phases of the process lifecycle employing a combination of different methods and tools (e.g. process re-design, workflow management, process-oriented EAI). Standard processes are synthesized from best practices identified in the work groups and provide an economy of scale and a foundation for learning from common measures and experience (OMG, 2008).

Level 4: Quantitatively Managed

The organization at this level has established its focus on processes, is committed to continuous improvement and utilizes business-focused metrics to increase its efficiency and effectiveness (Fisher, 2004).

The organization has started to adopt Service-Oriented Architecture, is SOA-enabling its application and integration legacy and is implementing new business functions as SOA services. Composite services are being orchestrated within a BPMS process implementation. The organization is using ESB and service registry as well as requisite security, logging and monitoring faculties for SOA. Through virtualization, the service is more closely coupled to the infrastructure (OSIMM, 2009).

Work processes are managed quantitatively to establish predictable results (OMG, 2008). The IT and business perspectives on process management are merged. Process orientation is a mandatory project component and process management initiatives are continuously extended and consolidated. There are formal, designated process management positions and the reliance on external expertise is minimal. (Rosemann et al., 2006).

Level 5: Optimizing

The organization extends its improved capabilities throughout the end-to-end value chain involving its partners that also adhere to the optimal characteristics (Fisher, 2004).

The organization has adopted a full-fledged SOA and extended the service management to the enterprise scale. It may employ service choreography on an end-to-end business process scale. The organization is using advanced BPM/SOA technologies such as BAM (Business Activity Monitoring), BRE (Business Rules Engine), WSM (Web Services Management), and CEP (Complex Event Processing). The assembly of business processes may be performed at runtime (OSIMM, 2009).

Process management becomes business as usual -- a part of managers' activities, accountabilities and performance measurements. Business process lifecycle management is established and there is one organization-wide approach to business process management that incorporates customers, suppliers, distributors and other stakeholders. (Rosemann et al., 2006). Both proactive and opportunistic improvement actions seek innovations that can close gaps between the organization's current capability and the capability required to achieve its business objectives (OMG, 2008).


Arsanjani, A. and K. Holley (2005). "Increase flexibility with the Service Integration Maturity Model (SIMM)". IBM developerWorks white paper.
Fisher, D. M. (2004). "The Business Process Maturity Model: A Practical Approach for Identifying Opportunities for Optimization". BP Trends. September 2004.
Harmon, P. (2004). "Evaluating an Organization's Business Process Maturity". BP Trends. March 2004.
IFEAD (2004). "Extended Enterprise Architecture Maturity Model". Version 2.0. Institute for Enterprise Architecture Developments
OMG (2008). Business Process Maturity Model (BPMM), v. 1.0.
OSIMM (2009). The Open Group Service Integration Maturity Model (OSIMM). Technical Standard. The Open Group.
Rosemann, M., de Bruin, T. and B. Power (2006). "A Model to Measure Business Process Management Maturity and Improve Performance". In: Jeston, J. & J. Nelis (2006): Business Process Management, Chapter 27. Butterworth-Heinemann.
SEI (1995). The Capability Maturity Model: Guidelines for Improving the Software Process. Software Engineering Institute. Reading, MA: Addison-Wesley.

Janne J. Korhonen provides insights into how information technology can be applied strategically to catalyze organizational change and responsiveness. Drawing from both theory and practice, he discusses agile enterprise and its governance.

Janne J. Korhonen

Janne J. Korhonen is an independent business and IT consultant,specializing in enterprise architecture, business process management,service-oriented architecture and pertinent governance models. He has over ten years of experience as an architect and consultant in a variety of extensive and mission-critical IT projects. With strong theoretical underpinnings, his consulting encompasses systemic co-development of business, organization and information technology.

Recently Commented On

Recent Webinars

    Monthly Archives