<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1907245749562386&amp;ev=PageView&amp;noscript=1">

Bringing together project requirements in ARIS

Anita Halse Anita Halse on January 4, 2016

We all agree it is important to monitor, track and report on the ‘common theme’ that runs through IT projects – such as implementing or developing a new system from initiation stage to rollout and implementation phase. In this article, we discuss how the requirements and artefacts – use cases, functional specifications, technical specifications and prototypes – can be managed effectively during the project’s life cycle.

The concept of monitoring these artefacts from ‘cradle to grave’ (inception to implementation), leads to a myriad of questions:

  1. Is it possible to manage all these documents, spreadsheets, artefacts, and deliverables in a central place?
  2. How can we follow the ‘common theme’ from use case to functional specification to technical specification?
  3. How can we track, monitor and manage them in a central repository?
  4. How do we version, minor and major, and track changes?
  5. How can we re-use these and make them available to other projects?
  6. How do we ensure ‘a single version of the truth’?
  7. How do we re-use architectural artefacts (organisational structures, application systems, etc.)?
  8. How can we manage central libraries of governance, risk, requirements and controls?
  9. Is there the ability to govern access to this information?

The Project Management monster and its artefacts!

During an IT project’s life cycle, numerous tasks and activities are facilitated and managed. These may include, but are not limited to:

  • Management approval, which is obtained by signing off on business cases, as well as functional and technical
  • Business and technical
  • Design review – by validating the wireframes (ARIS/OBPA screen navigation and screen design diagrams).
  • Software development and programming – the system/user interaction and expected sequence result are further annotated in UML activity
  • Documentation and training – user and

Risk is mitigated by maintaining complete records of project activities in a central repository, and providing a periodic review of project activities and artefacts.

Bringing it all together

These project requirements can successfully be hosted in tools such as ARIS.

From the UML Use Case diagram:


This illustrates the processes and represents the business system under analysis. The UML Use Case diagram defines the scope of the project, and is the root of the functional decomposition at the conceptual level of detail.

New Call-to-action

Topics: EA - Enterprise Architecture, BPM/EA Technology

Why inventory of IT applications is business critical

Frederick Halas Frederick Halas on December 31, 2015


IT applications contribute to the support of business processes, or other applications, thanks to the execution of IT software. Directly or indirectly, IT applications have one main  purpose: supporting the business in the most efficient way. They can be considered as an asset of the enterprise.

Either custom developed or packaged, IT applications represent a cost: licenses, maintenance, customization, development, running fees, etc.

In a large organization, due to reorganization, acquisitions or lack of coordination, it is hard to keep track of which business processes are supported by which applications.

An inventory of IT applications, united with process descriptions, is the necessary foundation to answer the following questions with fact-grounded confidence:

  • What are the applications that support the most critical processes, and which require attention and investment?
  • Are there applications that are unused (or barely used) for which recurring fees occur?
  • Is it possible to reduce costs by using one application instead of many for the same business purpose?
  • By virtue of the dependencies between applications, is business continuity at risk if there is an IT failure?

Information quality is key

An outdated list of applications (or many disparate sources of information about IT applications) cannot be used as a solid reference; no business decisions can be taken on that basis. That’s why a central inventory of applications needs to be maintained.

Moreover, to allow the level of analysis required to answer business-related questions, it is necessary to link the applications to business processes representations; a repository is required.

An applications repository reaches an optimal level of quality when all necessary information is collected, signed-off, and kept up-to-date.

There are two types of information that need to be recorded:


These store the properties of applications: unique enterprise-wide Identifier, name, description, responsibilities, support responsibilities, and assessment of criticality, which can be in the form of a tiered classification, current operational status, indication of update strategy, number of users, etc.


Using a repository that integrates a database allows the relationships between applications and other representations to be documented. Relations allow impact-analysis queries between applications and the software products they use, the vendor providing them, the main functionalities they support and, eventually, the processes they support.


It is recommended that a quality-assurance mechanism be put in to assess the calibre of application documentation for completeness of required attributes (semantic quality) and existence of relationships (syntactic quality). It should also include an assessment of the validity of the recorded information.

