Stakeholder Oriented Enterprise Architecture Modelling

Malgorzata Pankowska

Department of Informatics, University of Economics in Katowice, 1 Maja street, Katowice, Poland

Keywords: Enterprise Architecture, Stakeholder Modelling, Archimate, E-Prosumption, Knowledge Broker.

Abstract: The enterprise architecture (EA) is defined as a coherent and consistent set of principles and rules that

guides system design. In the EA modelling methods, an enterprise is identified with institution, business or

administrative unit, a firm or an industrialized region. Beyond that, EA can be considered as a set of

organizational attributes or activities. In this paper, the human roles' approach for EA development is

emphasized. The paper is to answer the question of who is the stakeholder of EA, who is competent and

responsible for the EA planning and development, and what activities must be realized to achieve the EA

goals. At first, the paper presents the EA as a product and a process, next the EA evaluation characteristics

are discussed. Finally, the EA modelling tool, i.e., ArchiMate is applied for stakeholder role visualizaton.

1 INTRODUCTION

Generally, the enterprise architecture (EA) is a

discipline of designing enterprises guided with

principles, frameworks, methodologies,

requirements, tools, reference models, and standards.

The primary need for developing an enterprise

architecture is to support the business by providing

the fundamental technology and process structure

for an IT strategy.

The EA should be widely accessible for all the

organization members to receive their acceptance as

responsive to user needs. In the ICT domain,

architecture will always specify and follow

incremental and iterative implementations of

information systems. For the purpose of this paper,

the enterprise architecture is a venture that seeks to

explain why organizations do what they do and how

they can be changed to achieve a certain demanded

purpose.

The main goal of the paper is to emphasize the

role of stakeholders in an enterprise architecture

modelling process and product. The paper consists

of three parts. At first, the enterprise architecture is

presented as a product and a process. Next part

covers literature review on the stakeholder theory

and the discussion on the stakeholder roles in the

enterprise architecture theoretical frameworks. The

last part is to present the specification of

stakeholders for the e-healthcare prosumption

architecture model development.

2 ENTERPRISE ARCHITECTURE

AS PRODUCT AND PROCESS

ISO/IEC/IEEE 42010 -2011 standard architecture is

the fundamental organization of a system embodied

in its components, their relationships to each other

and to the environment, as well as the principles

guiding its design and evolution. The EA as a

product serves to guide managers in designing

business processes and system developers in

building applications in a way that is in line with

business objectives and policies (Minoli, 2008).

The EA as a process is to translate business

vision and strategy into effective ICT components. It

should be noted that enterprise models are applied as

a computational representation of the structure,

activities, processes, information, people, goals, and

constraints of a business. The EA goals are to

promote business-IT alignment, standardization,

reusability of existing ICT assets and to share a

common model for project management and

software development across the organization. The

EA is to ensure a holistic view of the business

processes, systems, information, and technology of

the enterprise. The results of work of enterprise

architect cover the derived information technology

(IT) strategies, a new and modified EA, the new and

modified set of EA standards, and a roadmap

describing the ICT projects for the implementation

of the new architecture and achieving the target

state, and a development plan (Minoli, 2008).

Pankowska M..

Stakeholder Oriented Enterprise Architecture Modelling.

DOI: 10.5220/0005544700720079

In Proceedings of the 12th International Conference on e-Business (ICE-B-2015), pages 72-79

ISBN: 978-989-758-113-7

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

There are many well developed enterprise

architecture frameworks (Bernus et al., 2003;

Zachman 2007; Holt and Perry, 2010). The EA

frameworks emphasize the modelling part of EA

development and they do not consider any methods

which strictly belong to economics. The EA

frameworks' developers separate EA evaluation from

EA implementation. They prefer to analyse

architecture models, languages, modelling

techniques and propose methods for the evaluation

of the created artefacts. They perceive the necessity

to ensure coherence among different models, they

analyse the convergence of proposed models, their

