Read Enterprise Architecture: unlocking business potential

Enterprise Architecture: unlocking business potential

Kim Parker

Acknowledgements
Foreword - Tom Graves
Introduction
1 Knowledge
2 Enterprise Architecture
3 Business Performance
4 Organisation
5 Business Change

Acknowledgements

Amongst others, the following people kindly provided comments, advice, suggestions and feedback and encouragement on various ideas expressed in this book: Tom Graves (GB), Peter Tseglakof (AU), Tanya Parker (AU)

Please note that, to preserve commercial and personal confidentiality, the stories and examples in this book have been adapted, combined and in part fictionalised from experiences in a variety of contexts, and do not and are not intended to represent any specific individual or organisation.

Trademarks or registered trademarks such as Zachman, TOGAF, PEAF etc are acknowledged as the intellectual property of the respective owners.

Foreword - Tom Graves

First things first: yes, read this book. Buy this book. If you’re involved in enterprise-architecture and business-transformation - and particularly if you’re just starting out on your career in those fields - then you need this book. Simple as that, really.

Why? Well, a bit of background first. I first met up with Kim perhaps a decade ago, when we were both working on a business-transformation project for a large logistics organisation in Australia. It was a major piece of work, setting up a true whole-of-enterprise transformation, not just IT-systems, but business-processes, culture, quality, skills, facilities, the lot. Importantly, it wasn’t just a one-off change-programme, but about creating a new capability, to assist the business to manage change overall in the longer-term in a more effective way.

And that’s really the point of enterprise-archecture: everything affects and depends on everything else. Without the clear view of that ‘the everything’ that an enterprise-architecture provides, the tendency is to fall back to a view of only the small subset that’s directly affected by a single change - and thence to a ‘local optimisation’ which might at first seem to work well from the perspective of a single department, but will almost invariably lead to inefficiency, frustration, waste and poor overall performance.

The catch is that the scope of a real whole-of-enterprise architecture can seem to large for anyone to comprehend. The way round this is to treat the view more like a holograph than a photograph: each view into that whole might emphasise only one specific concern or domain, yet it’s always in context of the whole. Rather than attempting the impossible task of trying to describe everything at once in excruciating detail, we instead construct a story from small pieces, loosely joined, each somewhat self-contained, yet that together imply and iterate towards this overall sense of the whole.

Which is where, and why, Kim’s style of writing about enterprise-architecture becomes so useful. This doesn’t pretend to describe yet another grand scheme about ‘the truth of enterprise-architecture’. Instead, it’s a collection of small pieces, loosely joined, each providing its own succinct view into the whole EA space, and each drawn from hard-won experience in the everyday practice of real-world enterprise-architecture.

Those heavy academic tomes and formal framework-specifications do all have their place, of course. But for most of us, to most useful writing on enterprise-architecture looks like this: small succinct reminders of principles and themes that we can put to practical use, straight away, in our everyday work.

There’s no particular structure or sequences to these pieces: that’s actually part of the point. You can read it from cover to cover, of course, but you might well gain even more value if you dip in at random instead, and allow the strange processes of serendipity to bring you straight to what you most need right now.

Whichever way you read it, this is likely to be a book you’ll come back to again and again - and help you in new and different ways every time.

Enjoy! – Tom Graves, Colchester, England, July 2013

Introduction

All businesses, ranging from the ‘one man show’ through to multinationals and governments, can succeed or fail on the back of the decisions that they are constantly on call to deliver. The quality of the decisions that are made has significant influence on the outcomes that the decisions are designed to affect. The very nature of the decisions is affected by the quality, the completeness and the immediacy of the information available to the decision maker. Access to information, to feed into the decision making process, is strongly influenced by how business knowledge is managed.

Knowledge itself, either explicit or tacit, provides a level of understanding to business information which not having can render the information itself less than useful. The ability to leverage tacit knowledge, largely held in the heads of individuals, is a critical yet significantly underutilised asset. Explicit knowledge, codified perhaps into a repository, may be more easily accessed but still requires a means of interpretation. A business can only realistically aspire to reaching its full potential if it is able to establish a business strategy, define a road map describing how the strategy will be realised and have a repeatable process supporting the making of decisions along the way. An Enterprise Architecture provides a structured framework and business methodology by which:

Relevant business knowledge can be managed;
Processes can be applied to ensure appropriate information is captured and is properly maintained with a consequential increase in business confidence in its quality.
Guidelines can be provided to the business community explaining how to apply the contents to specific scenarios.

Its application is relevant to all businesses; not just the large and complex. The capability to make timely, properly informed and focussed decisions, with a high level of confidence that the expected outcome will be realised, permits a business to:

Identify and explore business opportunities that would otherwise have been closed;
Respond to change with confidence;
Perform with a higher level of operational efficiency;
Better manage the costs of doing business;
Realise business benefit sooner than they otherwise might;
Progress the realisation of their business vision.

An Enterprise Architecture provides a business with the opportunity to unlock its full potential. It provides a business with knowledge about:

Where it is heading;
Why it is heading there;
How to get there;
How to respond to inevitable change and the impact it will impart.

With the provision of appropriate information and the knowledge on how to use it an Enterprise Architecture supports the ability to achieve maximum business benefit and success in their endeavours.

Who should read this book?

This book should be read by

Decision makers;
Business and IT strategists;
Business Analysts;
Finance Managers;
Risk Managers;
Portfolio, Program and Project Managers;
Architects of all types

What is contained in this book?

This book contains extracts from my Blog ‘ The Knowledge Economy’. It explores my thoughts, observations and experiences on:

Knowledge and how it impacts a business;
Enterprise Architecture and the value it can provide;
Business Performance and
Business Change

Whilst the ‘Knowledge Economy’ Blog has no specific structure I have attempted to impose a very loose order within this book by at least grouping my writing into themes. Not wishing to ‘over-think’ the content I have maintained the integrity of the Blog and not ‘padded’ sections with additional words so that pagination within chapters worked better.

This book does not need to be read from the sequentially but can be dipped into at any point.

The Knowledge Economy blog can be found at:

www.theknowledgeeconomy.anorien.com

1 Knowledge

The Knowledge Economy

Knowledge is a vastly under rated and unvalued corporate asset. Whilst the ‘bean counters’ look at the ‘bricks and mortar’ they almost invariably fail to put a value on the knowledge that resides within their employee’s heads. This failure to recognise true value is a failure of the business itself.

Enterprise Architecture and the Knowledge Hierarchy

Every business, as it matures, is required to traverse the Data to Wisdom Hierarchy. How far it progresses and to what extent can determine the success or otherwise of the business itself.

Data: Is the product of observations of people and measurements and facts about the world in which the business resides.
Information: Is contained in the description of the data. It adds context through the application of patterns and structure allowing for the answers of questions such as who, what, where, when and how many?
Knowledge: Is attained in the ability to define what the information patterns mean in relation to the business and to consequently being able to apply the definition to create predictable future outcomes.
Understanding: Is the state where explanations of how and why the patterns exist can be expressed. Plausible predictions arising from being able to consider the actual causes relating to a business situation. Understanding allows for answering the question ‘Why?’
Wisdom: Provides the ability to perceive and evaluate the long-term consequences of behaviour allowing the business to better decide what to do when confronted by a situation in which it may or may not have experience. Wisdom allows for reliably being able to answer the question ‘What if?’

An Enterprise Architecture provides a means through which information on data collected from within the business can be contextualised, structured and analysed. Depending on how an Enterprise Architecture is expressed it may also provide predictive tools supporting the realisation of understanding and the acquisition of wisdom.

An Enterprise Architecture by itself contains neither understanding nor wisdom. Both of these states however can be realised in individuals using contents of the Enterprise Architecture to provide them with the necessary insight.

Knowledge as an asset.

I have heard it often suggested when discussing the value of knowledge that being regarded as intangible it is not quantifiable and consequently it is not counted as a real asset.

I would contend that the difficulty in measurement is only a consequence of a lack of desire to do so. Because it may be hard to measure does not make the effort to do so unnecessary nor the rewards of having done so trivial.

Individuals, Intellectual Capital and corporate assets.

I acknowledge that the value of Knowledge is extremely difficult to quantify. I rarely see any attempt to recognise that Knowledge has any value at all. Key individuals who, if they were to depart, taking with them significant Intellectual Capital, would severely damage the ability of a company to operate are assets that should be preserved. It is too late to realise the value to the knowledge asset after the fact.

I would also suggest that the business which actively engages in assigning value to the knowledge they hold and consequently having improved understanding are significantly better placed to take advantage of business opportunities when they arise, understanding their capabilities as well as their potentialities.

Dangerous Knowledge

Albert Einstein famously said that “a little knowledge is a dangerous thing. So is a lot”.

However it is neither having a little nor too much knowledge that is dangerous but in believing that there is no more to know.

Where knowledge is captured within a business it is important to appreciate context, quality and scope. Realising that there is always more to know ensures that assumptions can be better identified for what they actually are and the confidence in any risk mitigation strategies developed to support the business are more appropriate.

It is knowledge without wisdom that is the truly dangerous thing.

Dynamic Knowledge

Knowledge is rarely if ever an absolute and should be continuously tested against the current reality. New information received can and does alter the perception of what has been held as truth. A person residing in the Middle Ages had no issue with ‘knowing’ that the world was flat. Newtonian physics was regarded as being absolute fact until situations were encountered that did not ‘fit’.

As well as new information having an impact on the validity of what is known so does the framework within which it is applied. We know for instance that 1+1=2. This is certainly the case generally but not when working in a binary framework where 2 does not exist in this framework. We now need to know that 1+1=10.

There are also cultural differences that can affect how knowledge can be applied. In any homogeneous environment knowledge of body language cues relating to such things as ‘eye contact’, ‘gestures’, ‘personal space’, ‘hand shakes’ can be readily learned. Communication however, if this knowledge is applied in a different cultural environment, can be significantly and adversely disrupted.

Knowledge acquired should not be regarded as sacrosanct. It is always subject to change depending on the facts available. It is also open to interpretation depending on the framework in which it resides.

Knowledge is dynamic, responding to the world.

To know does not mean to understand.

Having all of the available facts does not automatically mean that you understand all.

Facts by themselves can and frequently are interpreted in multiple ways dependent on the world view or paradigm that the perceiver works within. Demonstrable in the situation where two individuals, each presented with the same facts, can and do arrive at either different conclusions or make different and possible contradictory decisions.