A pass score can be established to determine which applications descriptions are ready for sign-off and promotion to the library.

Building the applications architecture is a process.

Building an application’s inventory is a process that transforms a heterogeneous, redundant and uncontrolled list of applications into a controlled catalogue placed under the responsibility of the subject matters experts.

To reach the level of information quality required for trustworthy reference and reporting, it is necessary to ensure that each application is identified, documented, and signed-off by the persons in charge of them within the enterprise.

Application inventory – constituted by the applications, their attributes, and relations to other objects – is structured content stored in a database. Yet, it is important to make sure that initial unstructured, incomplete, or approximate content may be taken into account as an initial input.

During discovery phases, a modelling tool that allows collaboration and sharing of application architecture views can be used. Eventually, created application architecture views constitute the graphical communication of the application inventory content stored in the database.

Once it has been signed-off, an application is ready to be placed under architecture control. It is promoted to a library. The library contains validated content and is presented strictly according to conventions. The content of the library is the trusted reference.

Write access to the library is strictly controlled to prevent accidental or uncontrolled modification of the application’s library.


Last recommendations

Deliver services

It is important to stay focused on business needs. When possible, adopt an agile approach to allow rapid implementation and rapid adjustments to the specific needs of users and stakeholders. Try to address immediate needs as much as possible (like the production of reports to illustrate dependencies between applications supporting a specific process).

Facilitate learning

Allow a smooth and progressive adoption of the application inventory building process (it’s a group-learning exercise). Keep it easy. Develop simple conventions, and create a project space where creativity is allowed and mistakes have no consequences. When collecting input from subject matter experts, privilege ‘focus on content’ instead of ‘focus on layout’ or presentation. When possible, make the most of available collaborative software that allows easy screen sharing and cooperation across the enterprise.

Enforce reference material

The application inventory must become referential, communicated, understood and used across the enterprise. It can then be used with confidence for business analysis, planning, and the design of future solutions.

To allow comparison and optimisation, when possible, describe applications by mapping relations to readily available enterprise-wide reference material, like a common application domains model.

Unite with business processes

Applications support business processes: it’s a good way to track an application’s fitness for business purpose.


 Enterprise Transformation EA




Topics: EA - Enterprise Architecture, BPM/EA Technology

The Role of Tools in Process Governance [Infographic]

Daniel Weatherhead on December 3, 2015


Topics: BPM/EA Technology

9 Benefits of Process Measurement

Roger Tregear Roger Tregear on December 1, 2015

15_Blog_9_benefits_process_measurement-1.jpgProcess performance measures are the ‘vital signs’ of organizational health, providing a current status assessment, giving clues to possible health issues, and showing progress towards recovery.

A government organization implementing a new service did a lot of planning, created a large number of process models, and had many sessions with a wide range of stakeholders. Green lights everywhere, so the service was launched with appropriate ‘ribbon cutting’.

Two days later, all were relieved that the launch had gone well; two weeks later, there was a slowly rising murmur of complaint; two months later, service delivery was in virtual gridlock and the murmur was a cacophony. A month after that, it was finally discovered that a key process in the service delivery was often failing, causing significant rework and introducing inordinately long delays. Further analysis found ways to reduce the delays by 95%.

After resolving the backlog, normal service delivery resumed. Customer, and staff, memories of the fiasco will, however, never be erased.

It didn’t need to be like that.

Careful analysis of process performance expectations before launch, and appropriate measurement of process performance from launch, would have either avoided the problem completely, or detected it early and allowed resolution before it became a major issue.

A great deal can be gained from effective process-based management, but every organization has the right, indeed the obligation, to demand that those involved continuously demonstrate that the promised benefits have been realized.

The process of process management also needs to be constantly improved.

For this to be possible, there  must be regular assessment of the effectiveness of the changes made. Process practitioners are not in the business of just making recommendations; their purpose is to make positive change—and to prove that they have done so.