scalability, openness, agility, sustainability and

ability to ensure security. However, the real value in

the enterprise architecture is revealed in the EA

implementation, supported by strong involvement of

its stakeholders.

3 COPYRIGHT FORM

The term "enterprise" can be interpreted as an

overall concept to identify a company business

organization or governmental institution. The EA

provides a holistic expression of the enterprise's

strategies and their impact on business functions and

processes, taking the firm's sourcing goals into

explicit consideration. The EA helps the business

organization to establish technical guidelines of how

the service delivery function needs to operate to

deliver cost-effective, flexible, and reliable business

services. The EA gives user an opportunity of faster

delivery of new functionalities and modifications, as

well as an easier access to higher quality, more

consistent and more reliable information. Well

architected systems can more quickly link with

external business partners. The EA is to ensure the

comprehensive understanding of the current state or

the desired state, as well as the interrelationships of

processes, people and technology affected by IT

projects. The organization has got a bigger

consistency of business processes and information

across business units. The EA identifies

opportunities for integration and reuse of IT

resources and prevents the development of

inconsistent processes and information. The

ISO/IEC 42010-2011 standard emphasizes the

stakeholder object in the architecture description.

According to this standard, Stakeholder has an

interest in the system, which exhibits an

Architecture. Architecture Description identifies

stakeholders and system of interests, as well as

expresses the Architecture. The following

stakeholders can be considered and identified in the

architecture description: system users, operators,

acquirers, owners, suppliers, developers, builders

and maintainers. Therefore, it should be noticed that

stakeholders are included in the information system

development processes, but the consortium of users

of the system should be further discussed in details

within a particular EA development project, because

it is a group of people highly differentiated, and

having different interests, risk awareness and impact

on the system.

Considerations on stakeholder theory need to

begin from the point of view of the stake. A stake

can be presented as an interest or share in a project

undertaken to achieve business, technical and social

goals. Widely, there are stakeholder's interests,

concerns, and perceptions of rights, expectations, or

even ownership. The organization’s interests are in

maximizing local budget profits, satisfaction,

environmental protection, benefits from external

funds, protecting intellectual and material properties,

balancing resources and demand, keeping the

citizens happy.

Stakeholder theory is about value creation and

how to manage a business effectively. Generally, the

theory should focus on the stakeholder relationships

and on the jointers of stakeholder interests rather

than solely on the trade-off that sometimes has to be

made. Stakeholder analysis asks to consider all the

parties who will be affected by or who affect an

important decision.

Wiring (2014) defines a stakeholder goal as a

desire for which the stakeholder has committed

resources in a certain process of value creation.

Value is created in a context, with the help of other

stakeholders. They jointly satisfy their needs and

desires by making voluntary agreements with each

other. Recognition of the roles of a multitude of

stakeholders in the value creation process diminishes

the problem of the dominant group. Stakeholders are

conscious that they are engaged in creating multiple

win-win situations, as well as they accept the

responsibility for the consequences of their actions.

The value creation process is determined by

stakeholders' attributes, i.e., legitimacy, power, and

urgency (Archie et al., 2014). Legitimacy refers to

the perceived validity or appropriateness of a

stakeholder's claim to a stake. Therefore, owners,

employees, and customers represent a high degree of

legitimacy due to their explicit, formal relationships

with a company. Stakeholders who are more distant

from the organization might be considered to have

less legitimacy. Power refers to the ability or

capacity to produce an effect. Urgency means the

StakeholderOrientedEnterpriseArchitectureModelling

degree to which the stakeholder claim on the

business calls for the business's immediate attention

or response.

Nowadays, the EA is considered as the discipline

of designing enterprises guided with principles,

frameworks, methodologies, requirements, tools,

reference models and standards. There are many

frameworks that support the EA modelling and

development, e.g., the Zachman Framework (ZF),

the Open Groups Architecture Framework

(TOGAF), the Generic Enterprise Reference

