Driving the Adoption of Enterprise Architecture Inside Small Companies

Lessons Learnt from a Long Term Case Study

Christophe Ponsard and Annick Majchrowski

CETIC Research Centre, rue des Fr

eres Wright 29/3, Charleroi, Belgium

Keywords:

Enterprise Architecture, Very Small Entities, TOGAF, Process Assessment, Process Improvement, ISO29110.

Abstract:

Including Enterprise Architecture (EA) as part of an organisation’s processes is an important milestone in

reaching higher maturity levels because it will drive the a long term alignment of IT and business dimensions.

This paper explores some important questions related to the introduction of EA inside very small enterprises

or entities (VSE), referring to the very common situation where the IT department has limited resources even

possibly in a larger organisation. We provide a number of elements of answers on how EA can successfully be

deployed in VSE based on a study of approaches already developed by others complemented by our extensive

experience in helping such kind of companies to improve their IT practices and adopt EA. The paper is illus-

trated on a multi-year case study. It has also a special focus on the ISO29110 standard directed towards VSE

and possible ways to evolve it to take EA into account in more advanced maturity proﬁles under preparation.

1 INTRODUCTION

Enterprise Architecture (EA) is a discipline aiming

to proactively and holistically respond to disruptive

forces encountered by entreprises. It relies on the

identiﬁcation and analysis of the execution of change

toward the desired business vision and outcomes.

(Gartner, 2013). According to (Lankhorst, 2005), it is

a coherent whole of principles, methods, and models

that are used in the design and realization of an en-

terprises organizational structure, business processes,

information systems, and infrastructure.

Although the beneﬁts and adoption in large com-

panies is well established, the situation is quite differ-

ent for smaller organisations due to the overall matu-

rity level and the complexity involved in using the cur-

rent EA approaches compared to the available man-

power (Bhagwat and Sharma, 2007). Still, it is recog-

nised that EA can bring several beneﬁts in helping

companies of smaller size such as more clearly deﬁn-

ing a vision of their business architecture and compet-

itive strategy, assessing how well their IT processes

and infrastructure are supporting them, and easing

the communication across management and operation

(Buchalcevova, 2011)(Bernaert et al., 2013).

From an economic point of view it is important to

address such a target because micro and small enter-

prises represent the vast majority of enterprises across

the world. According to the latest ﬁgures published

by OECD (Organisation for Economic Co-operation

and Development), in the Europe of 27, about 90 per-

cent of the enterprises have less than 20 people. It

is about 75 percent in the US (OECD, 2013). Larger

organisation will also be impacted because they of-

ten heavily rely on products developed by small com-

panies. Another point is that even large companies

often include smaller entities which maybe in charge

of speciﬁc project portfolio, possibly in a multina-

tional context. In this paper we will use the term

of Very Small Entity (VSE) which was coined by the

ISO29110 standard and which refers to an enterprise,

an organization, a department or a project having up

to 25 people (ISO, 2011).

The purpose of this paper is to bring some prac-

tical elements of answers to some important impor-

tant questions related to the best way to introduce and

to foster the adoption of Enterprise Architecture in-

side VSE. Our approach is based on the validation of

a number of suggested approaches, guidelines, pat-

terns, and other kinds of practices reported by in the

literature for this type of target. Our validation re-

lies on consultancy work carried out with Belgian en-

terprises over the past years. More speciﬁcally we

will take as running example the case of a Newborn

and Child Care organisation. We will envision dif-

ferent dimensions like the WHAT (effectiveness of

practices) and the WHOM (role, motivation, commu-

nication among people). Thanks to this long lasting

334

Ponsard C. and Majchrowski A..

Driving the Adoption of Enterprise Architecture Inside Small Companies - Lessons Learnt from a Long Term Case Study.

DOI: 10.5220/0005464903340339

In Proceedings of the 17th International Conference on Enterprise Information Systems (ICEIS-2015), pages 334-339

ISBN: 978-989-758-098-7

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

collaboration (more than 7 years), we are also able

to take into account the progressive growth in matu-

rity of the organisation and to report some interesting

ﬁndings about WHEN it is interesting to consider the

introduction of new practices, especially combining

the Enterprise Architecture with a Software Process

Improvement (SPI).

Our main observations are formulated under the

form of some lessons learnt that have a double pur-

pose: (1) help people engaged in the same process

with or within VSE and (2) provide useful guidelines

that can further drive the elaboration of more struc-