The provision of an Enterprise Architecture within a business context is an attempt to qualify the facts collected by exposing how they are inter-related. By having a tool that can potentially support predictions on the outcomes of the decision making process the different interpretations of the ‘original facts’ becomes less of an issue.

An Enterprise Architecture can assist in the conversion of knowledge into wisdom with the business gaining significant benefit as a consequence.

All knowledge is not equal.

When exploring the possibility of building a repository of business knowledge it is worth understanding that knowledge presents itself in many different forms and should consequently have different treatments and perhaps different values associated to it.

It is generally understood that knowledge can be categorised as either being:

Tacit Knowledge: this is knowledge that is embedded within individuals and is based on their own experiences and involves such intangible factors as their personal beliefs, perspective s and values.

Tacit knowledge forms that invisible, influential part of organisational knowledge, subtly driving the organisational culture, relationships and capabilities.

Tacit knowledge is often difficult to articulate and consequently hard to communicate and store, it consists of non-codified content. Being resident exclusively in the human mind, it can be communicated through face-to-face contact and the telling of stories. Sharing of tacit knowledge which is “owned” by the individual is realistically the only way that this can be preserved within a business. Losing a ‘sole owner’ of tacit knowledge can be disastrous.

Explicit knowledge: is knowledge that can be fully articulated and consequently captured and transmitted. Being easier to articulate, communicate and store, explicit knowledge can be codified and stored in artefacts such as documents (paper or digital) or databases. Explicit knowledge can be “owned” solely by the organization and is not dependent on the individual.

Tacit and Explicit Knowledge are however fairly course grained categories. To be able to best assign some value to either we should also look further. At the highest level Knowledge has an additional classification in that it can regarded as being

a priori knowledge which is gained without needing to observe the world and
a posteriori or empirical knowledge which is only obtained after observing the world or interacting with it in some way.

Other means of categorising knowledge encompass:

Personal Knowledge: is knowledge of acquaintance and is gained through experience. This knowledge can be affected by personal belief systems. Belief systems are a powerful influencer of personal knowledge. A person, believing something to be true, with neither personal experience nor evidence to support it may presume this to be knowledge and communicate it as such.
Procedural Knowledge: describes how something can be done. People who claim to know how to operate a computer, or model the business using software tools, are not simply claiming that they understand the theory involved in these activities but are claiming to possess the skills required to do them. Knowledge of this type could be said to be “know how knowledge”
Propositional Knowledge: or descriptive knowledge is the knowledge of facts. These will be supported by ‘scientific’ or observable evidence. By its very nature knowledge of this type can be expressed in declarative sentences or indicative propositions.
Inferential knowledge: is based on reasoning. It is established though taking facts and/or theories and inferring something new. This knowledge may not be verifiable through either observation or testing but can be a powerful tool asset in supporting the decision making process.

Understanding the source of knowledge and how it has been established provides significant value to its user. Being able to adequately deal with personal and corporate beliefs is important. It is possible to believe yet not know or know yet not believe.

Harvesting Intellectual Capital.

Intellectual Capital within a business is an asset that should be enhanced whenever possible. Frequently, when undertaking activities that lead to increased capability, improved business processes or perhaps more efficient operations and where external resources are utilised, the opportunity of harvesting new knowledge is overlooked.

Having an established knowledge repository from which internal resources can draw will provide a valuable supplement to what they already know. With a knowledge repository being fed with additional information the reliance on external resources can become less critical. Where external resources are engaged to fill an identified knowledge and skills gap, processes should be enacted that harvest as much of the missing knowledge as is possible for future reference.

Hand in hand, with the increase in Intellectual Capital within the business, so does its maturity increase. With more knowledge ‘in-house’ and accessible, better decisions can be made and the business can become more self-reliant and less at the ‘mercy’ of external vendors.

So often it is the external resource who walks away from a business with increased knowledge of how the business operates, making them more marketable back to the business itself or to its competitors.

By harvesting Intellectual Capital and applying it where and when appropriate a business will, over time, reap significant business benefit.

2 Enterprise Architecture

Documentation

Many businesses expend significant and increasing rare funds in creating documents supporting the design, development and implementation of initiatives that are expected to provide them with real benefit. How many of these same businesses are able to describe the both the impact and the dependencies a single initiative will have on other initiatives that are in train or in fact have been delivered.

The downside of many documents produced is that they tend to be static (point in time) rather than living and dynamic. The end game in document production is often to have it printed and then ‘signed-off’. Once in the ‘signed-off’ state the document, referred to by some as shelf-ware may only rarely be referred to again.

Businesses need to actively examine the on-going relevance of documents produced. Initiatives should be supported by an active repository that holds all relevant and up-to-date information that can be readily queried. Documents can be, with some effort, made dynamic with content being sourced/linked to the repository.

Even the most simple of businesses would be perceived as having many fundamentally different yet inter-dependent components. Consequently it is only reasonable to expect that so should be their supporting architectures

All businesses are multi-faceted in nature with individuals generally being interested in particular, rather than all facets, at any one point in time. It is however not enough to consider the enabling technologies for a part of the business in isolation but to also examine the people, their motivations, external influencers (amongst other things) and their interrelationships when establishing a supporting architecture. Similarly it is also not sufficient to just explore the business drivers and process with looking at what the technology can delivery.

By recognising this a more complete picture of the business can be built from significant and varied knowledge bases providing increased overall value that caters for multiple needs.

Holistic Architecture: A new term replacing current confusion

Within a business it is crucial that all participants operate from a shared understanding. Consistent misuse of the terms ‘IT Architecture’ and ‘Enterprise Architecture’ as synonyms limits the scope of Enterprise Architecture reducing its value to the business. As the misuse is so widespread I suggest we adopt the unambiguous term ‘Holistic Architecture’ which brings with it no baggage.

The issue of communication is one reason why a new term should be introduced. Thomas Kuhn (Structure of Scientific Revolutions), in 1962, introduced a. concept of incommensurability. With regards to this situation the problem is the preconception that individual users have of the term Enterprise Architect. Unless they have the same definition then any communication between them will result in a mismatch of expectations. Having lost the initiative in the use of the term Enterprise Architect we should now educate others in the use of a new term rather than attempt the ultimately futile act of re-education.

Avoiding the use of the term Enterprise Architect and introducing something like “Business/IT Strategy Architect” in order to dispel misunderstanding confirms my view that an Holistic Architect is a better choice. Stringing together a number of descriptors before the word Architect tends to be a clumsy attempt to solve the problem. Architect by itself is not sufficient as it is recognised that there are many aspects of architecture which can be explored and in which some individuals may have deep skills. The use of a composite descriptor such as “‘Business/IT Strategy” also seems to reinforce the concept that an architecture is segmented. I would contend that whilst there are multiple facets to an architecture it should be regarded as an integrated whole.

Repository of lessons learned

Maintaining a repository of lessons learned is a valuable tool when assessing the viability or advisability of a newly identified business initiative. Consequently being able to make an informed decision to proceed will provide a higher level of confidence that the outcomes and benefits identified as a result of implementing the initiative will be realised. With historic data available the ability to assess risk and put in place appropriate mitigation strategies can only improve.

This repository must be actively built and maintained with relevant information. A business should develop processes that not only determine the type of information they wish to capture, including key criteria they wish to use in reaching decisions and also ensure that these processes are correctly executed.

With good knowledge of what has occurred in the past the ability to extrapolate and forecast future outcomes can only improve to the betterment of the business.

Putting Business Architecture in perspective.

Business Architecture is neither the after-thought nor the financial overhead that many within an organisation regard it as being. Whereas it is widely accepted that the development of an Enterprise Architecture enables the efficient deployment of Information Technology the development of a Business Architecture appears to be more of a mystery as to what its true benefit may be.

A Business Architecture provides support for how the vision of a business can be navigated from strategy through to execution, incorporating or perhaps integrating with the Enterprise Architecture with its predominantly IT focus. A Business Architecture can assist with the identification, the prioritisation and the development and/or maturing of capabilities and supporting processes required to realise the Business Strategy.

Without a Business Architecture the opportunity to drive a business efficiently and using scarce resources wisely is greatly diminished.

Not only is the Business Architecture not an overhead but is an essential tool in allowing a business to prosper.

Adopting an Enterprise Architecture hybrid

Most businesses engage in the creation of architectural artefacts as part of their Business As Usual process as it applies to the design and execution of strategic initiatives.

Many of these businesses will not have a supporting Enterprise Architecture Framework in place yet appreciate the value that one may bring.

Oddly enough, a significant obstacle in establishing an Enterprise Architecture is the wealth of already created material. In exploring the Architectural Frameworks such as FEAF or TOGAF the question generally arises on what happens to the architectural components that have already been developed. These have generally been socialised and accepted by the business and the prospect of ‘tossing’ them out can result in significant push-back.

One solution is the establishment of a Hybrid Architecture Framework. In this case, by aligning architectural components already developed with those supported by other frameworks, it is reasonable to expect that appropriate coverage of the architectural landscape could be made. By choosing components that maximise the reuse of an already created body of work, avoiding rework and also resonate strongly within the business and IT the perceived obstacles can be largely overcome.

Instead of maintaining a purist view to building an Enterprise Architecture, by ‘picking the eyes’ out of what is already developed and what make sense from other frameworks, the business can realise an asset to which it may otherwise have been denied.

It is much better to have an Enterprise Architecture, no matter its form, than none at all.

Missing the mark!

Having decided to engage in the development of an Enterprise Architecture within a business it is extremely important to adopt an approach to capturing and recording information that supports the decision making process.

Without an approach or methodology directing the building of the architecture it is extremely easy to expend much effort and expense building ‘beautiful models’ that contribute little to realising the overall business strategy. With the plethora of models available to be built in the many different Architectural Frameworks it is often the easier or better understood that are undertaken first rather than the most urgent.

However, with forethought and by first gaining some understanding of where the business may have issues, a series of questions that need answering should be developed. These questions, whatever they may turn out to be, can assist in focusing the architectural development in those areas that would ultimately lead, with analysis, to providing valuable answers.

By targeting the development of the architecture to support the solving of problems that the business might have, earlier rather than later, the architect can develop a life of its own and become a valuable asset. With the subsequent maturing of the architecture through asking additional questions the decision making processes becomes more reliable and wide ranging.

Without selecting an appropriate focus the architecture will more than likely miss the mark and become the ‘white elephant’ that provides no ongoing business benefit.

Enterprise Architecture and the Brownfield business.

