Enterprise Unified Process: Overview

The Enterprise Unified ProcessTM (EUP) extends iterative/agile processes such as Disciplined Agile Delivery (DAD), Extreme Programming (XP), or Scrum to address the real-world needs of IT organizations. There are two categories of extension, depicted in Figure 1. The first extension is full software lifecycle support, which includes the addition of a Production phase, a Retirement phase, and the Operations & Support discipline to extend the development process to become a full delivery process. The second extension is for full IT lifecycle support. Not only do you develop, operate and support systems you must also address all of the cross system issues as well. The EUP adds seven core enterprise disciplines to extend software development processes to be sufficient for real world organizations. This article summarizes these seven disciplines.

Figure 1. The EUP lifecycle: 2013.

Much of the difference between the EUP and software development processes such as DAD, Scrum, and XP lie in their scope. The scope of software development processes is the development of a single system, including at least one or more typically several production releases. The EUP, however, is concerned more with issues that reach across multiple systems. It extends software processes to address enterprise issues. As such, it deals with concepts that do not apply to just a specific system. Some activities, therefore, will occur outside the context of a specific project.

1. The Core Enterprise Disciplines

This article provides an overview of the core enterprise disciplines, formerly encapsulated by the Enterprise Management discipline (originally called the Infrastructure Management discipline) in previous versions of EUP. It overviews the disciplines of the enterprise discipline and presents a high-level view of the activities that take place within each. It is not meant to be the definitive description of these disciplines but rather an introduction.
The seven disciplines are:

Enterprise Business Modeling
Portfolio Management
Enterprise Architecture
Strategic Reuse
People Management
Enterprise Administration
Software Process Improvement

1.1 Enterprise Business Modeling

The Enterprise Business Modeling discipline extends business modeling to enable your organization to explicitly realize the benefits of doing so outside the context of a project.

The goal of the Enterprise Business Modeling discipline, also sometimes referred to as enterprise requirements modeling, is to enable you to understand and effectively communicate the business that your organization is engaged in. It explores both the business process that your organization engages in as well as the overarching business requirements for the software applications that support it.

During the Inception phase of individual projects more detail may be added to the Enterprise Business Model (EBM) as project teams delve into the finer-grained details of their own business models. The team should start with the EBM as the base, explore the pertinent details for their project, and then provide feedback to the enterprise business modelers so that the EBM may be evolved.

1.2 Portfolio Management

The Portfolio Management discipline enables you to track and plan your organization’s entire collection of software systems (proposed, in development, and in production). Organizations often have families of related applications, often called programs, that can be better managed as groups rather than as individual applications. Doing so allows them to implement new requirements appropriately and plan development / deployment of requirements better. This also helps to avoid implementing the same functionality within different applications. Throughout the lifetime of the organization the portfolio management team convenes on a periodic basis to review business requirements and product enhancement requests and plan out product releases. The length of this cycle will vary depending on the organization; a quarter or year is typical. Between the periodic release planning sessions, the team is gathering requirements and enhancement requests for the next planning effort and shepherding projects. The effort expanded to do this is minimal; hence, the relative lulls between the product release planning sessions. The initial effort issomewhat larger because the team must also identify product families for the first time.

There will be some effort before a project begins, what I call “Iteration -1” on agile projects, and during the Inception phase (Iteration 0) as the project team further defines the objects for the project and requires clarification. At the end of project phases, there is a small amount of effort to update the product families with the status of the project effort. At the end of the Production phase, there is a slightly larger effort as plans for the replacement / retirement of the system is executed.

1.3 Enterprise Architecture

The Enterprise Architecture discipline defines the enterprise architecture of an organization. It consists of models that define it, reference architectures, prototypes and working models that demonstrate how it works, and frameworks that make it easier to use. An enterprise architecture model is a representation of the structures and processes of an organization; a good one depicts the organization both as it is today and as it is envisioned in the future, and maps the various views representing the architecture to one another. These views include both business-oriented perspectives as well as technical perspectives. In many ways enterprise architecture models are a communication bridge between senior business stakeholders and senior IT professionals.