tured recommendations or even standards. Especially,

we carried out our work with the ISO29110 standard

as reference framework for VSE from the start (even

before it was adopted).

The remainder of this paper is structured as fol-

lows: Section 2 reviews relevant literature work about

the current use of EA among VSE. Section 3 details

our case study. Section 4 draws the main lessons

learnt from our case and puts them in the light of

the previous literature work. Finally section 5 draws

some conclusions and presents some perspectives.

2 SURVEY ON EA ADOPTION

WITHIN VSE

This survey is structured based on the key following

questions:

• what are the key requirements for a successful EA

adoption by VSE?

• among the large number of framework, are there

some that are better suited for their use by VSE?

• how to assess the current maturity level with re-

spect to EA?

2.1 EA Adoption Success Factor

An extensive survey performed by (Bernaert et al.,

2013) highlighted the following limitation factors and

how to address them:

• day-to-day view: enable SMEs to work in a time

efﬁcient manner on strategic issues

• limited IT knowledge and technical skills: keep

the approach simple

• lack of resource: do not require assistance of ex-

pert

• lack of knowledge management: enable sharing

of descriptions

• lack of management commitment: get CEO in-

volved in the approach

The author also deﬁnes 3 actions leading to en-

hanced adoption based on the Technology Adoption

Model (TAM) from (Davis, 1989):

• Increase the Perceived Usefulness: it is related

to performance/productivity/effectiveness aspect.

Practical implementation should be provided (like

case studies, tutorials, ...) as well as feedback to

help developing EA techniques that bring more

advantages for SMEs

• Increase the Perceived Ease of Use: it is related to

the ease to learn/control/understand/interact/use.

Techniques to lower time spent to carry out EA

tasks should be sought after (like templates, efﬁ-

cient tools,...).

• From Actual to Perceived Efﬁcacy: based on im-

plementation, feedback is used to adapt EA im-

plementation and successful practices are spread

across the organisation.

2.2 Best Framework for SME

Numerous EA frameworks and methods are available

on the market. Among those, the TOGAF Standard is

the most frequently used framework in general. Ac-

cording to (Cameron and Mcmillan, 2013), it stands at

82.2% followed by Zachman (52.7%), Gartner (26%),

FEAF (21.2%), and DoDAF (16.4%). However the

major trend (54 %) is to use an hybrid framework as

no single framework can addresse all the needs of a

particular organization.

About the ﬁtness for use by SME, there is a lack

of literature on this topic also reported by (Alm and

Wißotzki, 2013). The leading method TOGAF (The

Open Group, 2009) has also a number of positive

characteristics for the adoption for SME: the full ma-

terial is freely available through the Open Group,

it has a simple metamodel, good semantics with 4

levels of abstraction (Business, Application, Data,

and Technology). It also comes with a methodology

called ADM (Architecture Development Model). The

drawback is that it can be quite complex and time con-

suming to use. However a recent survey reported in

(Alm and Wißotzki, 2013) showed that SME are in-

creasingly willing to pay such a cost given the pay-

back in a increasingly dynamic and competitive busi-

ness environment. This cost can also be kept under

control by weighting some phase. However it is not

advised to completely omit some phases.

DrivingtheAdoptionofEnterpriseArchitectureInsideSmallCompanies-LessonsLearntfromaLongTermCaseStudy

335

2.3 EA Maturity Assessment

A number of assessment methods are available to help

in assess a the maturity level of a company in apply-

ing EA. A simple and easy framework is the Cornwell

Dashboard (Bailey, 2007). It is based on a Zachmann

dashboard (Zachman, 2003) which categorises mod-

els in terms of their audience (business, system,...)

against EA dimensions (data, functions, people,...)

Each aspect can then be ranked in that matrix.

A number of available assessment frameworks

are inspired of the 5 CMMI levels: (1) not de-

ﬁned/informal/ad hoc, (2) repeatable, (3) deﬁned, (4)

managed and (5) optimised. Some examples are the

TOGAF maturity framework(The Open Group, 2009)

and the NASCIO EA Maturity Model(NASCIO,

2003). Such frameworks give progressive objectives

for each level and to get to the next level. However,

like CMMI, they might be overkill for VSE.

Finally let us also mention the ISO29110 stan-

dard addressing the ”Systems and Software Life Cy-

cle Proﬁles and Guidelines for Very Small Entities”

(ISO, 2011) which is freely available. As opposed