When establishing an Enterprise Architecture within a business it is extremely rare that that the business would be regarded as being truly ‘Greenfield’. In a ‘Greenfield’ business there is no existing architectural collateral that need be considered as influencing the shape of the Enterprise Architecture. The integrity of the Enterprise Architecture Framework to be adopted, assuming that there is a preference for an ‘off-the shelf’ framework such as TOGAF, FEAF, PEAF or their variants, need not be compromised.

It is more often the case, however, that the ‘Brownfield’ business recognises that it is in need of an Enterprise Architecture in order to better manage, prioritise and shape its business initiatives so as to better serve its customers and realise its mission and strategic intent.

The Brownfield business, like the Greenfield, still needs to capture information relating to

vision,
mission,
strategy,
objectives,
goals,
requirements and
external Influences

It also needs to factor in already developed

principles,
policies and
existing architectural collateral (Business, Information, Application, Technology) that is likely to have been developed in a siloed approach.

When establishing an Enterprise Architecture Framework the ‘Brownfield’ business inevitably needs to take a pragmatic rather than a purist approach. Instead of being able to adopt a single ‘flavour’ of framework a hybrid is more than likely to be adopted. Being able to leverage and re-use existing collateral can kick start the entire process whilst reducing the requirement of costly re-work. It is worthwhile to resist the temptation to start from scratch.

Enterprise Architecture – why have one?

An Enterprise Architecture is an integrated, living and ever evolving business artefact that is both informed and informs other parts of the business. It takes a holistic view of both ‘business’ and ‘IT’ with business being the driver and IT an enabler. As each facet of a well-constructed Enterprise Architecture will have documented inter-dependencies it is unlikely that change in one place will not elicit change in another.

Having and maintaining an Enterprise Architecture within a business must provide some on-going value or what is the point. Understanding and acknowledging the value is paramount to its success.

Underpinning five key questions, spanning vision to execution:

Why are we doing this?
What do we need to do?
What are we able to do?
What is the impact of change?
How do we do it?

an Enterprise Architecture provides a dynamic end-to-end view of the business, its capabilities and how it operates.

As a tool it supports, amongst many other things:

the optimisation of return on business and IT investments by more closely aligning them with business needs,
identification of priority areas for consolidating and reducing costs,
identification and quantification of change impacts to support the delivery of strategic change initiatives.

As a tool, an Enterprise Architecture can provide visibility of aspects of the business that might otherwise remain obscure.

Using an Enterprise Architecture can provide a business with a means to make better decisions** relating to its future allowing it to grow and prosper.

Not having an Enterprise Architecture does not guarantee failure but does introduce an element of ‘Russian Roulette’ into any business decisions.

Creating Order out of Chaos!!

All businesses capture and store information, in some form, about:

What they are doing
How they are doing it and
Why

This information may be structured but often is not. Information abounds that relates specifically to individual projects or activities that have been undertaken but not on how they related to or are dependent on others. Without structure even this information may be internally disjoint.

Where there is a lack of capability to establish, analyse and consequently understand these relationships, the decision making capability of the business will be significantly compromised resulting in:

Guessing rather than knowing
Being oblivious rather than aware
Engaging in inactivity rather activity
Engaging in inappropriate activity rather than appropriate.
Spending recklessly **rather than **wisely.
Failing rather than succeeding (in the worst case)

Establishing a structure where relevant information can be placed provides the capability of:

Having an end-to-end business view of how the business operates.
Identifying what is really important.
Determining the real impact of change.
Making informed decisions.
Prioritising how and when (or if) money should be spent.

In establishing an Enterprise Architecture Framework the capability of being able to categorise, allocate and analyse information is greatly enhanced.

Governing content and measuring performance provides the opportunity of making properly informed decisions.

Creating order out of chaos: perhaps not, but the business will be better placed to succeed.

Five Cs of Enterprise Architecture

A complete Enterprise Architecture that effectively supports the business cannot be purchased as a fully realisable off-the-shelf commodity. This statement should of course be qualified by at least considering the possibility of acquiring a hypothetical ‘business-in-a-box’ with everything already defined and requiring the business to change to fit.

To be useful for the majority of businesses the Enterprise Architecture must be crafted with particular care.

As it takes time to craft well it is not reasonable to expect the business to wait until the Enterprise Architecture is fully formed. If it is to gain credibility and maintain momentum, should be used as it is being built.

To ensure that the Enterprise Architecture is indeed usable there are five key areas that should be considered:

CONTENT: What should be included within the Enterprise Architecture and in what order should it be captured.
COVERAGE: How much of the business should be initially covered to provide real, shorter term, value to the user of the Enterprise Architecture. Initial content captured should provide and end-to-end slice through the business.
CONSISTENCY: Ensure standards for capturing, recording and reporting on information have been defined and are consistently applied. Information captured must also not be ambiguous or open to misinterpretation.
CONTROL: Provide mechanisms by which information which has been captured, to be included within the Enterprise Architecture, is accurate and has been validated. On-going governance is key to the success of an Enterprise Architecture and consequently to the business.
CURRENCY: It is crucial that content held within the Enterprise Architecture be maintained. The consumer of content must have confidence that what they see is current and has not been superseded. Unless currency is maintained the Enterprise Architecture, instead of being of value, can become a liability.

It is imperative that the Enterprise Architecture be constructed and populated with a view to support the business.

By choosing what will be be included first and then maturing the content iteratively, the business will reap maximum value earlier. With a realised value identified and quantified earlier, the Enterprise Architecture has a very real chance of providing significant and long term business benefit.

The Business does not stop with Information Technology

When establishing a business architecture all of its components must be taken into consideration. Whilst it may be tempting to ignore technology as being out of scope (by saying it will be covered within a Technical Architecture) it is absolutely essential that it be included, if only at a high level. To ignore the contribution (existing and potential) and the impact that technology has within the business will compromise the decision making process and potentially lead to lost opportunities.

As an enabler, technology provides a platform upon which many of the business’ Capabilities, Functions and Processes are executed.

Without understanding of what the technology can offer many aspects of the business could fail to materialise or could perform so poorly as to be a liability rather than an asset.

With understanding, the opportunity to increase business benefit, through perhaps increased or improved process automation, is enhanced.

When assessing the capability to deliver against its Strategies, Goals and Objectives business, awareness of what technology does and can provide, gives needed information when deciding and prioritising what is required to increase business maturity.

The business does not stop at IT but encompasses everything needed to deliver a successful outcome. IT is part of the business.

Enterprise Architecture and Agile development are not mutually exclusive.

Business driven Agile development is achieved by

Breaking tasks into small increments;
Applying only the minimum of planning.
Iterating over short time frames (timeboxes).
Involving a cross functional team working in all Software Development LifeCycle functions.

At the conclusion of an iteration a working product is demonstrated to stakeholders with the goal of minimising overall risk and allowing the development project to readily adapt to change. In defining each iteration it is essential within an Agile methodology that

The current state of the solution landscape is reviewed.
The desired state from the business is elicited.
The technical and non-technical gaps between the current and target states be determined.
A definition (Story Card) of the steps necessary to narrow the gaps is created.
A review the implementation results is undertaken so as to choose the next step and revise where appropriate the approach towards the target state

Each of above, whilst in an Agile development is focussed on the micro, is also fundamental to a successful Enterprise Architecture on a macro scale. An Agile methodology can also be applied to the development of the Enterprise Architecture which subsequently becomes an information source for each Agile development activity.

Establish a light Enterprise Architecture at the highest level of the business providing. Business and IT strategy, a high-level roadmap, a light touch architecture framework, principles, guidelines and a governance approach.
Identify the slice of the enterprise where the business is about to embark upon multiple moderately sized initiatives.
Define a minimum set of end-to-end architectural artefacts such as processes, data models, service models etc. needed to support these initiatives and begin populating a repository with enterprise content, governing artefacts, and start documenting guidelines and best practices.
Assess the results, adjusting the previously defined governance approach, re-align the business and IT strategies where appropriate and mature the architecture framework.
Select another slice of the business and repeat from steps 2.

Agile development and Enterprise Architecture can work hand in hand, providing valuable support to one another.

Shaping business operations.

An Enterprise Architecture gives its user the opportunity of exploring the business from end-to-end. Instead of only having a ‘blinkered’ or ‘narrow’ view of only isolated parts of the business the user is able to gain a holistic perspective.

The ‘big picture’ view supports the ability to drive efficient and effective business behaviour.

Systems or processes that are fragmented across the business can, with an Enterprise Architecture, be better managed. Whilst they remain fragmented the business is subject to duplication, waste and lost opportunities.

Understanding what is ‘out there’ and how it is used and the impact of its use on the business provides the impetus to implement managed change.

The opportunity to take fragmented systems and with knowledge of the potential impacts explore the possibilities to

Categorise – creating better understanding of attributes and behaviour.
Aggregate – bringing together like capabilities, processes, functions, information and systems
Consolidate – simplifying by eliminating redundant environments.

Ultimately, the use of an Enterprise Architecture can lead to a rationalised business operations environment that is better placed to compete in the market place.

Guiding Principles.

An Enterprise Architecture, supporting a business, is an extremely valuable asset. It is however very easy, when populating it with knowledge garnered from the business, to use it as a dumping ground for everything: ‘just in case it becomes useful’.

Potential content, before being incorporated within the Enterprise Architecture repository, should be subject to a number of tests to determine its ‘fitness for purpose’

Establishing a set of Guiding Principles and ensuring that they are adhered to, provides a mechanism through which the Enterprise Architecture can retain its on-going value.

Content to be included should be:

Strategic: Align the architecture with decisions that need to be made and the strategic vision of the business
Standards Based: Reducing needless diversity
Simple: Making things as simple as possible but no simpler. Following well defined patterns and blueprints to define the content will increase understanding and decrease complexity.
Knowledge Driven: Manage content as a single source of truth for others. Base the content on facts, not supposition or assumptions.
Reliable: Ensure the validity of ‘facts’ and avoid inconsistencies.
Accessible: Content needs to be available to those who need it.
Secure: Ensure confidentiality, integrity and currency of information.
Sustainable: Content to be included must be maintainable, manageable and measurable.

The application of Guiding Principles, as a test for content inclusion and a governance regime providing assurance that they are being followed, will ensure that the Enterprise Architecture will provide a tool to the business that is worthy of its investment.

Decision making with finesse

So often, problems are ‘solved’ within a business by using the ‘bull-dozer’ approach of throwing money at them or cutting resources.

If there is a problem with performance get a bigger box.

Costs are too high, let’s get rid of people.

I frequently hear the phrase ‘Work smarter, not harder’ but whilst seeing this applied by rare individuals I hardly ever see it applied at a corporate level.

