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

Frederick Halas

Frederick Halas is a Senior Consultant at Leonardo Consulting (www.leonardo.com.au). Frederick joined Leonardo consulting after more than 15 years’ experience in software development, related methodologies and enterprise architecture capability development.
Find me on:

Recent Posts

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

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

4 things to remember when building enterprise architecture capability

Frederick Halas Frederick Halas on March 16, 2015

What is an enterprise architecture capability?The purpose of this post is not to be exhaustive when it comes to list the widely discussed enterprise architecture (EA) success factors (like the need for C-level management support, or the necessity to remain consistent with an industry framework like TOGAF), nor is it to justify why architecture should be an essential asset1 of any organisation. Rather, it is to look at four important aspects that are essential to understand the nature of the capability that makes EA actionable, and to prepare for the challenges.

1. It should deliver services.

This is what people expect; they don’t really care how you get there, as long as you deliver the promised services.

2. It should be process centric.

This is the only way to focus on the end purpose of an organisation.

3. It relies on reference.

A common language must be used to create reference material. Only organisation-wide reference material will allow the necessary integration for comparison and optimisation..

4. It is a learning exercise.

A learning exercise where the organisation as a whole is the learner. The pace of learning is slow; each new acquired capacity is a small step at an individual level, but a tremendous improvement at an organisation-wide level.

Organisations often consider enterprise architecture when in need for a lasting foundation that can be trusted to assess and support change decisions. At Leonardo Consulting, we don’t think that our work is to relay any definitions of EA to our clientsparticularly as there are no definitive ones. The term ‘enterprise architecture’ could disappear and be replaced – I like ‘enterprise intelligence’, but that is not the point.

In short, enterprise architecture capability enables an organisation to assess and control its transformations in a robust manner, thanks to a reliable source of knowledge.

Download Paper 4 Things to Remember When   Building Enterprise Architecture Capability


1  John A. Zachman article - You can’t “cost justify” Architecture - 2001
2  Roger Tregear’s article – bpm capability and credibility June 2013 - http://leonardo.com.au/newsletter.html

 


Topics: EA - Enterprise Architecture