<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:

15_ARIS_Project_REquirements.png

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

15_DEC_Blog_IT.jpg

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:

Attributes

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.

Relationships

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.

15_ITCritical.jpg

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.

15_ITCritical2.jpg.png

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 Need for Enterprise Transformation

Frederick Halas Frederick Halas on September 2, 2015

15_Blog_July-1-2

If you were asked to draw a picture of an enterprise before its transformation and a picture after its transformation, like in the classic before/after house renovation advertising, what would it look like?

As an enterprise architect looking for a way to represent an enterprise, we can interrogate TOGAF. It tells us that an enterprise is a system of systems, and that Enterprise Architecture is about managing enterprise transformation toward a target operating model; unfortunately TOGAF does not tell us how to draw a system of systems.

Fortunately there is a model, recently re-introduced by Patrick Hoverstadt in his book “The Fractal Organisation”, which is just about that, i.e. representing enterprise organisation as a system of systems. The Viable System Model tells us how viable organisations need to be structured in order to deliver their expected outcomes within their environment. For instance a malfunctioning performance management relationship between management and the operational units, is seen by the VSM as a structural defect, developing imbalances which affect the enterprise viability.

The VSM provides a mental model to observe, question and assess how an enterprise existing operating model compares to the required ingredients of viability. So, the picture of an enterprise before and after its transformation could probably be drawn with the help of the VSM.

Here is what TOGAF says about itself: TOGAF is “a framework for managing the spectrum of change required to transform an enterprise towards a target operating model” (in the TOGAF® Version 9.1 Book – Chapter 4.2 The Benefits of TOGAF).

Often, the enterprise’s capacity to deliver its expected outcomes is stressed in the face of both expected and unexpected changes in its environment.

The gap keeps widening between the strategic intents and the actual outcomes. The enterprise viability deteriorates, and its operating model no longer fits its environment.

Our enterprise in need of transformation could be pictured with people’s faces showing how much they appreciate being submitted to unclear or conflicting directives on broken or misaligned activities, and supported by less-than-smoothly operating pieces of technology.

Enterprise_Transformation_Viablity

However, this picture might not be detailed enough to show which parts of the enterprise operating model require work.

If, like TOGAF 9, we consider our enterprise as a system of systems (“Enterprise architecture structures the business planning into an integrated framework that regards the enterprise as a system or system of systems” TOGAF® 9.1 web > Part II: Architecture Development Method (ADM) > Preliminary Phase> Relating the management frameworks), then it would be interesting to try to represent that extra dimension of systems.

 

Enterprise Transformation EA

Topics: EA - Enterprise Architecture

4 things to remember when creating Business Process Architecture (BPA)

Roger Tregear Roger Tregear on July 20, 2015

Case-For-Process_fig1

Creating a BPA is not a trivial exercise, and since it will always be subject to change and the exploration of greater detail, it is a never-ending job. Nevertheless a useful, working BPA can be developed in a few months and the immediate value of doing so can be remarkable. Quite apart from creating a solid basis for effective ongoing process management, discovery of the BPA focuses the organization wonderfully on really understanding how it executes its strategic intent. This article details why Business Process Architecture is crucial as a strategic and operational management tool. 

Here are four practical steps you might consider doing now to get started on the creation Business Process Architecture (BPA)

  1. Just build it 

    You (yes, you) don't need permission to start building a BPA for your organization. Find the strategy statements and determine who are the customers and others stakeholders and your organization's value proposition for them. These are likely your core highest level processes (I'd call them Value Chains). Start decomposing those processes. You will need permission and agreement (and lots of it) to make it official, but you can start right now without anyone's approval.
  2. Hang it on the wall

    Once you've got something you and a few others think is reasonable, socialize it on internal websites or notice boards. ‘Hang it on the wall' and see what people say. Give folks the opportunity to comment and take note of who comments as well as what they say.
  3. Test performance

    Pick a process and try to measure its performance. If it was working well, how would you know? How is it performing? Is the performance gap something that should be fixed now?
  4. Continue the Discussion

    You've started the process performance discussion with a group of people who have expressed interest in the idea of process and the BPA. Keep talking.

 

New Call-to-action

This article was originally published at www.BPTrends.com

Topics: BPM - Business Process Management, EA - Enterprise Architecture

Building an IT application inventory: a return on experience

Frederick Halas Frederick Halas on March 27, 2015

15StockPicks-21

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: licences, maintenance, customisation, development, running fees, etc. In a large organisation, due to reorganisation, acquisitions or lack of coordination, it is hard to keep track of which business processes are supported by which applications.

A trusted IT application inventory, 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:

Attributes

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.

Relationships

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.

 Relationships

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.

 Models

 

 

Final Thoughts...

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.

Download Paper 4 Things to Remember When   Building Enterprise Architecture Capability

 

Topics: EA - Enterprise Architecture