Enterprise Architecture efforts will slowly increase initially as the EA team gradually builds up the enterprise architecture for the first time. When the enterprise architecture stabilizes, efforts will diminish. From that point on, work will ramp up as new technologies are adopted and new products and services are added and ramp down as they stabilize. On RUP projects enterprise architects may be involved in the latter part of Inception and throughout Elaboration as they assist / review / mentor application architecture efforts.

1.4 Strategic Reuse

The goal of the Strategic Reuse discipline is to enable you to develop applications quicker and of higher quality by reusing artifacts instead of developing them anew each time. Reuse helps to improve quality because it allows you to use artifacts that havealready been tested and proven to work by previous development teams.

The reuse effort increases initially as the team defines the approach that they will take and organizational and process changes are made to support the reuse initiative. The effort will peak as reusable assets are created and deployed. Efforts will diminish as assets are supported more than new ones are deployed and cycle up when new assets are identified and developed.

Reuse can be involved in the Inception phase of projects as Reuse Architects mentor application teams while they are formulating candidate application architectures on how they can apply reusable assets. During Elaboration, they will be more involved as the application teams define, prototype, and describe the application architecture. They will assist teams in deploying and extending reusable assets during Construction as well as mining application assets for potential reuse.

1.5 People Management (Human Resources)

There is far more to project management than the technical tasks of creating and evolving project plans. You also need to manage your staff and mediate the interactions between them and other people. People Management is the act of organizing, monitoring, coaching, and motivating people in a manner that ensure they work together well and contribute to a project/organization positively.

People Management efforts are fairly constant outside of projects, as people are hired, released, trained, plan and execute career plans, etc. Efforts increase at the beginning of the Inception phase as the overall staffing plan for the project is created. Working with Human Resources, the correct resources are identified and then staffed at the end and the beginning of each of the remaining phases and iterations.

1.6 Enterprise Administration

Enterprise Administration discipline efforts involve maintaining and supporting the technical and development infrastructure for your IT department. This includes but is not limited to data administration activities, network administration, tool support, and hardware support. Enterprise Administration efforts occur on a constant basis for the enterprise. For projects, they increase during the middle of both the Inception and Elaboration phases, as the requirements for the systems are identified and need for tools and administration for development environments are identified and implemented. Similar activities occur in the Construction phase and at the end of the Transition phase. Administration also occurs during the Production phase as the infrastructure is maintained and updated to support systems in production, and similar efforts occur as systems are sunsetted during the Retirement phase.

1.7 Software Process Improvement

The goal of the Software Process Improvement (SPI) discipline is to manage the software process for the enterprise. This includes
eliciting the needs of the organization regarding software process, definition of the process(es) to be used by the organization, proving of the process(es) (via pilot projects, for example), and documentation and publishing of the process(es). This also includes collecting appropriate metrics and analyzing them to enable tuning of the process(es).

SPI efforts will run in cycles as processes are adopted. The earlier cycles will contain more effort as processes are identified and adopted for the first time in the organization. Subsequent cycles will require less effort in general although a significant change in process philosophy may expand more effort. Software Process Improvement activities never fully cease for mature organizations as they constantly monitor and adjust their processes. The hump at the end of Transition (the end of a project) signify the process retrospective that is done at the end of each project to feed process improvement efforts.

2. In Closing…

This paper presented an overview of the enterprise disciplines of the Enterprise Unified Process (EUP). Like all the disciplines of the EUP (and the RUP, for that matter), it is not expected that organizations implement the enterprise disciplines verbatim. Organizations must look at their needs and wants and then decide what is appropriate for them. These disciplines should be tailored and adopted in a well-ordered manner (see Adopting the Enterprise Unified Process for details).