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

Vertical Dimension of Enterprise Engineering

user-pic
Vote 0 Votes

Recently, I have been writing quite a lot about Requisite Organization, a cognitive-developmental meta-theory of the organization. To put this rather abstract notion into a more concrete context, I will outline in the following a model of how to apply the work-levels approach – the vertical dimension – to enterprise engineering.

The scope of analysis here is a self-governing organization such as a middle-size business or an independent business unit of a large corporation at Stratum V complexity. At each level, the following aspects are briefly described:

– The key question word, such as Why, What, Who, that epitomizes the essence of the level.
– The level of design descriptions at each level.
– The level of development at each level.

Stratum VI, which provides an external context to the organization, is also described. The six levels of enterprise engineering are depicted in Figure 1.

enterprise_engineering.jpg
Figure 1. Levels of Enterprise Engineering

VI – Why?

The highest level views the organization from outside – why does the organization exist: what are the market drivers that have an impact on its strategic focus? The strategic focus states the mission, vision, goals and principles of the organization and has a significant impact on all the subsequent choices pertaining to business models, capabilities, processes and systems. In the large corporation setting, the strategic focus is formulated within the corporate realm.

V – What?

At this level, strategy is further specified: what is the business model, what are the organization's distinctive competencies, what is its scope?

Strategic Architecture at this level is “a summary formal description of the enterprise, providing an organizing framework for operational and change activity, and an executive-level, long-term view for direction setting”. It assists New Business Development in devising creative strategies that seek optimal congruence with the environment. These strategies are translated to Business Requirements that then drive Business Change at the next level down.

IV – Who?

At this level, the organization is divided to functions and the question comes down to who is responsible for what in producing a product or providing a service, either in the current situation or in the predicted future. Business Change happens through pairwise comparisons of the as-is solution with related to-be alternatives, leaning on Segment Architecture – “a detailed, formal description of areas within an enterprise, used at the program or portfolio level to organize and align change activity”. The to-be work system is specified in terms of its constituent Functional Requirements.

III – How?

This level deals with operating and developing socio-technical work systems that use information, technology, and other resources to produce products and services. These activities are supported by Capability Architecture, i.e. “a highly detailed description of the architectural approach to realize a particular solution or solution aspect”. Functional Requirements are typically specified in Use Cases that describe how the work system behaves, or should behave.

II – When?

At this level, information systems are developed and integrated to support the solutions at the higher level. System Architecture is “a means for describing the elements and interactions of a complete system including its hardware elements and its software elements”. Requirements specifications, such as scenarios, at this level must address time constraints and explicit sequence of activities. Typical specification artifacts include sequence diagrams and activity diagrams.

I – Where?

This is the level of application development that addresses the question of where: Where is the truth? The truth is in the code. The focus is on static aspects of the system: objects, classes, database tables. Technical Design at this level “prepares an implementation area for construction and installation. The key tasks are structured to produce a system and database that meet the user's acceptance criteria and are technically sound”. Test Cases at this level represent requirements of the highest specificity: discrete, testable units of software behavior.

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

    Blogs

    ADVERTISEMENT