An Enterprise that has a culture of ‘Working smarter’ will apply finesse to a problem not brute force. It will analyse root causes to a problem to find out ‘Why’ then leverage corporate knowledge and wisdom to determine ‘What’ and ‘How’.

A well-considered response to a problem will always be preferable to the gut reaction.

Risks, information and decision making

Without having visibility of the whole enterprise and the inter-relationships between its various components how can the true risks associated with a business initiative be reliably determined. With risk not fully identified how can you establish the cost of mitigation?

It is essential if risk is to be assessed that the business is provided with both necessary and sufficient information from which to work. Without access to this the decision making process will be subject to higher levels of uncertainty than is essential.

‘Quick Wins’ and lost opportunities

It is often the case that a business will pursue the ‘quick win’ when presented with a number of initiatives. That they do so seems on the surface to be logical as there is a fair chance that they will get an early return on investment thus seemingly validating the expenditure of increasing scarce funds.

Relegating other initiatives to the ‘back-burner ‘, to be looked at a later stage, may just however been closing the door on opportunities that far out-perform, in the longer term, than the ‘quick win’.

It can be all too easy to be essentially blinkered and not looking at the bigger picture or for the longer term to avoid making the ‘harder’ but wiser decisions. By setting the decision horizon or ‘pay back’ period to a point in the too near future the opportunity to reap real and significant benefit may be delayed unnecessarily or totally missed.

Satisfying wants and needs

The trouble with determining not only what the business wants but what it actually needs in order to deliver on its business strategy, if one exists, is an obstacle that absolutely must be overcome. All too often a business has vague idea on what it wants or needs to do. It may or may not have a good understanding of the business drivers but frequently little understanding how to best arrive at a solution.

Being able to clearly elucidate the scope of the problem to be solved and to define a set of requirements that would need to be satisfied to guarantee that a solution had been delivered is both necessary and essential.

Without a clear problem statement and associated requirements the opportunity to be delivered a solution that does not satisfy the need escalates dramatically. Without appropriate directions being defined the probability of frequent change being requested during the course of building a solution increases.

Applying rigour at the point where the problem is being defined and maintaining proper processes throughout the solution definition will result in better business outcomes and less frustration for both the business itself and the problem solvers.

Decision making and self interest

The relationship between the making of rapid, short term and often ill-conceived decisions and that of receiving financial incentives (bonuses or commissions) should be explored.

How often is a decision to proceed with a purchase or the execution of an initiative made with the expectation of the decision maker of receiving some personal and immediate financial benefit? Decisions made with an eye on the personal, even if unconsciously done so, rather than for the corporate long term benefit, are inherently flawed.

Sales commission based on the usual Sales Value rather than the rarer Delivered Margin encourages over-selling and under-delivery.

Decisions to deliver a project on time and (apparently) on budget at the expense of quality, governance and testing might provide kudos and perhaps a bonus for the Project Manager but will possibly cause significant ongoing issues when the project has wound up (having been delivered) and it has entered a Business As Usual phase.

All decisions should be made with an understanding of their longer term impact. Perhaps as well as offering incentives there should be the opportunity to offer disincentives as well.

Supporting agility in decision making

It would be naive to expect that when running a business that decisions would not need to be made. Situations are constantly arising that will require a response. To be able to reliably respond, appropriately and with some degree of agility, can determine whether a business will ultimately succeed or fail.

Examples of situations that need responses are:

Changes in Government regulations which require compliance.
New service offerings by competitors, potentially ‘stealing’ market share.
Changes in business strategic focus.
Innovation, introducing new business opportunities.
Failure of process or systems to deliver required results.

The decision making process needs to be as agile as possible so that an appropriate response can be adopted both rapidly and executed efficiently.

Too often, however, the decision making process takes too long to be effective or, though lack of good information, is poorly formulated.

The business, with a well-structured, content rich and properly maintained Enterprise Architecture, has an asset that supports decision making with many touch points into the process.

The Enterprise Architecture, providing an end-to-end repository of knowledge about the business, can provide a single access point from which information relevant to the situation can be drawn.

The Enterprise Architecture can additionally support the analysis and development of decision options and assist in the assessment of the business and/or technical impact of each. With a good understanding of impacts a decision can be reached and appropriate activities developed through which the decision can be executed.

Lastly the Enterprise Architecture repository can provide a framework which could capture the quantitative outcomes of decision made thus feeding and maturing future decision making activities.

Without having access to an active Enterprise Architecture the decision making process, whilst going through the same steps, can take significantly longer. Also being affected by poor access to information and consequently to a diminished ability to carry out a timely impact analyse the quality of decisions may be compromised.

It is often said: “Knowledge is Power”

An Enterprise Architecture is a repository of business knowledge. With it the power to make ‘good’, rapid business decision is greatly enhanced.

Having agility in the decision making process and making consistently good decisions must be good for the business.

Managing the impact of risk on business decisions.

Risk that is not understood can present as much or more danger to a business than one which has not been foreseen.

All decisions will have some element of risk associated with them and how the risk is to be ultimately managed can shape the actual decision itself.

Risk can be effectively managed ONLY if it is understood.

Understanding can only be realised with sufficient information available to provide appropriate context to the risk in relation to the decision to be made and the potential impact it will have on the business.

An Enterprise Architecture, whilst not pretending to be omniscient, can provide the necessary information to assess the risk and for the decision maker to garner enough understanding of both its impact and likelihood of occurring to formulate an appropriate decision and possible mitigation.

The information held within the Enterprise Architecture repository may not be complete when tasked to assist in supporting any given decision but will be better than not having any at all.

The outcomes of decisions, made as a consequence of the understanding reached about specific risks, should be fed back into the Enterprise Architecture improving future risk assessment.

With even better information new risks can be better understood with the business benefiting from better decisions and less unintended consequences.

Business success – It’s all about choices

No business is an automaton whereby, once started, it will continue to operate unsupervised. It will always be the case that situations, either internal or external, will arise or can be anticipated that will require the human element to provide appropriate and timely responses. Any response, if it is to be in the best interests of the business, will always involve the making of a reasoned choice.

Will I or won’t I do something?
What are the options open to me?
Why would I choose one option over another?
What order should I do these in?

In making a choice between competing options it is essential that sufficient information be available. With insufficient information the choice made may not be optimal. Equally important is having sufficient information so that an identification of appropriate options can be made.

An Enterprise Architecture is a repository of information that can be used to both identify options and then support the choice of selecting between them. With the gathering of suitable measures on how the business operates an analysis of the impact of adopting one option over another can be made.

The ability to provide a quantitative assessment of the merits of one choice over another, whilst also being able to explore the effect of its selection across the business, increases the confidence that the ‘right’ choice will be made.

Running a business is all about choices. Having and maintaining an Enterprise Architecture maximises the chances that the choices made will be in the best interests of the business.

Choosing appropriate solutions to address problem situations.

There will always more than one way to solve any given problem. How effective any given solution will be will depend on what information was used in the solution’s definition. An Enterprise Architecture can provide a repository of useful information necessary to the successful formulation of a problem’s solution.

By itself this is not enough. A business situation will always require some response even if only choosing to do nothing. Those charged with its resolving the situation will undoubtedly identify a number of options from which to choose.

How they go about identifying and subsequently making their choice will shape the eventual impact of the option selected. The Enterprise Architecture, whilst holding valuable information, must be supported by processes assisting its user to find and use the information that they require. The is nothing more frustrating than knowing that information exists but not being able to locate it.

Without supporting processes the user of the Enterprise Architecture may just as well be reaching into a ‘lucky dip’ and see what comes out.

The information returned by a ‘hit and miss’ approach may be accurate, assuming the Enterprise Architecture content is properly governed, but will it be relevant and appropriate.

Processes supporting an Enterprise Architecture can assist in assessing the validity of using the returned information to the situation at hand.

The information held within the Enterprise Architecture repository is not enough, by itself, to provide significant value to the business. It must be supported by processes assisting the user to leverage the information to solve real problems in the most optimal fashion.

3 Business Performance

Quality information and analytics

A business leader in order to make decisions that have real worth must be well informed. Consequently presenting a view of a changing and ever evolving business to the business that is clear, unambiguous, concise and timely is a real challenge that must be met.

This must be supported by the capability to rapidly analyse significant quantities of information, establishing intra and inter-relationships between seemingly unrelated data and applying collective wisdom so as not having to rely too much on the crystal ball.

Motivations and Measures

Identifying key business motivations and measures are two requisites to building a successful Holistic Architecture.

Knowing why you are designing the component you are and what will be the consequence of doing so provides clarity to the architecture development process. The measures in particular give you the opportunity to determine the effect of your design on other architectural components.

Unfortunately uncertainty seems to be a fact of life when establishing any architecture. The risks associated with this uncertainty however can mitigated to some extent when there is some understanding and application of the business measures and motivators. ‘Why’ and ‘what is the impact’ are crucial questions in the decision making process.

Qualifying assumptions

Whilst acknowledging that capturing ‘all’ information relevant to making a decision about implementing a business initiative is not possible there is a real issue that needs to be addressed with how assumptions are managed.

Often an assumption is accepted as being a fact. Its unqualified acceptance can result in significant and unmitigated risk to the initiative’s eventual success.

The scenario, for a hypothetical initiative, is that an assumption is made that, if executed, will result in a business increasing its customer base by 50%. In building a business case this increase is expected to translate, based on known customer behaviour, to an increased peak transaction load on whatever system is developed to host the initiative of say 10,000 transactions per hour.

With the assumption accepted, as is the transaction rate, with other perhaps known information and other assumptions some benefit of the initiative to the business could be established thus providing an indication of its feasibility.

To make a good decision however the assumption initially made should have been qualified.

By supporting the assumption with statements such as ‘based on market research it is expected that the customer base will increase by 30% plus or minus 20% with a confidence level of 30%’ can have a profound effect on decisions eventually made. The assumption, now qualified has a best case of achieving a 50% customer base increase but has a worst case of 10%. The business case benefit, driving the decision, without having further quality information, must now be suspect.

The lesson here must be that before making a decision based on assumptions ensure that they are qualified.

Balancing decisions against risks, costs, benefits and business goals.

At some point in establishing the business case to support a business initiative a decision needs to be made either to proceed or to not proceed. In building the business case information will have been gathered and collective knowledge will have been applied to determine it adequacy.

Risks will have been identified and presumably the cost of mitigation coupled with both their impact and the likelihood of their occurring will have been established.