Architecture and Methodology (GERAM), the

Purdue Enterprise Reference Architecture (PERA),

the Computer Integrated Manufacturing Open

System Architecture (CIMOSA), the Lightweight

Enterprise Architecture (LEA), the Nolan Norton

Framework (NNF), the Extended Enterprise

Architecture Framework (E2AF), the Enterprise

Architecture Planning (EAP), the Federal Enterprise

Architecture Framework (FEAF), the Treasury

Enterprise Architecture Framework (TEAF) (Bernus

et al., 2003; Lankhorst, 2005; Minoli, 2008;

Theuerkorn, 2005). Mostly, the mentioned above

frameworks are product-oriented, and only some of

them, i.e., ZF, TOGAF, FEAF, CIMOSA and

MODAF emphasize the role of stakeholders in the

EA development processes. The ZF provides a basic

structure for organizing a business architecture

through dimensions such as data, function, network,

people, time and motivation (Zachman, 2010).

Zachman describes the ontology for the creation of

EA through negotiations among several actors. The

ZF presents various views and aspects of the

enterprise architecture in a highly structured and

clear form. He differentiates between the levels:

Scope (contextual, planner view), Enterprise Model

(conceptual, owner view), System Model (logical,

designer view), Technology Model (physical,

builder model), Detailed Representation (out-of-

context, subcontractor), and Functioning Enterprise

(user view). Each of these views is presented as a

row in the Zachman matrix. The lower the row, the

greater the degree of detail of the level represented.

The model works with six aspects of the enterprise

architecture: Data (what), Function (how), Network

(where), People (who), Time (when), Motivation

(why). Each view (i.e., column) interrogates the

architecture from a particular perspective. Taken

together, all the views create a complete picture of

the enterprise (Minoli, 2008). Since 1999, the FEAF

has promoted a shared development of US federal

processes, interoperability and sharing of

information among US federal agencies and other

governmental entities. The FEAF components of an

enterprise architecture cover architecture drivers,

strategic direction, current architecture, target

architectures, transitional processes, architectural

components, architectural models, and standards.

The architect is responsible for ensuring the

completeness of the architecture, in terms of

adequately addressing all the concerns of all the

various views, satisfactory reconciling the conflicts

among different stakeholders. The framework

emphasizes the role of planner, owner, designer,

builder and subcontractor in the EA development

process (see Table 1).

Table 1: The Federal Enterprise Architecture Framework,

(FEAF, 1999).

Data

Architecture

Application

Architecture

Technology

Architecture

Planner

Perspective

Business

Objects' List

Business

Processes' List

Business

Locations'

List

Owner

Perspective

Semantic

Model

Business

Process

Model

Business

Logistics

System

Designer

Perspective

Logical Data

Model

Application

Architecture

System

Geographic

Deployment

Architecture

Sub-

contractor

Perspective

Data

Dictionary

Programs

Network

Architecture

The FEAF is derived from the Zachman

Framework, however, the user of realized

architecture is not included in the development team.

Planning of enterprise architecture according to the

ZF meets some unclear situations (e.g., question

When? is difficult), therefore the FEAF seems to be

the simplified and more intensive version of the ZF.

The Ministry of Defence Architectural

Framework (MODAF) is the UK Government

specification for architectural frameworks for the

defence industry (Perks and Beveridge, 2003). The

MODAF covers seven viewpoints, i.e, All View,

Acquisition, Strategic, Operational, System, Service,

Technical. The All View viewpoint is created to

define the generic, high-level information that

applies to all the other viewpoints. In this approach,

the architect role is hidden in the particular

viewpoints. The Acquisition viewpoint is used to

identify programmes and projects that are relevant to

the framework and that will be executed to deliver

the capabilities that have been identified in the

strategy views. The Strategic viewpoint defines

views that support the analysis and the optimisation

of a domain capability. The intention is to capture

long-term missions, goals and visions, and to define