to CMMI, it takes a progressive approach based on

a set of proﬁles that range from an entry proﬁle to

the most advanced proﬁle. The entry proﬁle consists

of the simplest set of development practices, covering

software implementation and project management ac-

tivities. This is followed by the basic, intermediate

and advance proﬁles that progressively cover a grow-

ing set of activities that can handle more complex sit-

uations involving a larger range of risks. The stan-

dard also includes dedicated guidelines for VSEs that

are complemented by deployment packages to ease

their adoption. Speciﬁc aspects should be covered by

the intermediate proﬁle (e.g. portfolio management)

and the advanced proﬁle (e.g. IT strategy deﬁnition).

ISO29110 provides a very good assessment potential

coming with practical recommendations which ease

a Software Improvement Process. Such an approach

was pointed as a very good ground to introduce En-

terprise Architecture (Buchalcevova, 2011).

3 CASE STUDY: A BELGIAN

NEWBORN AND CHILD CARE

ORGANISATION

This section highlights some relevant aspects of the

case study performed from 2007 to 2014 in a Belgian

NewBorn and Child Care Organisation (ONE, 1919).

We ﬁrst present some background information about

the organisation and the challenges it had to face dur-

ing those years before detailing the major steps in in-

troducing enterprise architecture practices. Note that

ﬁgures and some text presented in this section is bor-

rowed from the organisation website and enterprise

repository with the permission of the CIO and with

some adaptations (translation and project renaming).

3.1 Background on the Organisation

ONE is a public institution that develops birth and

childhood policies. Its main missions (unchanged

since its creation in 1919) can be summarised as fol-

low:

• to support children’s development within their

family and social environment; to advise and sup-

port pregnant women, parents and families med-

ically and socially in order to ensure the global

wellbeing of their children. Most services offered

by ONE are free.

• to organise (that is, to control and sometimes to

ﬁnance) day care centres for children outside of

the home environment. ONE’s role is to ensure

that these structures operate correctly and provide

quality care for children.

ONE is organised in three layers ensuring both

a complete geographical coverage with a close level

of proximity with families and a good management

structure:

• a central management located in Brussels group-

ing all the strategic (top management) and support

function (ﬁnance, IT, training)

• decentralised operational management located in

6 ”subregions” which coordinate the day-to-day

ﬁeld work, they rely on two key roles: adminis-

trative referent and team coordinators (about 30).

• ﬁeld teams (about 80) composed of nurses (about

850) working together with hired doctors (about

1000). Each team is in charge of a small geo-

graphic location (e.g. a small city, a district of

a bigger city)

ONE IT department can be considered as a VSE

inside a bigger organisation: it is composed of 15 peo-

ple. It is mostly relying on the externalisation of the

development work through analysts (3) and projects

managers (3). The other major activity is to ensure

the good operation of the whole IT infrastructure:

servers, clients stations and all deployed applications

both on server and client sides. This is ensured by

support and exploitation managers (6) and only one

internal developer. The whole department is coordi-

nated by the CIO and the IT architect.

ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems

336

3.2 IT Challenges and Move to EA

From 2005, the IT department was faced with the re-

newal of a number of aging applications and the need

for larger IT support both in terms of number of pro-

cesses to support. More recently the need for deeper

IT penetration also emerged (i.e. down to the third

layer of Figure ?? using mobile systems). Those chal-

lenges resulted in a series of large IT projects which

required to improve not only IT project development

practices but also stressed the need for Enterprise Ar-

chitecture. Table 1 summarises the main steps taken.

Table 1: Retrospective time line.

Year Project Improvement

2008 School care Systematic project follow-up

2009 Subsidies

Management

Preliminary process modelling

(MagicDraw)

2010 GPS Process cartography with

guidelines, ARIS Repository

2011 Renewal of

subsidies

management

Modelling of subsidies pro-

cesses and infrastructure

2012 IT for coordi-

nator/nurses

Modelling of ﬁeld processes

and infrastructure

2013 Mobility

hardware

Uniﬁed analysis process and

alignment with EA process

The path followed combined both Software Pro-

cess Improvement (SPI) and Enterprise Architecture

(EA) by people having regular meetings together.

This team was not only composed of IT experts but

also from trained people acting as relay inside spe-

ciﬁc department of the organisation. A key role is

also the internal auditor which has an in dept knowl-

edge of the processes (how well they are deﬁned, they

perform, who master them,...). The GPS is a large

effort to gather the organisation structure, processes,