A decision can be reached by balancing the benefits of the initiative against the cost of implementation, the impact on the business if it is not and the importance of its contribution into the realisation of Business Goals and Strategy. This decision needs to be also made with an appreciation of other competing initiatives in the pipeline.

Managing Risk

Managing risk is absolutely essential if you wish to optimise the benefit of a business initiative. That there will be risks is unavoidable. Identified risks can be managed through either avoidance or mitigation.

With risk avoidance, activities are undertaken in order so the situation that would trigger the risk can never happen. Mitigation however assumes the risk will be realised but plans or subsequent actions put in place that will lessen its impact.

To optimally manage identified risks it is also necessary that two of their attributes are understood.

Likelihood of a risk being realised: This can be expressed in terms of a level of confidence.
Impact if realised: This may be the dollar cost to the business.

Both of these attributes may consist of a range of values with the risk perhaps being expressed as having a range of possibilities.

In both the case of risk avoidance and risk mitigation there will be a cost associated with its achievement. These costs must also be identified.

With a good understand of the likelihood of a risk being realised, the impact on the business together with the cost of dealing with it, the feasibility of a executing a business initiative can be better assessed.

Performance metrics – supporting Service Delivery?

Performance metrics are often established as a mechanism to establish the effectiveness of a business and the delivery of its services. Who, however are the metrics designed to assist.

Over the last three months I have been an active user of mixed-mode public transport in order to attend my distant workplace. The daily commute is long and encompasses the use of buses, metropolitan and regional train services. Over a period of time I have been able to garner first hand a strong impression of the level of performance delivered.

The public transport authority responsible for regulation of each service publishes a set of performance metrics which, if they are met, result in an incentive payment made to each operator. A penalty is imposed on failure to deliver.

The main metric used relates to what is called ‘on-time’ performance. This describes the parameters within which a Service is regarded as ‘on time’

77% of Metropolitan trains must arrive at its final destination no more than 59 seconds early or 4 minutes 59 seconds late.
92% of Regional, short haul trains must arrive no more than 5 minutes 59 seconds late.
Buses must arrive at their final destination no more than 2 minutes early or 5 minutes late and with no timetable service operating early at any point of their route and 90% of services running on time.

Whilst each of these are well defined metrics providing each operator with a statistical target to achieve in order to receive an incentive what do that actually mean to the paying customer.

Experience has shown me that in the three months of travel that the bus and metropolitan trains generally meet their ‘on-time targets’ although the frustration experienced in seeing a bus running 1 minute 45 seconds early when I am on the other side of the road is significant. It may have been ‘on-time’ but without me on it may as well have been 20 minutes late, being the wait for the next service.

I also have issues with a service which, on some lines where there is a frequency between trains of less than 5 minutes, at certain times of the day, allowing as acceptable the targets set. A ‘late’ train on such a service seems indistinguishable from a cancellation.

I am also yet to meet the member of the travelling public who actually finds it acceptable to have 23% of their metropolitan train services not run ‘on time’. The business impact of a public transport travelling workforce being late for work at least once per week is likely to be significant.

The Regional train I use is mixed in its service delivery. I have been able to rely on it delivering me to work on time in the morning reliably. Going home however I have yet to arrive at my destination ‘on time’. Consequently my experience of the Regional Service is no better than 50%. But of course from the operator’s perspective it is the statistical figure over the entire transport network that is important.

The performance metrics set seem designed to support the cash flow of the operators. Setting the thresholds low maximises operator’s profits.

The operator is likely engaged in applying a typical saddlepoint analysis strategy. Setting the threshold low enough that they can earn the maximum incentive from the regulator yet not so low that they will drive away their customer, the travelling public, thus optimising profit.

What, however was the original purpose of establishing these performance metrics?

Were they designed as an aspirational target through which service delivery to travellers could be improved or was it set purely for financial purposes?

In this instance I will maintain my cynicism.

Enterprise Architecture: Baselining Performance Metrics

Being able to demonstrate the benefit of undertaking Enterprise Architecture requires, like other business initiatives, the establishment of appropriate performance metrics. Being able to provide quantifiable validation that Enterprise Architecture activities actually contribute value to the business can enshrine its ongoing use.

In establishing performance metrics it is important that they have resonance with the business.

High level KPIs such as:

Identifying reuse opportunities
Identifying functional duplication
Reducing design rework

need to be expressed so that the business can on any particular initiative can quantify the actual benefit;

Initiative A Identified x reuse opportunities
Initiative B Identified x functions that have been duplicated resulting in a reduction of project scope
Project C reduced design and development rework by x%

Each of these could be quantified with both a financial and time to implementation benefit (saving $y and z man days of effort).

One obstacle to being able to quantify these benefits is however not having a benchmark in place from which the benefit can be measures against.

Being able to answer the questions ‘what is the value to the business of being able to reuse components already developed?’ and ‘what was the cost of developing the function that you avoiding duplicating?’ ‘what is the cost of rework?’ needs to be answerable.

Going ‘hand in hand’ with a developing Enterprise Architecture is a business that is baselined. Knowledge and understanding of where the business is, what costs it has incurred getting there and why becomes an important asset for realising future benefit.

The likelihood that this baseline knowledge exists is often low but with effort can be established whilst the Enterprise Architecture matures.

A measure of success.

The ability to be able to measure success within a business is fundamentally dependent on having already established the criteria against which the measure is being made.

In establishing a business case to support the development of a business initiative it is critical that the benefits expected to be realised after execution are fully defined. The quantification of these benefits provides the basis against which the success of the initiative can be assessed.

Similarly when maturing the capabilities within the business, in response to delivering against defined strategy, the only way of really knowing if progress is being made is through having a quantitative understanding of the capabilities before any change was invoked.

Establishing a measurement baseline, then continuously assessing how it alters as change is implemented, provides at least one dimension of measuring the success of a business initiative.

KPIs and the business

The establishment of Key Performance Indicators (KPI) within any business is absolutely essential. Aligned to strategy they provide the means by which the health of the business may be properly assessed.

KPIs should be set early to support the achievement of business goals and objectives. Once established at a high level they should be able to be decomposed so that business activity, no matter, how fine grained, can have its contribution traced to it source.

Having processes are in place that ensure that metrics are captured then measured against the planned or expected outcomes permits decision makers to determine if remedial action is required to compensate for any negative results.

The feedback provided by having reliable metrics enables the opportunity to engage in business process improvement or to refine business strategy and the consequent business goals and objectives to reflect reality.

Without the definition and on-going management of KPIs a business can have no real insight into how it is performing.

Without insight the business risks failure.

Assessing Process Value

Processes define how the business actually interacts with the world. Each process must have a valid purpose that assists with the delivery of the business strategy. Each process and its component parts will have an outcome that can be measured for its efficacy.

Central to understanding how the business operates and how to potentially improve that operation is gaining an appreciation of how processes interact with one another and how changes to their structure and flow can affect associated business outcomes.

Processes are rarely stand-alone, being triggered by some upstream event or outcome resulting from another process. Physically documenting how each process works: how it interacts with others and what information is flowing (from what and to where) assists in the gaining of an end-to-end view of what is happening within the business. By overlaying key measures such as

Cost of operation
Time taken to complete
Step and total value earned

the effects of change on business benefit can be better assessed.

Leveraging the Value Chain

Having defined processes within the business and having also established performance metrics deemed necessary to assess their respective health the building of Value Chains, providing a high level view of how aspects of the business operates, is essential.

A Value Chain provides the mechanism through which a sequence of relevant high profile activities or processes can be linked so that a targeted performance metric may be analysed.

Exploring a Source to Sell Value Chain for instance allows each step in the process from which raw materials are sourced through to their being changed into a product which will ultimately be sold to a targeted customer to be visualised simply.

Each step of the process has a cost associated with it as well as contributing to a change in the value (this could range from financial value to customer satisfaction), either positive, negative or no impact of the product to be sold.

Assessing the changes within the Value Chain provides the opportunity to identify parts of the process that are less than optimal and consequently adversely affect the end result. In identifying poor links in the chain remedial action can be taken to rectify potential problems.

It should however be noted that a Value Chain analysis should explore multiple performance metrics as there is likely to be some form of interdependence between them. The remediation of one link in the change for one metric may have adverse effects on either itself or another link for another metric.

The Value Chain provides a useful tool for both assessing the health of the business and the targeting of specific components that would benefit from Process Improvement or Re-engineering.

The case for Buy, Build, Augment or Reuse.

Many businesses, for better or worse, decide on a single policy such as ‘Buy before Build’ when looking at implementing new business capability. The rationale behind such a policy is sound in that the design and development work to implement supporting business functions is effectively outsourced to a third party provider. By purchasing a COTS (Common Off The Shelf) software package the business has delegated the support of the business functions away from themselves. The question should be asked: “Is this best for the business?”

A significant issue of a ‘Buy Before Build’ policy is that the purchased product is likely to exhibit the required functionality in a different manner to that which the business actually wanted. Unless the business is then prepared to go down the customisation path the _only _option open to them is to change the business to suit the product.

A secondary issue of this policy is that over time the business will accumulate duplicated functionality as purchased products have overlapping feature sets. This duplicated functionality may be used by different parts of the business necessitating variant processes to achieve the same or similar outcomes. Having worked for one company where it was widely regarded as being the ‘Noah’s Ark’ of the IT world (they had at least two of everything) the duplication did cause confusion.

Rather than adhering to a strict policy perhaps a guideline could be put in place that explores the different options available to the business:

Buy - Purchase a product when it closely satisfies the required functionality and there are no other options.
Build - Develop a system that delivers the required functionality when there is no product available to purchase or other systems available.
Augment - Modify an already existing system to provide the additional business functionality.
Reuse - Leverage business functionality that already exists within existing business systems.

By looking at the range of possible options and associating each with a set of costs and benefits a better decision can be reached on how new business capability can be implemented. This should be undertaken in association with an analysis of how each option would impact other existing systems.

Business Architecture and Benefits Realisation

In the ‘ideal world’ all business activity would be undertaken in a manner that moved the business closer to achieving its ‘vision’ in an efficient and most cost effective manner.

Unfortunately, living in the ‘real world’, the truth falls far short of the ideal.

The intent of Benefits Realisation within a business is about ensuring that ideas and consequently projects deliver the benefits, forecast and identified in a business case or project charter documents and are aligned to business strategy.

The steps in doing so should be straight-forward however the reality is that many projects fail to deliver the benefits. Worse still, many fail to even identify what the benefits are other than superficially. Common pitfalls such as expecting that technology will deliver the benefits whereas, whilst it may contribute, it is likely that it is the business change that will deliver the results.