Measuring business process performance delivers many benefits:

  1. factual evidence of customer-service levels
  2. better understanding of cross-functional performance
  3. enhanced alignment of operations with strategy
  4. evidence-based determination of process improvement priorities
  5. detection of performance trends
  6. better understanding of the capability range of a process
  7. uncovering actual and latent problems
  8. changing behavior based on factual feedback
  9. improved control over the risks that really matter.

BPM initiatives that do not incorporate process measurement will fail. Process measurement is not always easy, but it is always possible.

Process Measurement BPM



Topics: BPM/EA Technology

Putting Practical Process-based Management Into Operation

Roger Tregear Roger Tregear on November 12, 2015

What’s the problem?

My favorite question is “What’s the problem we are trying to fix?”— so we should start with that.

In thinking of BPM as a management philosophy, we mean to effect ‘process-based management’. This means that the cross-functional processes that every organization uses to create, accumulate, and deliver value are central to strategic, operational, and tactical management. To do that, we identify the processes, set performance targets, create governance mechanisms, and improve process performance in a process-aware culture where everyone contributes and appropriate support is provided. I have written about and presented this sequence extensively including in a BPTrends columnand also here and here.

We can easily see the required components, and it’s not so hard to imagine them all working harmoniously together in some future state. What is not so easy to see is how to reach this nirvana. How do we get from the pristine theory of everybody being ‘process-centric’, to the gritty reality of managing a real organization with all of its complexities, latencies, impossible demands, and human frailties? How do we operationalize process-based management in a practical and sustainable way?

That’s the problem. Let’s see if you agree that the Circles help provide the answers.

The Circles

First, a recap of the basics of the Circles.

Without conscious attention to cross-functional processes, nobody is responsible for the creation, accumulation, and delivery of value to customers and other stakeholders. The organization chart is silent on this issue. All organizations seek to deliver value but, without a relentless focus on business processes, there is a critical gap between aspiration and reality. Too often, process improvement initiatives are ‘random acts of management’ without a systemic foundation. 

PO Circle

The Process Ownership (or PO) Circle is continuously testing for actual or emergent process performance gaps and opportunities. Set a performance target, measure what is happening, explore what could be happening, and respond if the variance is enough to warrant intervention. This target-assess-respond sequence is the essential cycle of process-based management, ensuring unrelenting focus on improving process—hence, organizational performance. For many, this is a new way of thinking and working. The novelty is not in the idea of measurement or reporting, but in measuring and reporting process performance rather than just the performance of organizational units—that is, focusing on value creation pathways from the process architecture, as well as resource-management objects from the organization chart. This is the core of the Process Owner’s[1] role.

PI Circle

The Process Improvement (or PI) Circle identifies the current state (As Is), defines the future state (To Be), and determines and executes the transformation (To Do). Across the spectrum, from small adjustment to significant innovation, the PI circle delivers process performance change. Irrespective of the detailed process analysis methodology employed (the Circles are methodology agnostic), the PI circle addresses the process performance anomalies and opportunities discovered via the PO circle.

Importantly, the PI cycle starts and finishes with As Is. The objective is not to design the To Be, nor is it enough to create the plans for change (To Do). What is required is not just a new To Be or a To Do, but a new As Is. To be credible, process improvement must produce results—that is, improvements in organizational performance. This must be true both for large innovative change and smaller corrective change. While the PO Circle continues to monitor process performance, the PI circle realizes demonstrable and objectively measureable business benefits.

The PI circle discovers the problems we are trying to solve, and opportunities we are trying to realize; it pushes the envelope to find all the possible change ideas, and then executes the best. It is a conscious, deliberate, repeatable process that is applicable for any scale of process change.

Organizations focused on continually improving and innovating their creation, accumulation, and delivery of customer value have process thinking embedded in their culture and practice. The Circles operationalize process-based management.

[1] There are many terms used to describe the Process Owner role, and all of them are wrong in some way. I use the Process Owner term here because it is the most common. I have recently been quite taken with the alternate terms Process Trustee and Process Guardian.

 Get the Cirlces Turning

Topics: BPM/EA Technology