IT applications and underlying IT infrastructure. This

work was made clearly visible on the intranet with a

statement of the goals and a FAQ.

In the rest of this section we detail main achieve-

ment making the connection between SPI and EA.

3.3 Document Templates and Models

A key step was the deﬁnition of high quality standard

template for the requirements engineering phase and

especially for capturing the as-is and to-be business

processes. The modelling was supported by the ARIS

platform (SoftwareAG, 1992). Business processes

were modelled using Event Process Chains (EPC) en-

suring a good way to decompose the processes. They

also ensured a good level of completeness and con-

sistency. Some automatic generation could be used.

However it was not practical enough to be generalised

Figure 1: Document Templates and Guidelines.

so it required additional work to integrate diagrams

inside a speciﬁcation document. Figure 1 illustrates

the relation between models and templates across the

whole analysis phase.

3.4 Enterprise Architecture Framework

The starting point for introducing an enterprise frame-

work was closely related with the selection of sup-

porting tool: the ARIS toolset (SoftwareAG, 1992).

ARIS come with a methodology depicted as a house

composed of organisation, data, control and function

elements which can be used in compliance with TO-

GAF. As the tool was far too rich, only a subset

of diagrams were selected together with guidelines

on how to use them. The TOGAF Architecture De-

scription Method (ADM) was not used systematically.

However most phases were covered, especially with a

strong emphasis on the requirements as described be-

fore. Business, Information System and Technical Ar-

chitecture were also detailed in dedicated parts of the

repository. Migration, governance and change man-

agement were only addressed in document form and

not captured in the tool repository. Figure 2 shows

how the deﬁned enterprise framework is aligned with

DrivingtheAdoptionofEnterpriseArchitectureInsideSmallCompanies-LessonsLearntfromaLongTermCaseStudy

337

Figure 2: Project and EA Alignment.

the models deﬁned at project level.

4 LESSONS LEARNT

Based on our experience we can formulate some in-

teresting lessons learnt in relation with the topics dis-

cussed in Section 2.

About Adoption Factors - Efﬁciency. Having tem-

plates and guidelines deﬁned and shared by the whole

team is a key factor. It is important to ensure all peo-

ple adhere to the agreed conventions and avoid using

some ”advanced” features that will not be understood

by other reader. As the model repository becomes

the reference source of information, it is important to

keep it up to date and try to generate as much doc-

umentation as possible from the repository and min-

imise the extra work required to produce textual docu-

ment. In order to be efﬁcient as-is and to-be processes

can be modelled together with speciﬁc convention to

highlight the delta when the structure was not altered.

About Adoption Factors - Ease of Use. The

methodology should deﬁnitely be kept simple. The

toolset used should also have a good interface. In our

experience, it was not always easy to control the lay-

out in diagrams which generated some frustration and

slowed down the learning curve for some analysts.

About Adoption Factors - Perceived Efﬁcacity. It is

important to make (partly) validated work visible not

only to the team but to the whole organisation. All

feedback should be welcome and people giving good

feedback are good candidate for playing some role in

the enterprise architecture. A good place to start is

an enterprise intranet but the best place is a knowl-

edge management platform (such as a forge, share-

point) which is more easy to keep alive and also offer

feedback channels. The information present is also

very interesting for new people joining the organisa-

tion and a speciﬁc entry point should be dedicated to

them.

About the Architecture Framework. Compliance

with a standard framework is not a goal for VSE.

Standards should only be used as check list to ensure

no important aspect is missed. The goal is to produce

an adapted/hybrid approach that covers the company

needs and is both efﬁcient and easy to use. The frame-

work should be updated from time to time typically

after some key milestone (large project, new strategic

direction,...).

About Combining SPI and EA. It is deﬁnitely a

good way to proceed: it is better to start by ensur-

ing consistent analysis development processes across

projects on which a clear enterprise vision can then

be build. Building on project managed in various way

ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems

338

would not only be inefﬁcient to gather the information

but also to have a common communication basis. It is

however not necessary to wait for the whole SPI to

have taken place before starting enterprise modelling.

Once the use of some artifacts have been standard-

ised inside the organisation, the information it cap-

tures can be passed to the EA. The deployment can

thus proceed from analysis, to design, tests, etc.

5 CONCLUSIONS

In this paper, we have addressed some questions re-

lated to the introduction of Enterprise Architecture by

Very Small Entities. Preliminary answers from the lit-