ICE-B2015-InternationalConferenceone-Business

what capabilities are required to realise them. The

Operational viewpoint contains views that describe

the operational elements required to meet the

capabilities defined in the strategic views. This is

achieved by considering a number of high-level

scenarios, and then defining what sort of elements

exist in these scenarios. The operational views are

solution-independent and do not describe an actual

solution. These views are used primarily as a part of

tendering where they will be made available to

supplier organizations and form the basis of

evaluating the system views that are provided as the

supplier's proposed solution.

The System viewpoint contains views that relate

directly to the solution that is being offered to meet

the required capabilities that have been identified in

the strategic views and expanded upon in the

operational views. There is a strong relationship

between the system viewpoint and the operational

viewpoint. The system views describe the actual

systems, their interconnections and their use. This

will also include performance characteristics and

may even specify protocols that must be used for

particular communication. The Service-oriented

viewpoint contains views that allow the solution to

be described in terms of its services. This allows a

solution to be specified as a complete service-

oriented architecture where desirable. The Technical

viewpoint contains two views that allow all the

relevant standards to be defined. This is split into

two categories: current standards and predicted

future standards. Standards are an essential part of

any architecture and it should be noted that any

number of standards may be applied to any element

in the architecture (Perks and Beveridge, 2003).

The CIMOSA framework is based on four

abstract views (function, information, resource and

organization views) and three modelling levels (i.e.,

requirements definition, design specification and

implementation description) (Spadoni and

Abdmouleh, 2007).

The four modelling views are provided to

manage the integrated enterprise model (covering

the design, manipulation and access). For the

management of views, CIMOSA assumes a

hierarchy of business units that are grouped into

divisions and plants. The TOGAF standard takes a

holistic approach to the enterprise architecture.

TOGAF is a registered trademark of the Open Group

in the US and other countries. TOGAF divides an

EA into four categories:

 Business architecture: describing the processes

that the business uses to meet its goals,

 Application architecture: describing how

specific applications are designed and how they

interact with each other,

 Data architecture: describing how the

enterprise data stores are organised and

accessed,

 Technology architecture: describing the

hardware and software infrastructure that

supports applications and their interactions.

In TOGAF, the architecture of a system is the

system's fundamental organization embodied in its

components, their relationships to each other and to

the environment, and the principles guiding its

design and evolution. Similarly to the ISO/IEC

42010-2011 standard, in TOGAF the minimum set

of stakeholders for a system covers users, system

and software engineers, operators, administrators,

managers and acquirers.

Beyond that, stakeholders are as follows: the

executive management, who defines strategic goals,

the client, who is responsible for the allocated

budget, with regard to the expected goals, the

provider, who delivers the component elements of

the architecture, the sponsors, who drive and guide

the work, and the enterprise architects, who turn

business goals into reality within the structure of

their system. Stakeholders have key roles in or

concerns about the business information systems.

Concerns may pertain to any aspect of the system's

functioning, development or operation, including

considerations such as performance, reliability,

security, distribution, and evolvability. In TOGAF,

the Business Architecture Views address the

concerns of users, planners, and business managers,

and focus on the functional aspects of the system

from the perspective of the users of the system - that

is, on what the new system is intended to do,

including performance, functionality and usability.

The People view focuses on the human resource

aspects of the system. Beyond that, the Data

Architecture Views and Application Architecture

Views address the concerns of the database

designers and administrators, and the system and

software engineers of the system. The Technology

Architecture Views address the concerns of the

acquirers, operators, communication engineers,

administrators and managers of the system (Minoli,

2008). Desfray and Raymond (2014) argue that in

TOGAF, stakeholders, actors and roles are

differentiated. Stakeholders are individuals, teams,

or organizations that have interests in or are affected

by the result of architectural change. An Actor is an

active enterprise participant (person, system,

organization) who takes part in the activities of the

enterprise. An actor is never a physical person. It

StakeholderOrientedEnterpriseArchitectureModelling

