Architecture in a business context

© 2015 - artITians

Slide 1 better business by design

Architecture in a business

context

Some thoughts

Kim Parker

Melbourne

© 2015 - artITians


Contents• Documentation

• Multiple facets of a business

• Holistic Architecture

• Business Architecture in perspective

• Enterprise Architecture: A value proposition

• Enterprise Architecture: Why have one?

• Knowledge Repository

– Scope and Range

• Language in business

– You’ve built me what?

• Take small bites

• Gold Plating

• Early delivery

• Enterprise Architecture: Not an end in itself

• Breadth or Depth

• Adopting an Enterprise Architecture Hybrid

• Missing the mark

• Enterprise Architecture and the Brownfield business

• Five Cs of Enterprise Architecture

© 2015 - artITians


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.

An architecture repository is a living and dynamic source of knowledge

© 2015 - artITians


Multiple facets of a business

• 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.

The ability to generate multiple views of a business is a real benefit.

© 2015 - artITians


Holistic Architecture• 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.

© 2015 - artITians


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.

© 2015 - artITians


Knowledge Repository

• 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.

© 2015 - artITians


Scope and Range

• Having access to a searchable and actively maintained knowledge repository

provides businesses with a valuable tool when exploring possible initiatives. The

ability to rapidly define both the scope of an initiative and its range assists in the

tasks of prioritisation, planning and execution.

• An initiative’s scope is defined by what needs to be undertaken so that it may be

brought to fruition. Its range can be defined by describing what else in the business

is impacted or influenced.

• By having an appreciation of both the scope and the range an initiative can readily

be turned into a manageable project. With changes in scope resulting from adding,

deleting or changing requirements the impact on the project’s range can be better

determined.

• With active knowledge of the scope and range, the efficacy and cost of delivery of a

project can be more tightly contained and the impact on the business can be

managed.

• Reliable, accessible knowledge within the business will bring significant benefits.

© 2015 - artITians


Language in business• Since time immemorial guilds had developed language used to communicate ideas

and concepts to their members. This language, once established, was also used to

exclude non-members from being able to understand their ‘secrets’ unless they

became accepted and inducted into the guild.

• Whilst Businesses in general and Information Technology in particular have the

appearance of being inclusive the use of industry specific nomenclature and the

explosion in the use of acronyms can create a barrier to entrance that is just as

difficult to pass as was that of the guilds. Terms used within a line of business can

be identical in sound across industries but have very different meanings. Acronyms,

including the dreaded TLA (Three Letter Acronym), can have quite diverse

meanings depending on the industry and the context within which they are used.

• The problem with communication is where not all parties are familiar with all

aspects of the language to be used.

• Prior to good communication being established a common vocabulary must be in

place and agreed by all participants. TLAs, if they must be used, should be

explained on first use.

• Without this, misunderstandings will take place.

A common and agreed language enhances understanding.

© 2015 - artITians


You’ve built me what?

• What the business wants from IT and what it gets from IT can often be very

different things. This may not purely be the fault of either the business or IT but be

a fault in the very nature of communication itself. Language can be imprecise in its

use with the same word, term or even acronym meaning different things to different

people. The failure to establish a common vocabulary when commencing a

conversation can lead to significant misunderstanding about expectations.

• When gathering requirements for a business initiative they must be expressed in

terms that are absolutely unambiguous to all parties. Supplying associated

acceptance criteria for each requirement can provide necessary validation of the

requirement’s intent and IT should play back to the business what it understands.

• To ensure that what is delivered is what was wanted, bidirectional communication

between parties must be clear. Without this, no matter how competent both the

business and IT are at filling their respective roles the end result of any initiative will

be anyone’s guess.

Poor communication, poor understanding, poor outcomes.

© 2015 - artITians


Take small bites• Attempting to ‘Boil the Ocean’ is a term that springs to mind when reflecting on

many of the Enterprise Architecture endeavours I have seen undertaken over the

years. Whilst the end goals were laudable the ability to actually reach them was

severely impacted by the magnitude of the task.

• Hindsight would be useful if it could be applied before the architecture work were

commenced. Rather than futilely attempting to do it all it would have been far more

useful to have built segments of the architecture in sufficient depth and breadth to

be of actually use.

• An Agile approach to Architecture development would have been more productive.

Establishing architecture content in sufficient detail to address defined questions in

parts of the business whilst keeping an eye on the shape of the overall architecture

would provide for realising business benefit faster whilst simultaneously

constraining unmanaged growth.

.Taking smaller bites of the architectural landscape equates to ‘boiling the

thimble of water’: a much easier proposition

© 2015 - artITians


Gold Plating and early delivery• Having worked as a consultant working for a large company selling products and

services to its clients I frequently heard the two mantras ‘ Over deliver and deliver

early’ and ‘Deliver on- time and under budget’ Whilst both of these seemed to have

good selling points the first certainly had some downsides.

• The first of the mantras was client focussed. Over delivering often was accomplished

by the inclusion of additional functionality over and above that which had been agreed

and which was deemed ‘by us’ as being useful to the client. There were no

requirements that indicated how this functionality should be realised nor was there any

perceived need by the client that it was necessary.