erature were faced with our practical experience in a

multi-year case study covering the introduction of EA

in an organisation undergoing important changes.

Based on this we could draw a number of lessons

learnt highlighting interesting adoptions practices.

Among the interesting adoption factor identiﬁed, the

adopted way to progressively introduce TOGAF con-

cepts and steps incrementally in the course of succes-

sive projects could limit the overhead for the organi-

sation and enable a progressive growth in maturity. It

is also worth stressing the good complementarity be-

tween Software Process Improvement and Enterprise

Architecture. Taking this path further, it is very rel-

evant to take into account progressive Enterprise Ar-

chitecture practices as part of the intermediate and ad-

vanced proﬁle of the ISO29110 proﬁle under prepara-

tion.

We are currently working on consolidating the

identiﬁed practices and structuring them in the spirit

of the emerging intermediate and advanced proﬁles of

the ISO29110. Two other validation case studies are

also ongoing respectively in the banking and clinical

sectors. We also plan to report about our work to the

ISO WG24 in order to guide the elaboration of those

new proﬁles.

We also believe this work is worth being shared

with the EA community given the currently limited

available work reporting on this topic and the increas-

ing incentive for VSE to adopt Enterprise Architec-

ture practices.

ACKNOWLEDGEMENTS

This work was partly funded by Walloon Region. We

warmly thank the Ofﬁce for Newborn and Child Care

for allowing us to report about their case and Alain De

Preter for sharing his expertise and providing feed-

back.

REFERENCES

Alm, R. and Wißotzki, M. (2013). TOGAF adaption for

small and medium enterprises. In Business Informa-

tion Systems Workshops - BIS 2013, Pozna

n, Poland,

June 19-20, 2013, Revised Papers, pages 112–123.

Bailey, I. (2007). The Cornwell Enterprise Architec-

ture Maturity Dashboard. http://www.modaf.com/

ﬁle download/38.

Bernaert, M. et al. (2013). Enterprise architecture for

small and medium-sized enterprises: a starting point

for bringing EA to SMEs, based on adoption mod-

els. In Devos, J., Van Landeghem, H., and De-

schoolmeester, D., editors, Information systems and

small and medium-sized enterprises (SMEs) : state of

art of IS research in SMEs, pages 67–96. Springer.

Bhagwat, R. and Sharma, M. K. (2007). Information system

architecture: a framework for a cluster of small- and

medium-sized enterprises (smes). Production Plan-

ning and Control, 18(4):283–296.

Buchalcevova, A. (2011). Software process improvement

in small companies as a path to enterprise architec-

ture. In Proc. Information Systems Development, Ed-

inburgh (UK), pages 243–253.

Cameron, B. and Mcmillan, E. (2013). Analyzing the Cur-

rent Trends in Enterprise Architecture Frameworks.

Journal of Enterprise Architecture, 9(1):60–71.

Davis, F. D. (1989). Perceived usefulness, perceived ease of

use, and user acceptance of information technology.

MIS Q., 13(3):319–340.

Gartner (2013). It glossary. http://www.gartner.com/

it-glossary/enterprise-architecture-ea.

ISO (2011). ISO/IEC 29110:2011, Software Engineering

- Lifecycle Proﬁles for Very Small Entities (VSEs).

http://standards.iso.org/ittf/PubliclyAvailableStandards/

index.html.

Lankhorst, M. (2005). Enterprise Architecture at Work:

Modelling, Communication and Analysis. Springer.

NASCIO (2003). Enterprise Architecture Maturity Model.

http://www.nascio.org/publications/documents/

NASCIO-EAMM.pdf.

OECD (2013). OECD Factbook 2013: Eco-

nomic, Environmental and Social Statistics.

http://dx.doi.org/10.1787/factbook-2013-en.

ONE (1919). Ofﬁce de la Naissance et de l’Enfance

(Belgian Ofﬁce of Birth and Childhood).

http://www.one.be.

SoftwareAG (1992). ARIS Toolset. www.softwareag.com/

fr/product/aris platform/aris design.

The Open Group (2009). TOGAF 9 - The Open Group Ar-

chitecture Framework Version 9.

Zachman, J. A. (2003). The Zachman Framework for Enter-

prise Architecture: Primer for Enterprise Engineering

and Manufacturing. Zachman International.

DrivingtheAdoptionofEnterpriseArchitectureInsideSmallCompanies-LessonsLearntfromaLongTermCaseStudy

339