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

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

Are You Modeling Too Many Processes?

Roger Tregear Roger Tregear on November 7, 2014

Modelling processes

Too often, the theory, practice and aspirations of process-based management are reduced just to process modeling. A stated intent in some organizations is that “we will model all of our processes”, and this is said as though achievement of this goal would solve some serious business problem. In reality, there is never a business problem called “we don’t have enough process models”, and an inappropriate focus on modeling severely handicaps the achievement of genuine process management.

Why model processes?

There are four general purposes for process modeling: document, understand, improve, automate.

  1. Document: describing how a process is meant to work enables consistency, quality and standardisation
  2. Understand: understanding the detail of how a process works gives insight into what works well and what might be able to work better
  3. Improve: discovering ways in which the process might work better is enabled by modelling and testing the possible changes
  4. Automate: using the process models as input to a process execution system is increasingly the way that IT applications will be built.

Enterprise Process Architecture (EPA)

Every organization should have an Enterprise Process Architecture (EPA), a hierarchical model of the first three levels of its business processes. Individuals processes in the EPA, and there may be hundreds of them, need only be identified as a single object (a box of some form depending on the graphic notation being used). The EPA model is about identifying relationships between processes, rather than the details of individual processes. Modeling the process detail is then undertaken on demand; it’s done to address a particular problem or opportunity. Therefore, detailed process modeling should be done as part of a process improvement project that has a very clear organizational performance goal.

Should we model all of our processes?

Some processes will never be modeled if there is never a good reason to do so. Looking through an EPA, we should find that some processes have been modelled in lots of detail and to many levels, others will have been modeled only at higher levels, and others will have never gone lower than the original single box. Addressing process issues will always be a matter of prioritizing scarce analysis resources. Modelling ‘everything’ is waste.

Next time someone says “We should model all of our processes”, ask the important question “Why?”

Topics: EA - Enterprise Architecture