Benefits don’t just happen. They need to be measured and managed.

Align to Strategy: Ideas and resultant projects should support Business Strategy. If there is no alignment why do them.
Identify Benefits: What benefits can realistically be expected.
Identify Measures: How will these benefits be manifest and how will they be measured
Conduct Baseline Measure: Need to have a baseline against which the measures can be compared.
Implement Change: Execute the change within the business that the project has defined.
Monitor: Capture measurement details.
Assess: Compare measures benefits with the expected.
Realign to Strategy: Feed results back into the strategy and refine as required.

A Business Architecture provides a structure which supports the Benefits Realisation process. It allows competing ideas and potential projects to be prioritised by identifying early on what business benefit is expected. By providing end-to-end visibility of the business it can assist in identifying key components of potential change and where measures should be made.

A Benefits Realisation Process is not difficult to implement providing the business has sufficient knowledge of how the business operates and the discipline to carry it out.

Business Goals must be defined and then measured.

All organisations should have formulated a set of goals and objectives, derived from their mission and vision statements and supporting their business strategy. The completeness of these goals and how they are managed can influence the of the organisation to be a success.

Having established goals provides real focus and ensures, with the assistance of governance and compliance processes, that all functions and elements within a business are moving in a common direction.

Without goals:

the business lacks specific direction
is without focus and
has everyone, in the worst case scenario, doing their own thing

As progress is made in realising business goals a regime of monitoring real performance is essential. With consistent monitoring

Progress against a plan can be reliably reported.
Accountability for either success or failure is improved.
Where issues or risks are identified the facilitation of corrective action or mitigation strategies is enhanced.
Feedback supports improved strategic planning and future goal setting.

With well-defined business goals defined a sense of real purpose will be apparent within the business. With tangible and achievable measures set individuals within the business can experience a true sense of achievement during the journey of achieving those goals.

Enterprise Architecture – A measure of success!

Having spent time and effort in populating an Enterprise Architecture its true value can now be realised in its use.

The Enterprise Architecture, being a tool that provides visibility of the business, providing ‘line of sight’ between strategy and execution, allows it user to gain insights that would otherwise be obscured.

With being able to ‘slice and dice’ the business, the capability to assess the impact of change and the carrying out a ‘what if analysis’ on areas of interest is greatly enhanced.

The key to determining impact is the identification and inclusion of Business Measures within the Enterprise Architecture and their ongoing monitoring as part of ‘Business as Usual’ activities. The measures, once established, will be influenced by many different parts of the business and need to be looked at holistically as a change in one area may have a consequential change elsewhere.

Business measures must also not be looked at in isolation.

For instance:

Increasing revenue by increasing prices may provide a short term gain but might be at the expense of customer satisfaction and market share
Increasing efficiency or productivity may come at the expense of employee satisfaction.
Driving down costs may come at the expense of revenue and customer satisfaction.
Revenue may have increased through no reason than population growth yet if market share has decreased is this a success.

Business success should be assessed by taking a multi-dimensional view of the business. Success will be measured through the contribution of multiple individual measures and the context in which they taken.

It is reasonable to assume that if a business manufactures more of a specific product for sale then both revenue and the cost of manufacture will increase. Success here can, simplistically, be assessed by looking at the interplay between these two measures.

If increased production equates to increased profit then does it matter that costs have increased?
Does increased sales equate to increased customer satisfaction and give some consequential additional benefit?

With Business Measures firmly entrenched within an Enterprise Architecture and processes in place that use them and are rigorously enforced, a business will be in an excellent position to shape its future and be ‘successful’.

4 Organisation

Behavioural Maturity

Establishing an effective Enterprise or Business Architecture within an organisation is in much need having achieved behavioural maturity as it is in achieving process maturity.

As, when progressing through the various CMMI maturity levels to achieve optimised business processes, there are parallel behavioural characteristics that must also be realised.

It is often said that a successful business is as much about the people as it is about the process. In essence without good disciplined people there is no business.

Corporate Maturity

For a business to fully realise its potential to deliver whatever may be its primary mission it must reach an overall level of maturity such that it operates as a single ‘organism’.

So often a business will recognise that work needs to be undertaken yet only matures some aspects of their operation, failing to complete and failing to reap the full benefits. Having an architecture function with its house in order is a good start. Architecture and IT are only part of the answer however, as the whole of business need also to be fully engaged and integrated.

Recognising the potential rewards to a business in driving actively towards maturity should be the incentive to either commence or continue the journey.

Accountability and responsibility

Responsibility to undertake decisions within any business usually devolves to multiple individuals. The scope and the magnitude of the decisions that they are empowered to make is largely dependent on the role they occupy.

Whilst responsibilities are generally easy to manage the same cannot be said with accountabilities. Generally for every decision that is made, ignoring at present those made by committees, a single individual must be accountable. Where the accountable individual is the same as the responsible individual it is quite obvious where credit or blame, if needed, should be directed as a consequence of a decision made and its resultant outcomes. Where accountability and responsibility are divided there is generally no such clarity.

Well defined processes supporting the potential decision outcomes must be in place within a business where accountability and responsibility can be separated. Without such, accountable individuals may not be prepared to delegate responsibility possibly crippling the business by taking on too much themselves. On the other hand the individual who does have delegated responsibility may fail to make decisions without having a clear understanding of the ramifications.

Communication, Comprehension, Co-operation, Collaboration

Good communication is at the heart of a successful business. Not so often, fortunately, communication takes the form of a monologue with one party telling what it is they think they want to have done. The resultant business outcome may not be what was either intended or expected and may often be detrimental to the business.

With true dialogue all parties are able to contribute and in gaining clarity can rapidly reach a state of comprehension and increased understanding of what is really required.

Communication with full comprehension is the means by which co-operation can be engendered within a business. Collaboration is that desired extension of co-operation where all parties mutually work together to achieve a common goal. With true enduring collaboration a business will reap significant benefits.

Left or Right Brained Architects

A person who is left-brained is often referred to as being more logical, analytical and objective than their right-brained counterpart who is regarded as being more intuitive, thoughtful and subjective.

A question could be asked regarding the attributes that are necessary to be a good Business or Enterprise Architect. Certainly being able to analyse the requirements of a business and applying logical processes in order to establish the need and priority of developing supporting initiatives is highly desirable.

But how then are these initiatives to be defined?

Being able to think outside of the box and with the ability to take that ‘leap of faith’ that an idea could work is often the prerequisite for the business initiative that is truly innovative.

Decisions to proceed may result more from the application of ‘gut feeling’ rather than logic. Risks may be greater but so may the rewards.

In reality the Business and Enterprise Architect will display aspects of both right and left brained behaviour. It is the balance and the amount of interaction between the two, managing the risks though logic that were raised through intuition, which will determine their success.

Sometimes the answer should be no.

Not all activity undertaken under the guise of developing architecture models provides value to the business. I would hate to count up the number of times I have been asked to undertake some task which would identify the interdependencies between components within the enterprise only to find that there was either no real relationship established or in having identified one to find that knowledge of the relationship provided no tangible benefit.

As you are with two people, with some effort, able to establish a linkage between them so you can with components within a business. The question is, having established that linkage, what was the point?

The desire to link everything to everything is predicated on wanting to know it all. The problem of course is that knowing it can obscure what is important. It sometimes seems that the more you know about everything the less you know about the specific: a real demonstration of ‘not being able to see the forest for the trees’.

Architectural work undertaken must be guided by the questions that are important for the business to ask when making decisions. Activities that do not support these questions may be counter-productive, diverting resources and effort from more valuable endeavours.

When requested to undertake some activities sometimes the answer should be no.

Picking low hanging fruit: not necessarily the best option.

Regardless of intent it is so easy when undertaking a multi-faceted activity to focus on completing the simpler tasks first. Using the rationale of picking the low hanging fruit much effort can be expended in actually avoiding the more difficult tasks. This is not necessarily laziness but possibly an actual disinclination to risk failure. Whilst the simpler tasks are being ‘ticked off’ progress appears to be being made and success appears to be assured. I am reminded of the project adage which says ‘ The first 90% of a project is completed in 90% of the time, the remainder of the project takes another 90%’.

However avoiding making a commitment to starting the harder tasks or perhaps actively procrastinating by undertaking additional, related but unnecessary simple tasks can , as a consequence and possibly disastrously, result in not achieving the outcome of that the original activity was expected to deliver.

Any activity should be analysed for how to best proceed. Picking and choosing individual tasks and leaving the harder ‘stuff’ until last is not likely to be the optimal way to proceed. Balance need to be injected into the process and the best way to proceed should be followed irrespective of personal bias or preference.

Behavioural Motivators: The need to succeed.

There are obviously many different behavioural motivators that drive or inhibit the work ethic of an individual. Many of these can be leveraged or exploited to drive real benefit in the business world.

The Need to achieve: achievement behaviour is an interaction between situational variables and the individual subject’s motivation to achieve. An individual’s motivation can be either implicit where they are driven by spontaneous impulses to act through incentives inherent in the tasks they are undertaking or explicit where their actions are driven by outside influences.

Maintaining a working environment where the tasks undertaken by the individual are in themselves interesting and intrinsically challenging encourages implicit behaviour. Additionally, a business, with a culture of rewards and recognition, provides an environment that strongly encourages the explicit individual to strive for succeed in each of their endeavours.

This desire to achieve can however be perverted when the rewards rather than the achievement become the central focus.

Greed, with all of it negative and destructive connotations unfortunately can become the prime motivator. Balancing the rewards offered against the personal satisfaction provided by the achievement itself becomes crucial.

Behavioural Motivators: Politics and Power

Competing agendas from multiple individuals within an organisation can be counter-productive. These often exist as a consequence of the ‘political’ machinations that are progress. Some individuals within a business, whether consciously or unconsciously strive to gain personal power and influence. The activities in which they engage and how they proceed, are frequently designed to enhance their own standing. Consequently, when the personal goals of the individual do not align with that of the business, there may be a conflict of interest which can adversely affect the performance of other individuals and the business itself. Perceived success in this situation is measured from the personal perspective rather than from the business as a whole.

Almost everyone has come across ‘the Empire Builder’ within an organisation. Whilst the way they operate may not be ultimately malignant, the fact that they exist may cause others within the organisation to attempt to counter their plans with their own. Focus is subsequently redirected from that of the business to that of the individual.