designates a category of function that participants

can carry out, as well as a type of skill required. The

role represents one of an actor's usual or expected

functions. It corresponds to a certain set of skills,

knowledge, experience and capabilities.

The Open Group ArchiMate 2.4 (2012) language

defines three main layers, based on specializations

of the core concepts. The business layer offers

products and services to external customers. The

application layer supports the business layer with

application services which are realized by software

applications. The technology layer offers

infrastructure services (e.g., processing, storage and

communication services) needed to run the

applications, realized by computer and

communication hardware and software system.

What is extremely important from the point of

view of stakeholder orientation is that in ArchiMate

modelling approach the motivational aspects

correspond to the "why" column in the Zachman

framework. The motivation extension of ArchiMate

adds the motivational concepts such as goal,

principle and requirement. The motivational element

is defined as an element that provides the context or

reason lying behind the architecture of an enterprise.

The motivation extension recognizes the

concepts of stakeholders, drivers, and assessments.

Stakeholders represent groups of persons or

organizations that influence, guide, or constrain the

enterprise. Drivers represent internal or external

factors which influence the plans and aims of an

enterprise. An understanding of business

organization strengths, weaknesses, opportunities

will help the formation of plans and aims to

appropriately address these issues. However, it is

necessary to understand the factors, often referred to

as drivers, which influence the motivational

elements. They can originate from either inside or

outside the enterprise. Internal drivers, also called

concerns, are associated with stakeholders, which

can be some individual human being or some group

of human beings, such as a project team, enterprise,

or society. Examples of such internal drivers are

customer satisfaction, compliance to legislation, or

profitability (The Open Group Archimate 2.4, 2012).

4 MODEL OF E-HEALTHCARE

PROSUMPTION

ARCHITECTURE

Although the user centred design process focuses on

computer end user tasks, as well as on understanding

the user's cognitive, behavioural and attitudinal

characteristics, there is a lack of procedures, which

strictly depict the role of a user in the information

system exploitation process. Generally, the user

experience methodologies allow for gaining a very

comprehensive understanding of user experiences

within information systems as well as domain

knowledge. However, for information system

customised development, not only user experience is

important, but also user creativity and opportunities

to implement their creative ideas in the business

environment. The framework for end user

involvement is a system development and

exploitation should be supported by system

architecture modelling. The proposed in this paper,

e-healthcare prosumption support system model is

based on the idea of prosument-patron relationship

(PPR) development and management. In this

approach a patron is understood as human (library

custodian, knowledge broker) or computerized

agent, which supports users in the process of

exploitation of the knowledge-based e-healthcare

information system. The knowledge broker also

ought to be engaged in IT system and e-healthcare

services development as well as in user learning

processes (see Figure 1).

In many developed countries, citizens have

access to official governmental e-healthcare

information systems. However, beyond that, the

prosument-patron relationship system development

seems to be necessary to support e-healthcare

prosumption, in order to support self-diagnosis, self-

testing, self-monitoring and even self-treatment in

case of disease. In this case study, prosument is

understood as a patient, their family member or

friend looking in Internet or any other global system

for a remedy for a particular disease. The patron is to

be responsible for gathering user requests and

providing the competent knowledge to prosuments.

Generally, the patron receives three types of

information from prosuments, i.e., patients, their

family members or care takers:

 information about incentives, diseases. These

problems must be solved and professional

knowledge advice is required,

 questions, which answers are delivered by the

patron or end user with the help of patrons. The

answers could be received, otherwise the user

further browses the Internet to find the solution,

 suggestions provided by users as the result of

their own experiences and practices.

Suggestions should be further surveyed,

carefully analysed and presented in the form of

case studies.

ICE-B2015-InternationalConferenceone-Business

Figure 1: e-Healthcare Prosumption Architecture Model.

The knowledge brokers have access to the following

sources of knowledge:

 scientific libraries including articles from

scientific journals, articles from professional