• Whilst there were certainly times where the extra functionality was appreciated there

was always the danger of the client being dissatisfied. I had heard the comment ‘You

have sold us a Rolls Royce when all we wanted was a ‘Volkswagon’ Presuming that

the client will be appreciative is not good technique. If additional functionality was

identified as being necessary it would have been better to discuss this with the client

with the possibility of a managed scope change.

• Adding unasked for functionality was the Gold Plating that whilst possible providing

some value to the client was regarded as part of the cost of delivery that if omitted

could have resulted in a lower cost. Unless the functionality was absolutely required

the client would more than likely have preferred the lower cost.

•

© 2015 - artITians


Delivering Early

• Delivering early, on the surface, also seemed to be beneficial. There,

however, was a downside to this. A client will have made plans based on

the contracted delivery date of the product or service. Early delivery may

have caused significant disruption to those plans and also leading the

client to think that the original contract had included too much

contingency and thus consequently an inflated price. Their view was

possibly ‘No value to us the client, increased profit to the provider’

• This mantra ‘Deliver on- time and under budget’ was far more sensible in

its intent. Here the client was to be delivered a product or service with

agreed functionality at the time stipulated for an agreed price. The under

budget portion of the mantra was internal in its focus and related to

undertaking the work involved wisely. By taking care and mitigating or

avoiding risks any contingency built into the budget could be either

converted to profit margin or in some instances returned to the client.

Everyone was a winner.

‘deliver to what you say, when you say and for the agreed price.’

© 2015 - artITians


Enterprise Architecture: A value proposition.

• Establishing an Enterprise Architecture Framework within a business and populating it with relevant content

certainly seems to be a laudable endeavour. Why then is there so much opposition to either starting or

continuing one started?

• The constant question that the business often throws up is ‘what is the point?’ Activities supporting the

Enterprise Architecture are often regarded as an overhead imposing both a cost and time impost on the

development of business initiatives.

• When the business is cost sensitive it can often make the ‘easy’ decision to dispense with the architectural

component.

• Where the mistake is made is in the original selling of the Enterprise Architecture.

• Being perceived as an ‘end’ in its own right tends to divorce it from the real world business issues. It would be

rare for a business to have a goal to have an operational Enterprise Architecture. It would however not be

unreasonable for the business to have a goal of operational efficiency.

• An Enterprise Architecture and the disciplines that its enhancement and maintenance entails should instead be

regarded a tool by which the business can be optimised so as to reach it goals. There would be a hue and cry if

the business were stripped of using, say Microsoft Word, to support much business activity. The word

processor has become an invaluable tool of trade.

• What is not seen however is the impact on the business of not applying Enterprise Architecture disciplines. They

see the costs when imposed but not the benefits. They see time consumed but not the time saved.

• Part of this comes about through the way in which benefits identified for a new business initiative are often

managed. Options are presented with some level of benefit associated with them. The ‘do nothing’ impact is

rarely enumerated.

• Similarly whilst the benefit of ‘doing’ Enterprise Architecture may be defined the impact of ‘not doing so’ is rarely

considered.

• For Enterprise Architecture to be truly part of a Business As Usual scenario its value proposition must be

properly communicated and understood by the whole business.

© 2015 - artITians


Enterprise Architecture – Not an

end in itself• Having an Enterprise Architecture established within a business is not an end in

itself. The Enterprise Architecture exists for no other reasons than to assist the

business to determine an optimal strategy to achieve its business goals and ensure

that the strategy can be realised efficiently and cost effectively.

• This unfortunately is not always the case. Rather than being a tool that can help the

business its very existence, without the full appreciation of why it is there, can

distort the business by driving it in directions that might fill out another portion of the

architecture but not lead to substantial business benefit.

• Just like Information Technology is an enabler of business and not the driver, the

Enterprise Architecture is the shaper of business and not the business itself.

• Keeping the practice of Enterprise Architecture in perspective and ensuring that it is

undertaken purely to support the business endeavour should provide for a healthy

and potentially prosperous outcome.

An Enterprise Architecture is a tool supporting a business outcome

© 2015 - artITians


Breadth or Depth

• A question that is sometimes asked when populating an Enterprise Architecture framework is

should there be an emphasis on breadth or depth. The danger of proceeding without first asking

this question is that given the richness and the quantity of the content that can be included that

whilst progress is seemly being made there may be little business benefit being realised.

• Informing the depth/breadth issue should be: What are the questions that the business wishes

to be able to ask of the Architecture. Knowing these questions can then permit the required

analysis that will define the type and scope of the content that needs to be captured.

• The architecture’s reason for existing is to be able to answer questions that the business deems

to be important. Whether the content is either broad or deep (or somewhere in between) then it

is a ‘simple’ matter of determining what is required to answer the business questions.

• The capability of the architecture to answer business questions is also a key selling tool to the

Architecture’s continued existence and ability to mature.

• The Business needs to perceive that it is being provided with real quantifiable benefits.

© 2015 - artITians


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.

© 2015 - artITians


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.

© 2015 - artITians


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.

© 2015 - artITians


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:– •he 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.

© 2015 - artITians


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

•