It is probably inevitable that any given business will have some level of political power play in progress at any given time. In recognising this, a wise business manager will attempt to temper the politics by ensuring that all individuals retain a focus on business goals.

Who is in the driver’s seat?

A significant danger in establishing an Enterprise Architecture Practice within a business arises through potential confusion of who is in the driver’s seat.

An IT lead Enterprise Architecture initiative needs to assure the business that they, IT, are not leading the business but offering guidance and advice. Where there is a perception that this is not the case the ‘business’ can feel disenfranchised and can either push back at IT or worse still totally disengage.

I like to use the analogy of a GPS in a car. The driver is able set their final destination of a journey into a GPS. The GPS will then look at where the journey is commencing and establish a route by which the driver, if they follow it can get to their destination. The driver is aware that there may be more than one route available to them (‘Toll’ or ‘no Toll’ as an example)

The driver is not bound to follow the directions provided by the GPS and is able to make decisions of their own that may vary the route. The variation that the driver invokes may or may not provide for a better trip but then again perhaps their local knowledge, not included in the GPS’s database, does give a better result.

If we equate the GPS with an Enterprise Architecture we see that the better informed it is the better the outcome. The GPS can never know all there is to know about conditions on the ground so can be over-ridden by the driver. The driver, similarly recognises that they do not know everything about their journey which is why they are using the GPS.

Once over-ridden a GPS will go through the process of recalibrating a new route to the target destination.

An Enterprise Architecture provides information and guidance to the business. The guidance offered can either be followed or not depending on what additional information the business may elect to consider or in fact how well they trust the GPS itself. I am reminded of the recent debacle relating to the Maps app on the iPhone and the problems it caused some users who followed directions blindly.

The Enterprise Architecture will only be regarded as an asset to be used where the guidance it offers is perceived to be of value. Where it is not, it is either dispensed with or kept ‘in the glove box’ for a time of need.

Failing to Plan is Planning to Fail

How often do we see a perfectly good idea fall flat through the responsible person (if one indeed exists) not having taken care in the planning process? Whilst it is not feasible to foresee all possible obstacles to success the most potentially damaging can be avoided or mitigated by careful planning.

Any initiative that is perceived as providing value to the business and therefore worth doing is also worth the effort to plan carefully. Doing so allows for a better quantitative understanding of the benefits it may bring, the impact it may have on other related initiatives and the resources it may consume in its development and execution.

Not planning can result in unexpected costs, resources conflicts and business impacts that are undesirable. Scenarios arising from not planning range from little impact (because of good luck), failure of the initiative and with the the worst case, failure of the business itself.

Having established planning processes and following them is absolutely essential if outcomes are to be optimised. Anything less is just a gamble.

Size does not matter.

An Enterprise Architecture is able to contribute significant value no matter the size or the nature of the business. A business can be anything from a single person operation through to a multinational conglomerate or a government. All have missions that define their goals and objectives. All have internal and external driver that affects what they do..All wish to succeed in their endeavours. The one person business, in establishing their initial business plan must, if they wish to succeed, define what it is they wish to achieve and decide if it is actually ‘doable’.

Understanding what capabilities they have and what additional ones are required to deliver on its mission helps in shaping the business plan.
Defining the measures of success and having a view as to when success should be achieved allows them to monitor progress.
Describing the processes they will use, the costs of implementing each and how they inter-relate enables the possibility of business process improvement.

How does this differ from what is required of the multi-national or government. The ‘larger’ the business the greater its inherent complexity yet the impact, on getting it wrong, can be seemingly just as great for the small business as for the large.

Not succeeding for the small business can mean it closes. Not succeeding for the large may not be as terminal.

Good, well informed decisions, made in the very small through to the ultra large enterprises are crucial for realising their individual success. This can only occur if they have access to a repository of knowledge and information from which to draw.

An Enterprise Architecture or something which is equivalent (the name is irrelevant) can provide the information that is required to support decisions that will provide an optimal path to success. Where it does not exist the enterprise should look at establishing one or risk failing to achieve what it wants.

Moderating tribal behaviour

Any business with more than more than one person within it will, at times, be faced with having to handle competing views. ‘Political’ agendas within a business can, if not moderated can be so destructive that the business can be torn asunder.

Politics can be born out of the passion arising from individuals having a different vision for the business than others in positions of power and influence. A different vision will translate to different goals and objectives** which in turn will require different processes and solutions.

The astute political player will manipulate others to their way of thinking hence creating a new ‘tribe’ within the business. Business politics and the consequential tribal behaviour can devolve a business from being united to being one which is at war with itself. The business will not benefit where this behaviour persists.

The existence of an operational Enterprise Architecture can assist a tool for the purposes of moderation between competing tribes.

An Enterprise Architecture will be compromised whilst there are alternative visions in place as the likelihood is that the measures of business success will differ for the goals and objectives of each. The application of different measures and the importance in which they are held will result in different decisions being made.

What the Enterprise Architecture can offer is the ability to support the development of the quantitative impact of the decisions that would be made for each vision and potentially provide the proponents of each vision with a better understanding of what they and others are proposing.

With better information the chances of reaching a common understanding of how the business should proceed is enhanced.

Where there are such ideological differences within a business that no common understanding and hence agreement can be reached an Enterprise Architecture can offer some insight as to what the impact of the competing tribes might be with the aim of being able to provide mitigation strategies that would at the very least reduce the substantial negative benefit that would occur otherwise.

5 Business Change

Drivers of Change

Just what is the driver for change within a business?

So often we see change for change’s sake. Perhaps a business decision maker says “ We must have one of those because our competitor has one”. Whether it is a good idea or not is not necessarily considered. The perception that it is a good idea holds sway.

Similarly change is often driven by an unreasoned need that the business should have the biggest and the best and of course with all bells and whistles. The perception here is the users of the new system will appreciate what is provided. This perception needs to be tested.

Whilst the desire to change, driven by the perception of need, may be valid the actual decision to invoke change should be qualified by the identification and quantification of business benefit.

The old adage ‘ If it’s not broken don’t fix it’ should be at least considered when exploring change options.

Is change always the best remedy?

Resistance to Change

Resistance or opposition to change can be as much a barrier to sustainable business growth as is the implementing change for change’s sake.

There are far too many decision makers that lack sufficient insight on what is possible through an unreasoned desire to hold onto the past. How many times have you heard someone say ‘But that is the way we have always done it’ or ‘It has always worked in the past’?

Whether it is the reluctance to take a risk that is the cause of not being prepared to move out of their comfort zone or just a predisposition to not acknowledge that there is any other way the consequence can be a stagnant or decaying business that allows both opportunities to be missed and their more flexible competitors to perhaps take their market.

The Execution of Change

The execution of change, whether in business or in everyday life, once accepted as inevitable, should be managed properly.

Frequently, activities required to implement a change are delayed or postponed whilst other perhaps less arduous or simpler activities are undertaken. “Why do today when you can do it tomorrow?” is a question not so much asked but implied by action. Procrastination of the harder work in favour of the simpler does not really help in the long run.

Twisting an oft use phrase to now say ‘there is madness in the method” seems to reflect the apparent randomness and inefficiencies that often accompanies the deferral of the necessary to accomplish the unnecessary or less urgent.

When the need for change has been accepted it should be embraced with all activities undertaken when required.

Risk management and asking “What if?

It is not reasonable to expect that we can absolutely know everything about those things that can affect anything we undertake to do, there are always elements of risk that we need to consider.

A farmer plants a crop at a particular time of year in anticipation that the weather conditions will be conducive to a successful harvest. A miner will dig a mine expecting it to yield a quantity of ore and sell it at a certain price. A traveller plans an itinerary that supports the trip they wish to make. In each case the expected outcome can be significantly affected through unexpected events. There may be an extreme weather event affecting crop growth, demand for the mined ore may collapse along with its price or a volcano may erupt affecting flight schedules.

When planning to undertake any endeavour and with the realisation that there must be inherent risks we should always be prepared to ask ‘What if …?’

Only when we ask this question can we explore the ramifications of what we plan on doing. It is only then that we can explore options that may mitigate the risks and to decide if the benefits are worth the possibility of failure.

With an understanding of the risks, a level of confidence in how likely they are to be realised and plans on how to mitigate or avoid the risk we can then make a reasoned decision on how to progress.

When undertaking any activity it is always worthwhile to have a Plan B.

A Simple Change Cycle

Change, within a business context, is inherently cyclic in nature. Undertaking change for change’s sake is not something that would normally be expected to occur.

The trigger for a change event is the identification within the business that there is a problem that needs to be addressed. The size of the problem need not be large but does need to invoke the desire for change to occur. Appropriate analysis of the problem should eventually lead to its full definition and an understanding of its root cause.

With understanding and, assuming there is the motivation within the business to continue to address the problem, a solution can be defined and ultimately executed. This will result in changes to the business itself.

The change cycle concludes with an assessment of the outcome of the change. Depending how the original problem has been impacted by the change may itself invoke a further change cycle to be implemented.

Enterprise Architecture – Supporting Business Change

All businesses are dynamic in so far as they need to respond to change drivers. How they respond is very much dependent on how well they know their business and its inter-dependencies.

It is very well accepted that the change outcome will be modified by alterations to key variables.

For instance, assume the Business decided on implementing a change, as a direct response to competitive pressure, that required the creation of a new product.

In its development there is always a balancing act between

Cost: What will be the financial impact on the bottom line of developing the product?
Time: How soon can the product be brought to market?
Quality: How well will the product be developed?

It is well accepted that change in any one variable must have an adverse impact on another.

If Quality is to be increased there must be an increase in cost and possibly time
If Time is to be reduced there must be an increase on cost and/or a decrease in quality
If Cost is to be decreased there must be a decrease in quality and time

For simplicity, with each of these questions, it is assumed that the change scope remains unaltered. A reduction in scope can result in decreased cost and/or time whilst leaving quality unchanged. A reduction in scope however does impact the ability to deliver on the original business requirement.

Where a business has an Enterprise Architecture available to it the ability to determine the impact of change is greatly enhanced. With appropriate measures in place, associated with capability, function and process, the ability undertake analysis in a ‘what if’ scenario provides key input into the decision making process.

With pragmatism at times demanding that cost or time pressures take precedence over quality an Enterprise Architecture can assist in providing an optimal response.

How much can cost or time can be realistically reduced?
What is the operational impact in a change in quality?

Drivers of change are largely outside of a business’s ability to influence.

How a business responds is entirely up to them.

The ability to make wise decisions is predicated on being as informed as possible.

An Enterprise Architecture can provide information necessary to support the decision making process.