research reports, books or book chapters,

repositories of peer-reviewed electronic

articles, i.e., ProQuest, Sciencedirect,

Cochrane, Medline,

 secondary documents. i.e., documents from

websites, minutes from seminars and symposia,

documents from other online knowledge

brokers, government reports, and reports from

international organizations, e.g., World Health

Organization, OECD.

The proposed architecture model (Figure 2) allows

for the development of a system which is

characterised by widening boundaries, a

multiparadigmatic profiling, and methodological

innovativeness. The approach allows to utilize user's

experience, practices and perceptions.

The knowledge-based PPR system development

relies not only on system developer research aims

and epistemological stance, but also on

organizational, historical, cultural, evidential and

personal factors, which are not problems to be

solved, but factors that must be included in practical

research design. The approach should also include

the context and healthcare creativity of users. A

system architecture model in ArchMate is organized

into some basic layers:

 BUSINESS containing elements such as actors

(i.e., Patient), roles (i.e., Prosument, Broker),

processes (i.e., e-Health Consultation Process),

services (i.e., Browsing, Conceptualization)

etc.

 APPLICATION covering elements such as

Financial Application, Portal, Management

System, Risk Evaluation, IT Support, etc.

 TECHNOLOYGY including elements such as

Data Server, Application Server,

 MOTIVATION containing elements: drivers

(i.e. Consultation Need), principles (i.e. e-

Healthcare Knowledge Development

Principles), assessments (i.e. Consultation

Evaluation), goals (i.e. Patient Satisfaction),

requirements (i.e. Healthcare Requests),

constraints (i.e., National Legal Acts,

Knowledge System Availability), stakeholders

(i.e. Patient, Patient Guardian, PPP System

Developer, PPP System Architect) (Figure 1).

When designing services within e-healthcare

system, appropriate knowledge components should

be assigned to them. According to Karlovcec et al.

(2012), a knowledge component is a description of a

StakeholderOrientedEnterpriseArchitectureModelling

mental structure or process that is used alone or in

combination with other knowledge components, to

accomplish steps in a task or to solve a problem.

User-oriented e-healthcare applications include

websites, chat sessions, newsgroups, e-mail

exchanges with medical experts, wireless and digital

broadcasts, and other compilations of online

resources. Developing such a self-care system

requires close cooperation between IT and clinical

staff. Self-care brings many benefits, i.e., ongoing

costs and waiting time reduction, early avoidance of

problems by self-diagnosis, networking of cancer

survivors peer interaction, reaching more widely

geographically dispersed groups. However, the

tailoring of the website content requires heavy

involvement of medical experts. There is also the

risk of losing contact with people who might be

vulnerable but will not ask for help as well as the

need to legally regulate the roles of knowledge

brokers and access to knowledge bases by users

(Moody et al., 2013).

A knowledge broker (i.e., a patron) is to ensure a

mutual understanding of goals and cultures, while

collaborating with users to identify issues and

problems for which solutions are requested.

Knowledge brokers should facilitate the

identification, access, assessment, interpretation, and

translation of medical research evidence into local

policy and practice. They ought to assist users in

translating medical evidence into locally relevant

recommendations for self-practice. They develop a

trusting and positive relationship with end users,

while at the same time they are promoting exchange

of knowledge.

5 CONCLUSIONS

The paper is concerned with the enterprise

architecture stakeholders as active and passive

partners who are involved in the process of the EA

products development. The reviewed in the paper

enterprise architecture frameworks focus mostly on

the enterprise methodology and stakeholder aspects

are omitted. Therefore, the development of

stakeholder oriented architecture frameworks is still

a challenge. Some good works have been done by

the Open Group, therefore the e-healthcare

prosumption architecture model was done in

ArchiMate language.

The presented in the last part of the paper

architecture model is developed to emphasize the

stakeholder position as well as an important proposal

that could be further realized. It should be noticed

that since the beginning of human life the first