Triggers of Business Change

All businesses are continually subject to change. With the recognition that change is inevitable having processes in place to deal with them ensures that a considered and informed response can be made.

The drivers of change can originate from multiple sources, few of which are under direct business control. Some of these are:

Introduction or changes of Legislation;
Introduction or changes in industry codes of conduct;
Competitive pressures;
Financial Pressures;
Customer needs and
Technology changes

Changed or new business driver will trigger a series of cascading events that need to be efficiently and effectively managed.

In response to a change in business driver there will need to be a corresponding change in business strategy. Depending on the change this can then trigger either changes in existing business capability or potentially require the development of new ones.

In realising a capability change there will consequential changes to business process, with a ripple effect on all parts of the business (people and technical) that the changed processes have contact.

With the application of change within a business an assessment of its efficacy should be fed back into the strategy change process.

This assessment can only be reliably made if in executing change key performance measures are set early in the change process and monitored as the change progresses through to completion. By assessing the impact of change and matching it to a known baseline taken prior to the change taking effect, the efficiency of the change process can be measured as well as the effectiveness of the decision making process.

How a business responds to change drivers and the lessons learned through implementation of change can define how well a business operates.

Enterprise Architecture – Managing Risk

Engaging in business activity always has associated with it some element of risk. Embedded in each risk is a probability that some threat, damage, injury, liability, loss or other negative business effect, caused by external or internal factors, may occur.

Unfortunately not all risks are identified.

Each risk, if realised, will affect the business with its impact ranging from minor to catastrophic.

Being in a position to identify that a risk exists, its nature, its potential impact and the likelihood of its occurring provides a business with the opportunity to take risk mitigation or avoidance action.

Knowledge of the business and the external factors affecting it is paramount to being able to effectively manage risk.

An established Enterprise Architecture is a tool that, wielded well, can assist the risk management process.

A well maintained Enterprise Architecture, containing mature and accurate information about the business and its external influencers, is a significant enabler of the business..

With good information the opportunity to identify risk is increased.
With good information to analyse the ability to determine accurately the impact of risk is enhanced.
With the ability to answer ‘what if’ questions the capability to identify activities that either mitigate or avoid the risk is greatly improved.

An Enterprise Architecture can remove much of the ‘guesswork’ out of a business.Decisions can be made with a fuller understanding of the risks, their impact and what can be done about them.

Influencers of Strategy

Business Strategy and its consequent business objectives are shaped by a series of influencers, none of which should be ignored.

At the very highest level the Mission Statement of the business should at the very least set its direction. The Drivers, whether originating from perhaps competitive pressures of from legislative requirements, provides a means by which some prioritisation can be derived.

The Measures establish a quantitative basis from which relative success or failure of any strategic outcomes can be assessed whilst Capabilities describe what the business is either able or needs to be able to deliver.

The combination of understanding where the business is ultimately headed, what is important and on what time horizons, what the business is actually able to do coupled with a quantitative measure of what defines success enables a foundation from which a business strategy and specific objectives can be built.

Business Capability – a key to success.

Central to the success of a business are the capabilities that it has available through which it can deliver on its defined strategy.

Individual capabilities can exist at various levels of maturity and whilst they may be being used the question always needs to be asked : Are they as effective as they should be?

An athlete for example may be quite capable of running and completing a marathon but are they capable of winning a race?

The ability to be able to successfully deliver products and services to the customer base of a business is tied up with the maturity of its capabilities.

Establishing and understanding the relationship between each business capability and

the strategy it supports;
dependent products and Services;
its information requirements;
delivered business functions and
supporting business processes

as well as a setting a benchmark against which it should be measured provides a structure through which the maturity and hence the success of the business can be improved.

Capability Maturity Cycle

The ability to deliver effective capabilities is at the heart of any successful business.

Capabilities do not come into being perfectly formed but tend to mature as the perceived need for them becomes more apparent.

Driven by both external and internal influences the motivation to establish and mature a capability arises from the relative benefits it brings to the business. Usually competing with other capabilities for the development dollar understanding how and when it can provide value assists in the prioritisation process for having the capability either realised or improved.

Once built or modified then subsequently utilised measuring the effectiveness of the capability to deliver provides the required feedback to the maturation cycle.

Achieving Business Balance

Operating a business successfully entails the constant maintenance of a balancing act between competing influences.

Establishing and subsequently maintaining the alignment with a defined business strategy requires a real understanding of the difference between what is wanted and what is actually needed.

Understanding the motivations driving wants as compared to the requirements driving needs provides a means to moderate the aspirations defined within a business vision with that of the reality as affected by either the capability to deliver or financial considerations.

Before making any decision affecting the business ask the questions:

Why should this be done?
What is the expected outcome?
In making the decision will the business be positioned to be in a better place?

Questioning decisions before being made is one way of maintaining balance.

Business Stressors

All businesses regardless of whether they are large or small are subject to a variety of business stressors. How the business ultimately responds to these will have significant impact on how the they will perform.

Financial stressors will affect how and what they business is able to invest in its future. The ability to either access funds to grow the business or the need to conserve what funds are available affect the ability to both innovate and execute.

The good reputation of a business is something that is essential to be preserved. How the business is perceived in the market will affect the types of activities that should be undertaken. For instance, if the business is seen as an innovator then it is expected that innovation will continue to flow. Alternatively if the business is seen as providing exemplary service then standards must be maintained. The good reputation of a business is something that may take ages to establish. It certainly does not take long to lose.

Competition is a stressor that can be quite healthy. That other businesses may be offering products and services in competition to your own can provide the impetus to either differentiate with the view of winning additional market share or to consolidate and accept the status quo. This second option is the riskier as of course the competitor may elect themselves to differentiate and steal your market.

Organisational stressors, depending how they are expressed can be either extremely positive or quite destructive. Internal power politics, where the achieving of personal agendas becomes more important than those of the business, can lead to business failure. Healthy discussion arising from differences of opinion can however lead to significant business improvement.

That stressors exist within a business must be recognised. Every identified stressor must have some corresponding ongoing activity as without responding to them through either mitigation or management the business could ultimately fail. Managed appropriately a business can prosper.

Differentiating wants and needs.

A Business will often decide that they ‘need’ to undertake certain activities so as to solve particular problems that they perceive themselves as having. Once these activities have been completed and the ‘problems’ solved the business expects to reap the benefits of a job well done. This is all well and good in theory but does tend to fall down in practice. The issue tends to be in differentiating between wants and needs. What may seem like a ‘good idea at the time’ and may have been very well executed might not, in fact, deliver the business the benefits it expects. Perceiving a problem existing does not necessarily imply that it does.

Deciding that a particular solution is appropriate does not mean that it is. Without sufficient and accurate information available to them, a decision maker does as good a job as they are able. Without better information they may ‘want’ to believe that a problem exists and also ‘want’ the identified solution to be the correct one. How often has a business been influenced, for example, by a software vendor in making their pitch that the only realistic solution to a problem (which the vendor has defined) is their solution. The vendor is out to convince the business that they also have the problem and the vendor’s solution will be their ‘saviour’. Perhaps the business does have the problem suggested.

An Enterprise Architecture provides a tool against which the business can assess the reality of the problem existing and the impact it is having if it does exist. The nature of the impact can define whether the ‘problem’ needs to be resolved. If a problem does in fact exist and is deemed necessary to resolve a business can explore the available options. A particular vendor solution might be appropriate, then again it might not.

An Enterprise Architecture can provide insight into what is ‘needed’ to solve a problem and optionally allow what is ‘wanted’ but not ‘needed’ to be discarded, consequently better defining the scope of what needs to be undertaken. Focussing on the needs rather than the ‘wants’ provides for a more concise solution, delivering the benefits that are required and potentially eliminating extraneous cost and effort from the equation.

Transitioning from Goals to Outcomes and Capabilities to Services

To succeed, a business needs to transition its goals into beneficial outcomes. Goals, in being realised, need to be supported by business capability which describes what a business is able to do and services which leverage combined capabilities to define something tangible that can be consumed by either internal or external customers.

Whilst capabilities define the ‘what’ and have an internal focus, services define the ‘what and how’ and are more externalised. Customers of a businesses are directly interested in what services the business offers not necessarily what it is capable of doing. Customers may be intimately interested in how well the services are executed as they are personally affected. Services should be defined that progress the goals of the business but should also play to the business capabilities.

A service that does not progress business goals should be questioned as to its existence. A service poorly executed, through not having the business not having the capability to deliver, will not be received well by its consumers. An Enterprise Architecture can be pivotal to establishing services that progress the goals of the business. With the ability to determine the capabilities required to support the deliver business goals the Enterprise Architecture can assist in highlighting what areas of the business need maturing.

An Enterprise Architecture can also provide information to support the assessment of services that should be either developed or changed. Keeping business value clearly in sight services can be constructed from existing, new or improved capability that provide the greatest benefit. An Enterprise Architecture provides a business with a tool that assists in defining:

What capabilities are required?
What Services provide the best value?
What benefit each service is expected to render to the business and
What benefits are ultimately realised?

Successfully transitioning from business goals through capability development to service delivery provides business outcomes that provides the expected realisation of business benefits.

It is not an overhead

Many members of a business community with access to an Enterprise Architecture see it as an overhead that ‘gets in the way’ of them ‘doing their job. As an overhead it is seen as something apart from their ‘Business As Usual’ activities offering a distraction rather value and thus is a liability. The purpose of an Enterprise Architecture within a business is to provide a governed mechanism through which business vision and strategy is able to be translated into effective enterprise change. This is accomplished by creating, communicating and improving the key requirements, principles and models that describe the desired future state of the business and supporting the transition to that goal. Enterprise Architecture is consequently not an overhead but integral to business success. Taking an idea from initiation through to execution for example it can be seen that an Enterprise Architecture is integral to each stage in its development.

Idea: Does it progress the business vision and strategy?
Feasibility: Is it doable, what are the benefits and should it be done?
Plan: When should it be done and how?
Design: What standards and principles are applicable?
Build: Does what is being built match what is required?
Execute: Does the outcome deliver the identified benefits?

An Enterprise Architecture is consequently not a thing apart but is embedded into the very fabric of the business. By providing appropriate information when required it ensures that:

No unnecessary activity takes place.
Duplication and waste is minimised.
Resources are conserved.
Decisions on prioritisation are more efficient.
Scope and planning of projects emerging from idea generation is managed.
Change is effective.

An Enterprise Architecture should not be seen as an overhead but an asset with which the business will derive significant benefit.

Table of Contents