medical diagnosis was the auto-diagnosis (or

diagnosis done by the nearest family) and the first

therapy is usually auto-therapy. The presented in

academic studies and in real life healthcare practices

emphasize the passive role of the patient. However,

the high cost of medical treatment and open access

to Internet enable to look for new ways of the

development of the medical auto-diagnosis, self-

monitoring, self-testing and going further - self-care.

Nowadays, almost all diseases are described online,

and virtual communities are developed to support

patients and their relatives. Therefore the e-

healthcare system based on knowledge brokering

could support knowledge management.

REFERENCES

The Open Group ArchiMate 2.4, Archi - ArchiMate

Modelling, User Guide, Version 2.4, 2012, accessible

December 2014, http://www.opengroup.org/

subjectareas/enterprise/archimate.

Archie, B. C., Buchholtz, A. K., 2014. Business &

Society: Ethics, Sustainability and Stakeholder

Management. Thompson Learning. NY.

Bernus, P., Nemes, L., Schmidt G., 2003. Handbook on

enterprise architecture. Springer. Berlin.

Desfray P., Raymond G., 2014. Modeling Enterprise

Architecture with TOGAF. Morgan Kaufmann.

Waltham.

Federal Enterprise Architecture Framework (FEAF),

version 1.1, September 1999, CIO Council, http: //

www.cio.gov/documents/fedarch1.pdf, access May

2012.

ISO/IEC/IEEE 42010 International Standard. Systems and

software engineering - Architecture description. 2011.

ISO. Geneva.

Holt, J., Perry, S., 2010. Modelling Enterprise

Architectures. The Institution of Engineering and

Technology. London.

Karlovcec, M., Cordova-Sanchez, M., Pardos, Z.A. 2012.

Knowledge Component Suggestion for Untagged

Content in an Intelligent Tutoring System. [in:]

Intelligent Tutoring System, Cerri, S.A., Clancey, W.

J., Papadourakis, G., Panourgia, K. (eds.). Springer.

Berlin, pp. 195-200.

Lankhorst, M., 2005. Enterprise Architecture at Work,

Springer. Berlin.

Minoli, D., 2008. Enterprise Architecture A to Z,

Frameworks, Business Process Modeling, SOA, and

Infrastructure Technology. CRC Press. London.

Moody, L., Turner, A., Osmond, J., Kosmala-Anderson,

J., Hooker, L., Batehup, L. 2013. Exploring the Need

for, and Feasibility of a Web-based Sef-management

Resource for Teenage and Young Adult Cancer

Survivors in the UK. [in:] Design, User Experience

ICE-B2015-InternationalConferenceone-Business

and Usability, Markus, A., (ed). Springer. Berlin. pp.

417-423.

Perks, C., Beveridge, T., 2003. Guide to Enterprise IT

Architecture. Springer Verlag. New York.

Spadoni, M., Abdmouleh, A., 2007. Information Systems

Architecture for Business Process Modelling, [in:]

Handbook of Enterprise Systems Architecture in

Practice, Saha, P. (ed). Information Science Reference.

Hershey, PA. pp. 366-382.

Theuerkorn, F., 2005. Lightweight Enterprise

Architectures. Auerbach Applications. London.

Wieringa, R. J., 2014. Design Science Methodology for

Information System. Springer-Verlag. Berlin

Heidelberg.

Zachman, J., 2007. Architecture Is Architecture IS

Architecture, EIM Insight Magazine. Volume 1, Issue

1 – March. Accessed at http: //www.eimininstitute.org

/library/eimi-archives/ volume-1-issue-1-march-2007-

edition/architecture-is-architecture-is-architecture,

January 2012.

Zachman, J. A., 2010. Frameworks Standards: What's It

All About? [in:] The SIM Guide to Enterprise

Architecture, Kappelman L.A. (ed.). CRC Press Boca.

Raton. pp.66-70.

StakeholderOrientedEnterpriseArchitectureModelling